Guest User!

You are not Sophos Staff.

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

Sophos UTM 9 HTTPS Blocking Behaviour

I am evaluating a Sophos 9.601-5 appliance using AWS AMI Marketplace. The goal is to replace a Squid proxy solution.

For blocked HTTPS pages, the desire is that when the client issues the HTTP Connect method they are immediately returned a 403 Forbidden. When I setup the Sophos UTM device the behaviour is to return back a self-signed certificate and a block page. The problem is this self-signed certificate will break clients and there is no easy way to roll out a root CA.

Is there any way to change this behaviour?

Thanks for your help.



This thread was automatically locked due to age.
Parents
  • What you want is not possible.

    If you browser sends a query to server1, it will accept a reply from server1, but it will ignore an unsolicited response from server2.   If the browsers worked otherwise, we would be dealing with a bunch of different attack methods.

    Http requires no authentication, so any device can claim to be server1 and send a reply.   UTM can display those block pages without any problems.

    Https requires authentication, so blocking the traffic requires impersonation.   UTM generates the certificate to impersonate.  If the browser does not trust the certificate, it will display a certificate warning page or other error. You have limited options:

    • Distribute the UTM CA Root so that UTM can impersonate successfully.

    • Do not distribute the certificate, but teach your users that a certificate warning might mean that the page was blocked.  If they click through the warning, they will see the block method.  On the other hand, we also need to teach users to be wary of certificate warnings, as it could mean that they have been misdirected to a hostile site.

    • Switch to XG, which has an option to drop the packet silently, which will cause the browser to display a timeout error after its wait timer expires.   If you are blocking Web Ads, as I do, I would expect silent block to create pernicious delays on many sites, delays that I expect users would find unacceptable.  I have not used XG, the option was discussed in another recent post asking similar questions.

     

     

Reply
  • What you want is not possible.

    If you browser sends a query to server1, it will accept a reply from server1, but it will ignore an unsolicited response from server2.   If the browsers worked otherwise, we would be dealing with a bunch of different attack methods.

    Http requires no authentication, so any device can claim to be server1 and send a reply.   UTM can display those block pages without any problems.

    Https requires authentication, so blocking the traffic requires impersonation.   UTM generates the certificate to impersonate.  If the browser does not trust the certificate, it will display a certificate warning page or other error. You have limited options:

    • Distribute the UTM CA Root so that UTM can impersonate successfully.

    • Do not distribute the certificate, but teach your users that a certificate warning might mean that the page was blocked.  If they click through the warning, they will see the block method.  On the other hand, we also need to teach users to be wary of certificate warnings, as it could mean that they have been misdirected to a hostile site.

    • Switch to XG, which has an option to drop the packet silently, which will cause the browser to display a timeout error after its wait timer expires.   If you are blocking Web Ads, as I do, I would expect silent block to create pernicious delays on many sites, delays that I expect users would find unacceptable.  I have not used XG, the option was discussed in another recent post asking similar questions.

     

     

Children
No Data