Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • +5 person also asked this people also asked this
  • Locked Locked
  • Replies 24 replies
  • Answers 2 answers
  • Subscribers 36 subscribers
  • Views 109163 views
  • Users 0 members are here
Options
Suggested
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

RickDunsirn

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
  • 0

    Rick,

    send me a PM and I will have a look at it.

    Thanks

  • 0 in reply to lferrara

    I sent a private message to you.  Thanks!

  • 0 in reply to Indo Optical SLU

    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

  • 0 in reply to sachingurung

    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.

  • 0 in reply to tom greene

    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.

  • +1 in reply to Caadmin Caadmin

    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?

  • 0 in reply to Michael Dunn

    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.

  • 0 in reply to Caadmin Caadmin

    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

  • +1 in reply to Clark Barlow

    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

  • 0 in reply to lferrara

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

  • 0 in reply to Indo Optical SLU

    UtN does this also, and I believe it is an unavoidable feature.  Here is what I have inferred:

    If the request is https, then the reply needs to be https.   A bogus site name is used for the response, so for https it uses a certificate issued by its proxy CA.  If you do not install the root certificate on your clieents, users will see a certificate error before the block page.

  • 0 in reply to DouglasFoster

    Make that "UTM does this..." Typing on my cell phone is hard.

Reply Children
No Data