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

XG (SFOS 16.01.2) HTTPS scanning disabled but XG still uses Sophos CA for block pages on HTTPS Sites

This is very odd.  I have HTTPS scanning disabled and have even created an exception for my IP for all HTTPS scanning.  However, when going to an HTTPS site that is blocked (facebook.com for example), it is using the Sophos CA for the block page, which does not work on the endpoint, because it does not nor can have the Sophos CA installed as a trusted CA.  Why does XG use the Sophos CA as the root for blocked pages if I have HTTPS inspection turned off?  If I go to an HTTPS site that is NOT blocked, it works fine and it is NOT using the Sophos CA...just blocked pages are getting the "Certificate cannot be trusted" and show Sophos as the root CA in the certificate:

Here are some pictures:

Facebook is blocked, but we are getting this instead of a blocked page:

Here is the certificate...Sophos CA?!?!

Here are my settings for HTTPS inspection:

Here is an allowed HTTPS page (google) with the certificate...notice Sophos is NOT the CA:



This thread was automatically locked due to age.
Parents Reply
  • No...I'm still having the issue.  Through my private chat with Sophos, it sounds like it's something they will not change or fix (it's a feature).  I do not feel like they are making the right decision.  The inability to completely turn off SSL inspection and/or forcing users to have a Sophos XG signed CA in order to present a "blocked" page seems like a technical flaw.  What if you have guests that do not have the Sophos signed CA?  They will just get an invalid certificate on every blocked page.  Seems like a horrible design moving forward.

    We have decided to stick with Sophos UTM for now, which does not have this issue.

Children
  • Rick,

    it would be very helpful to know what are the technical reasons behind this behavior (besides the obvious ones, of course :)). 

    Let us know please.

    thanks

  • Hi Peter,

    we are facing the same problem, microapp is disbaled by gui and through cli but we still see Sophos Certificate on SSL sites, we have SFOS 16.05.1 and these also happens in MR2 and MR3.

    If we dissabled HTTPS Scanning and Decryption and MicroApp it should not change SSL Certificate from webpages but it does, the same happens with Outlook 2016 and Office365. And agree that UTM 9.x its more stable and behaves as it should.

     

    Regards.

  • Hi,

    Verify which FW-Rule scans the traffic with the help of packet capture. Show us the configuration inside the FW-rule, which shall provide us some information.

    Cheers

  • I am having the same problem, i have microapp discovery disabled from gui and from command line but still no luck. Cant open any https sites even though i dont have https scanning enabled.

  • I'm digging up this thread as I have to say that I am also seeing this exact behavior. 

    Which to me is astounding. 

    Please explain to me the exact REASON why we do not have the ability to turn off filtering per RULE. Why would you EVER try and force us through an SSL decrypt if the rule has specifically told it not to. Other wise, what is the point of the option under the Firewall rules 

     

    Even IF this is a technical problem and requires it to be on, the firewall should actually INDICATE what it is doing. Not making us discover what the hell it doing by way of troubleshooting. If your UI is not indicative of the ACTUAL behavior you have a serious problem in your software.

     

    next up.. what is your solution to a mix of non SSO users and SSO users on the same gateway that are trying to access HTTPS

    For instance our LTE users (all Android) are redirected through our gateway via MPLS, but are prompted by the Captive portal when they have to access anything outside of our whitelist (rule above it). This is fine if they only try and access non HTTPS websites first (or visit the captive portal directly). They log into the Captive portal and then the SSL certificates are all fine.

    Our head office users are on a Separate Subnet on the same Gateway/XG, these guys don't have the issue (unless SSO breaks), because SSO signs them in and then does not actually Hijack the HTTPS.

    There is no way I am going to install the Sophos SSL cert on 1000+ devices in the field, across the entire country. You have to be INSANE if you actually believe that this is a solution to offer your clients. (windows yes/maybe.. android NO!)

    So why is it that the captive portal (which is on http) is getting completely broken by an SSL certificate error that is not even applied after there is user authentication???

    Hope I haven't muddied the water, but I believe the information is relevant and completely valid.

  • First, lets ignore authentication and just deal with HTTPS decryption.
    If you go to a website that is blocked, you it will force HTTPS decryption on and serve a block page using the CA.
    For a block there are really only two technical things we can do:
    - Drop the connection with no reply so the browser just fails
    - Break into the SSL encryption (which means forcing in our own CA)
    There really is no other option.  There is no possible way for us to even send a 403 response back without decrypting the SSL.
    The UTM and XG behave exactly the same.  AFAIK all our competitors do as well.
    We don't currently have the option to just drop the connection, but if it a heavily requested feature we can look into it.


    In this thread, the microap-discovery is a red herring (a unrelated distraction).  There was a problem fixed in 16.05 MR4 that was regarding whether port 443 traffic was sent to the proxy if the services were not configured to do so.  Even in pre MR4 it wouldn't affect this.


    Now for authentication, there are difference between UTM and XG, and also between standard and transparent mode.  I'm not sure I understand the issue with SSL/CA and captive portal.  Can you please explain?

  • The Page is not "BLOCKED"... it's waiting for authentication. If our users need to log into the Captive portal for authentication, for a user auth based firewall rule, why am I then getting a HTTPS decryption error instead of the http captive portal login page? THIS IS THE ISSUE.

    It's taking the initial request, seeing that the user is not authenticated then throwing up a HTTPS SSL Cert error (Sophos CA) instead of just asking them for their credentials. 

    It 'should' be redirecting the unauthenticated requests directly to the Captive portal (as defined in the Firewall rule 'show captive portal to unauthenticated users')

    So what i am asking, is why its not 'DROPPING' the traffic (as defined in the rule) and then asking for a login and instead 'decrypting https' when its unchecked as an option. 

    you have to remember, the rule functions perfectly normal on http traffic. 

    Browse to page > Captive Portal > Login > access to page

    ^^^^ you need this to happen on BOTH https and http traffic. as all that happens now on https is

    Browse to page > NOTHING

     

    "We don't currently have the option to just drop the connection, but if it a heavily requested feature we can look into it." - this is not a feature.. this is basic firewall functionality.

  • Hello All,

    I have read the entire thread, and I am having the same issues.

     

    I have two WAN networks coming in through my firewall. One has an MS Exchange server, and the other has internet. When I create any type of web access rule/policy and apply it to a range on the local LAN, then it wants to replace the certificates. However, if i just allow any LAN to any WAN, and don't apply a web filter, then it force the sophos certificate.

    Is there somewhere in the Web Polices that you can turn this off? Outlook uses port 443 for exchange, and if the certificate isn't trusted then it doesn't work.

    Any ideas?

    Cheers!

    Clark

  • Hi All,

    I did this test on MR6 with this option:

    • Captive portal

    • Firewall rule

    • Captive Portal page is displayed in HTTP and the page google.com or facebook.com are using their own CA.

    Regards

  • Thanks lferrara...this fixed the issue on my end!