Certificate Warning with https set to "URL filtering only"

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

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.

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.

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 [:)]

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

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

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.

Mod2402, here is the link to my feature request.  

Reset HTTPS connection instead of URL Filter block page

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!

Mod2402, here is the link to my feature request.  

Reset HTTPS connection instead of URL Filter block page

done! but we are the only one [:(]