Thread Info
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Certificate Warning with https set to "URL filtering only"

kdessis
Hi guys,

we installed a new system in a VM at a customer.

Enbaled Webfilter set to transparent mode and set HTTPS scan settings to "URL filtering only". This should normally not produce any certificate warnings... but IT DOES.
Any client who accesses a secure site gets a warning shot in the browser.
I disabled, enabled webfilter, restared the GW.. always same strange bahviour...

The only way at the moment is to enable "Do not proxy HTTPS traffic in transparent mode" but thats not what we want... 

...any ideas??

Cheers, kdessis


This thread was automatically locked due to age.
  • 0
    What is the warning?   Please show a related line from the Web Filtering log.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
    • 0
      You will still get the warning if you access an https site that is blocked, because it needs to man-in-the-middle in order to display the block page.  And if you are using browser auth and it needs to display the portal login page.
      • 0
        I'm puzzling over this issue as well.  Hosts that trust my UTM's cert are OK, but those that do not trust it are getting cert errors on HTTPS sites that are blocked when the UTM responds with its own page.  What I wish is that I could set it to just reset the connection without responding with a friendly explanation as to what happened.  Is there a way to do that?
        • 0
          Hi, and welcome to the User BB!

          Please click on [Go Advanced] below and attach a picture of the warning.  Also, please show the related line from the Web Filtering log file.

          Cheers - Bob
           
          Sophos UTM Community Moderator
          Sophos Certified Architect - UTM
          Sophos Certified Engineer - XG
          Gold Solution Partner since 2005
          MediaSoft, Inc. USA
          • 0
            Hi there,

            all my customers  that do not use full https scanning have also these issue. I can't understand, why sophos says that is not a bug. The issue occurs because the error page is called by https://paththrough.host.domain.tld/static/logo.png

            All customers who want to use the web protection must rollout the utm ca certificates in their active directory domain.

            For me, that is absolutly a bug.
            €dit
            or must import the ca certificate in the local browser.

            regards
            mod
            • 0 in reply to mod2402
              .....
              All customers who want to use the web protection must rollout the utm ca certificates in their active directory domain.


              Another solution (easiest one) is to import certificate of internal AD CA server (if present) to UTM.

              Not a bug, UTM uses MITM not only for SSL decrypt and scan, but also for other things.  This post was from Michael Dunn, that I saved in my KB:

              The UTM uses HTTPS to provide user notification, perform browser authentication and secure other user interactions. By default, the UTM uses an automatically generated certificate for these HTTPS connections:
              o If the user requests an HTTP page and the proxy must interrupt (eg show a block/quota page) then it send the block page on the HTTP connection.
              o If the user requests an HTTPS page and the proxy must interrupt (eg show a block/quota page) then it send the block page on the HTTPS connection. It must MITM even if HTTPS scanning is off.
              o The only exception to this is some authentication where the initial request is HTTP but we switch it to HTTPS.
              o Note: if we do MITM in order to show a block page (quota warn, etc) it is only for that page display. Once they are back at the real site it will be using the real Certificate again.
              o For HTTPS we really don't have much other option. The only other thing we could do that would not involve MITM is just drop the connection without sending any page back to the user. For transparent mode that might end the browsing timing out and displaying a "cannot connect to server" error.
              • 0 in reply to vilic
                Another solution (easiest one) is to import certificate of internal AD CA server (if present) to UTM.

                Not a bug, UTM uses MITM not only for SSL decrypt and scan, but also for other things.  This post was from Michael Dunn, that I saved in my KB:

                Hi vilic,

                yes this is one solution for managed clients. But what about smartphones, tablets, MACs and other unmanaged devices?

                Normaly you should never import a ca certificate with private key from another ca into the utm. The right way is, use an underlaying issuing ca just for the utm.

                The unmanaged devices are a big problem. They need a manual import. The user portal can not provide the webadmin ca cert (default config) or the VPN signing ca cert (with configured custom end user certificate).

                I can't understand why the blockpage must called over https...

                For me, this is a bug.

                regards
                mod
                • 0 in reply to mod2402
                  I can't understand why the blockpage must called over https...

                  My guess: because the original request was done over https. The UTM can't just send back http data over port 80 where the client is expecting a https response from server port 443. Something like that maybe? Could be completely wrong so don't take my word for it.. [:P]
                  • 0 in reply to InformaticaOostkamp
                    My guess: because the original request was done over https. The UTM can't just send back http data over port 80 where the client is expecting a https response from server port 443. Something like that maybe? Could be completely wrong so don't take my word for it.. [:P]


                    Hi icto,

                    this is not a response to the original request. This is a new generated request just for displaying the warn / block message.

                    regards
                    mod
                • 0
                  Certainly.  Attached is an error from a host running Kaspersky Internet Security, resulting from an attempted secure connection to doubleclick.net during the course of normal user web browsing to some legitimate site.  When Sophos UTM intervenes due to this being a web ad, the response that comes back to the host is from an untrusted source as far as its concerned, therefore a warning to that effect.  So, again, I think it would be my preference that the UTM simply drop/reset the connection rather than replying with an explanation as to what happened.  Perhaps that's simply not an option.  

                  Here's what was logged on the UTM at that time...
                  2015:09:27-19:10:53 hostnameXYZ httpproxy[5279]: id="0060" severity="info" sys="SecureWeb" sub="http" name="web request blocked, forbidden category detected" action="block" method="CONNECT" srcip="192.168.X.X" dstip="" user="" ad_domain="" statuscode="403" cached="0" profile="REF_DefaultHTTPProfile (Default Web Filter Profile)" filteraction="REF_DefaultHTTPCFFAction (Default content filter action)" size="3312" request="0x181cf800" url="googleads.g.doubleclick.net/" referer="" error="" authtime="0" dnstime="0" cattime="57727" avscantime="0" fullreqtime="355025" device="0" auth="0" ua="" exceptions="" reason="category" category="154" reputation="trusted" categoryname="Web Ads"
                  • 0
                    Yes, that last bullet item is what I was hoping was possible somehow.  Looks like a conscious decision not to do it that way.  It would be a nice option to have, even if the default were to send block page and one had to knowingly switch it to silent drop.
                    • 0
                      Technically there is more than one request involved.

                      When you go to https badsite.com and the UTM blocks you it sends back an html page that says it is coming from badsite.com.  This must be done with a man-in-the-middle where the badsite.com certificate appears to come from the UTM's CA (certificate authority).

                      Now that html page may in turn load things like the logo.  If I recall correctly (and I might not) they are loaded from utmname.fqdn/path or maybe from fw-notify.net (this is not a real site, the UTM serves up these pages).  These must also be served over HTTPS (or else the browser displays a warning about mixed content).  There is an option to use the UTM's certificate (NOT the CA).  I believe on the Advanced menu you can upload a real purchased certificate that is valid for the UTM (for example something that has a subject alternate name of *.mycompany.com).  Then those elements that the html loads will be shown with a correct certificate.

                      But the browser's bar will still show https badsite.com and the html is still served with a certificate generate from the UTM's CA for badsite.com.  There is no way around that.

                      The only alternative is that https block pages just drop the connection and the user has no idea what is going on.  The UTM does not support that option, however you can raise a feature request if you want to.  Most people feel that a certificate warning followed by a block page is better than a silent drop.
                      • 0 in reply to Michael Dunn
                        Thanks for the feedback.  I do think it is worth throwing into the pile of ideas and have submitted it as a feature request.  Perhaps a small minority of users would prefer it, but I think it should be an option.
                        • 0 in reply to WEL
                          Thanks for the feedback.  I do think it is worth throwing into the pile of ideas and have submitted it as a feature request.  Perhaps a small minority of users would prefer it, but I think it should be an option.

                          Please post the link for the feature request here. I'll vote there [:)]
                        • 0 in reply to Michael Dunn
                          Technically there is more than one request involved.

                          When you go to https badsite.com and the UTM blocks you it sends back an html page that says it is coming from badsite.com.  This must be done with a man-in-the-middle where the badsite.com certificate appears to come from the UTM's CA (certificate authority).

                          Now that html page may in turn load things like the logo.  If I recall correctly (and I might not) they are loaded from utmname.fqdn/path or maybe from fw-notify.net (this is not a real site, the UTM serves up these pages).  These must also be served over HTTPS (or else the browser displays a warning about mixed content).  There is an option to use the UTM's certificate (NOT the CA).  I believe on the Advanced menu you can upload a real purchased certificate that is valid for the UTM (for example something that has a subject alternate name of *.mycompany.com).  Then those elements that the html loads will be shown with a correct certificate.

                          But the browser's bar will still show https badsite.com and the html is still served with a certificate generate from the UTM's CA for badsite.com.  There is no way around that.

                          The only alternative is that https block pages just drop the connection and the user has no idea what is going on.  The UTM does not support that option, however you can raise a feature request if you want to.  Most people feel that a certificate warning followed by a block page is better than a silent drop.

                          Hi Michael,

                          thanks for the detailed explanation. Now I understand why Sophos goes this way. But I think a mixed content warning is better the the red X on many places.

                          regards
                          mod
                        • 0
                          Just a note, instead of importing the CA for certificate errors on passthrough.hostname.domain you can actually purchase a publically signed certificate from say Comodo for the passthrough Subject Name. In Web Protection > Filtering Options > Misc tab at the bottom of the page is a section for "Certificate for End User Pages".

                          Whatever hostname you put in there (i.e. fw.domain.com) it will be prefixed with passthrough. like this: passthrough.fw.domain.com.

                          To test this, Comodo offer a free 90 day SSL cert which is pretty nifty and does the trick.

                          We have been wrestling with this for a client because problems still occur if you're using transparent web filtering with Browser Auth (or as the OPs problem is showing). The problem is because the proxy for redirecting port 443 traffic generates an on-the-fly cert  (as Michael Dunn has said) to maintain the SSL/HTTPS connection. The only way to get past that bag of cats is to import the CA which is fine in a Domain Group Policy environment but not for BYOD.

                          In a BYOD environment the best method is to create a landing page as soon as they connect which pushes them to an HTTP page (like a Ts&Cs) that is external to the network (so it sparks browser auth if used) and tells them to download and install the UTM Proxy CA. If you're using Transparent Browser Auth this is the best fit solution as discussed with Sophos Support to "mediate" the amount of people complaining about Cert errors.

                          Unfortunately, in the past 2-5 years, HTTPS is becoming more and more prevalent and with the inclusion of HTTP Strict Transport Security (HSTS), this can break a proxy connection. To test this, set up a proxy and then try to connect to Google.co.uk, unless you've got an exception for it in the proxy it should crash the connection as it's untrusted and you can't proceed. Proxy technology and methodology is 10 years behind the level of security we use on our web browsers and pages today.

                          Emile
                          • 0 in reply to Emile Belcourt
                            Just a note, instead of importing the CA for certificate errors on passthrough.hostname.domain you can actually purchase a publically signed certificate from say Comodo for the passthrough Subject Name. In Web Protection > Filtering Options > Misc tab at the bottom of the page is a section for "Certificate for End User Pages".

                            Whatever hostname you put in there (i.e. fw.domain.com) it will be prefixed with passthrough. like this: passthrough.fw.domain.com.

                            To test this, Comodo offer a free 90 day SSL cert which is pretty nifty and does the trick.





                            I have a cert for *.mydomain.org.uk so I can use it for this purpose.  So I set my dns up for passthrough.mydomain.org.uk to point to the UTM.  

                            However this seems to break browsing when authenticating via the browser.  On my macs I then cannot get anywhere at all.  I don't even get to the UTM browser login page.

                            have a I missed a trick here - this is very annoying!
                            • 0 in reply to AlleynsITSupport
                              I have a cert for *.mydomain.org.uk so I can use it for this purpose.  So I set my dns up for passthrough.mydomain.org.uk to point to the UTM.  

                              However this seems to break browsing when authenticating via the browser.  On my macs I then cannot get anywhere at all.  I don't even get to the UTM browser login page.

                              have a I missed a trick here - this is very annoying!



                              Hi AlleynsITSupport,

                              Did you put the DNS entry as the IP of the UTM or the IP as: 213.144.15.19?

                              The reason for this is that Astaro/Sophos actually own this IP so they can use it in their UTM so when a packet that is destined for that external IP the UTM actually goes "ooh, that's for me" and intercepts it.

                              To double check, if you go to Definitions & Users > Network Definitions then search for "passthrough" (w/out quotes) it will show two entries, the IPV4 definition which should be the IP shown above and an IPV6 address. Make sure the DNS entry matches up to what this definition says in your DNS and that should help. Another thing to make sure is that on the devices you install the Proxy CA Cert which can be found in Web Protection > Filtering Options > HTTPS CAs. This will help prevent trust issues.

                              But if you're in a BYOD environment, this gets a tad difficult :/

                              Hope this helps,
                              Emile
                          • 0
                            In the end it comes down to:

                            Admins want to monitor and control all web traffic
                            Users/Websites want all traffic to be private

                            HTTPS is used by users and websites.
                            If an Admin wants to break the security of HTTPS and enforce monitoring and control then they can.  But they cannot do it silently.

                            That fact is -- the system is built so that users cannot be spied on without their knowledge.  The system works.

                            If as an admin you don't like the fact that users know their traffic is not secure, that kinda between you and the users/standards.

                            The UTM is not at fault for being unable to control users' HTTPS traffic without their consent.  That is how the system was built.

                            If admins don't want users to get those types of errors they must give up on the monitoring and control of those websites.