UTM Transparent Proxy Probleme mit Firefox

Hallo Reinhard,

(Sorry, my German-speaking brain isn't creating thoughts at the moment. [:(])

Configuring HTTP/S proxy access with AD SSO recommends using Kerberos instead of NTLM.  I don't know how to get Firefox to use Kerberos instead of NTLM when in Transparent mode.

MfG - Bob (Bitte auf Deutsch weiterhin.)

Hi,

dein link zeigt aber nicht die Konfiguration des Firefox für den transparenten Proxy.

In der Anleitung für den transparenten Proxy steht nämlich, so wie ich das verstehe, dass er für HTTPS Anfragen gar nicht funktioniert mit Kerberos.

Limitations of AD SSO

You can authenticate only standard HTTP requests through the proxy when using AD/SSO in Transparent Mode.
This only works when your browser makes a standard (non HTTPS) web request, and may not work for the applications and services listed below:   

• HTTPS
• Any URL with a parameter
• AJAX requests
• Any application which does not contain Mozilla in the User Agent string (non browser)

However, in UTM F/W >= 9.111, the proxy will use the last successful cached authentication for the same user, when non-standard web requests (HTTPS) are made, or when a non-browser application makes a web request.

This feature will prevent further authentication challenges from the proxy as long as there is an initial (successful) standard HTTP request which has been authenticated.

Oder versteh ich das falsch?

Gruß

In my experience, Firefox works with AD SSO.

Firefox has its own certificate store, so you have to manually configure the UTM root certificate into each user's certificate store, which is very difficult.   If this is not done, UTM's Block and Warn pages will trigger a browser warning about a certificate error.  PolicyPak.com has tools to do this if you buy their product and deploy their product to each PC.   In my opinion, Mozilla's products (Firefox, Thunderbird, and Lightning) have no place outside the home environment, because this is one of several features that are very difficult to configure to organization standards.   

The problem you are experiencing occurs because Decrypt-and-scan (https inspection) is off.   It has nothing to do with the choice between Transaparent or Standard proxy mode.   When a request is made in HTTPS, only the FQDN host name is unencrypted.  The NTLM information, URL path, and URL querystring are all hidden in the encrypted portion of the packet.   UTM cannot filter what it cannot see.

As your last post indicates, UTM uses a reasonable workaround:   When an HTTP request comes through, UTM remembers the IP address and username.  When a subsequent HTTPS request arrives from that address, it assumes that the same user is logged in.   (There is probably a timeout factor as well, I cannot speak to those details.)  This assumption is safe for single-user machines, but it can produce unwanted results on terminal server machines unless you use the advanced feature to assign each user a personal IP address.

Given all of the above: 

• If the first request to arrive is HTTP, the whole session will work.   
  
  
• If the first request to arrive is HTTPS, the request is unauthenticated and you have told UTM to block unauthenticated requests.  Because all of the better websites are now based on HTTPS, the HTTP-first assumption is not reliable.   Research studies indicate that HTTPS is slightly more than half of all web traffic, but my experience with typical business usage is that at least 75% of all traffic uses HTTPS.

Your options:

• Switch to HTTPS inspection.   Then every packet can be authenticated.
• Create a "safe" web filtering policy and filtering action, and apply it to unauthenticated users instead of blocking them.
• Make http://www.google.com one of your startup pages, so that an http page is launched automatically.   Google will redirect to HTTPS, but UTM will be happy because it will have seen the HTTP packet first.
• Teach your users the need to use an HTTP web address first.

My recommendations:

• Use Standard Mode and Transparent Mode proxies together.   I have a lot of non-browser web traffic originating from fat-client applications and operating system components, and I expect you do as well.   The browsers will honor Standard Mode proxy and will pass NTLM information.   Fat-client applications and operating system components cannot provide NTLM information and will generally not honor Standard Mode proxy.  Using both proxies allows you to use different strategies for the different contexts.
  
  
• My Standard Mode proxy captures web traffic with AD SSO authentication, but it still allows unauthenticated access to avoid your problems.   This configuration permits web access for special situations like PCs logged in with a local account instead of a domain account.
  
  
• My transparent mode proxy uses Authentication None, because I want my automatic update programs and fat-client applications to flow through UTM successfully.  It also ensures that I have protection from anything that tries to bypass the Standard proxy.
  
  
• I have UDP 443 blocked with a firewall rule.   If you do not have this rule, Chrome will bypass your web proxy using it's QUIC protocol.

I do not use HTTPS inspection at this time, although I have in the past.  I worry that my HTTPS traffic flows without content inspection, but there a lot of complications to having inspection enabled.  It requires a significant level of expertise and a significant commitment of time to detect and correct the problems.

In my experience, Firefox works with AD SSO.

Firefox has its own certificate store, so you have to manually configure the UTM root certificate into each user's certificate store, which is very difficult.   If this is not done, UTM's Block and Warn pages will trigger a browser warning about a certificate error.  PolicyPak.com has tools to do this if you buy their product and deploy their product to each PC.   In my opinion, Mozilla's products (Firefox, Thunderbird, and Lightning) have no place outside the home environment, because this is one of several features that are very difficult to configure to organization standards.   

The problem you are experiencing occurs because Decrypt-and-scan (https inspection) is off.   It has nothing to do with the choice between Transaparent or Standard proxy mode.   When a request is made in HTTPS, only the FQDN host name is unencrypted.  The NTLM information, URL path, and URL querystring are all hidden in the encrypted portion of the packet.   UTM cannot filter what it cannot see.

As your last post indicates, UTM uses a reasonable workaround:   When an HTTP request comes through, UTM remembers the IP address and username.  When a subsequent HTTPS request arrives from that address, it assumes that the same user is logged in.   (There is probably a timeout factor as well, I cannot speak to those details.)  This assumption is safe for single-user machines, but it can produce unwanted results on terminal server machines unless you use the advanced feature to assign each user a personal IP address.

Given all of the above: 

• If the first request to arrive is HTTP, the whole session will work.   
  
  
• If the first request to arrive is HTTPS, the request is unauthenticated and you have told UTM to block unauthenticated requests.  Because all of the better websites are now based on HTTPS, the HTTP-first assumption is not reliable.   Research studies indicate that HTTPS is slightly more than half of all web traffic, but my experience with typical business usage is that at least 75% of all traffic uses HTTPS.

Your options:

• Switch to HTTPS inspection.   Then every packet can be authenticated.
• Create a "safe" web filtering policy and filtering action, and apply it to unauthenticated users instead of blocking them.
• Make http://www.google.com one of your startup pages, so that an http page is launched automatically.   Google will redirect to HTTPS, but UTM will be happy because it will have seen the HTTP packet first.
• Teach your users the need to use an HTTP web address first.

My recommendations:

• Use Standard Mode and Transparent Mode proxies together.   I have a lot of non-browser web traffic originating from fat-client applications and operating system components, and I expect you do as well.   The browsers will honor Standard Mode proxy and will pass NTLM information.   Fat-client applications and operating system components cannot provide NTLM information and will generally not honor Standard Mode proxy.  Using both proxies allows you to use different strategies for the different contexts.
  
  
• My Standard Mode proxy captures web traffic with AD SSO authentication, but it still allows unauthenticated access to avoid your problems.   This configuration permits web access for special situations like PCs logged in with a local account instead of a domain account.
  
  
• My transparent mode proxy uses Authentication None, because I want my automatic update programs and fat-client applications to flow through UTM successfully.  It also ensures that I have protection from anything that tries to bypass the Standard proxy.
  
  
• I have UDP 443 blocked with a firewall rule.   If you do not have this rule, Chrome will bypass your web proxy using it's QUIC protocol.

I do not use HTTPS inspection at this time, although I have in the past.  I worry that my HTTPS traffic flows without content inspection, but there a lot of complications to having inspection enabled.  It requires a significant level of expertise and a significant commitment of time to detect and correct the problems.

Hallo,

danke der Post von DouglasFoster hat mir sehr geholfen zum Verständis.

Danke.

Ich habe nun "https entschlüsselung" aktiviert, dann habe ich aber das Problem, dass alle Seiten mit Javascript Probleme machen.

www.youtube.de zeigt nur weiße Kästchen an, die Google Suche sieht "komisch" aus.

In den Browsern Internet Explorer ist "Active Scripting" aktiviert. Das solle Javascript eigentlich aktivieren.

Kennt jemand das Problem?

Gruß