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 XG breaks SSL when connecting to Outlook Anywhere

Hi, I have setup a virtual XG firewall at home. I have have created an "allow all" policy for the web filter and have switched off the "Scan HTTPS" Feature. In my web browsers, this works fine and I see the SSL certificates of all the websites I visit.

When I start Outlook and connect to the mailbox of my company, I get a certificate warning from Outlook 2013 that shows the Sophos CA. Obviously, the XG appliance is breaking SSL for the connection to Outlook Anywhere. The company is running Exchange Server 2013.

When I connect to another Exchange 2013 system, the certificate warning does not appear, which totally confuses me. I assume this issue might be related to Exchange 2013 autodiscover, but I am sure it is related to Sophos XG as well. I did not have this problem with UTM 9 that I have been using before migrating to XG.

Do you have any ideas on how to resolve this issue?

Kind regards, Matthias



This thread was automatically locked due to age.
  • Is there an article or something you used to correctly deploy the certificate? 

  • If I recall correctly, in a world without XG:

    Outlook tries to do an SSL connection to a site that does not exist (or supports SSL?)

    Outlook fails on the SSL connect

    Outlook tries to do an SSL connection to the next site, and that works

    Outlook is happy.

     

    In a world with XG:

    Outlook tries to do an SSL connection to a site that does not exist (or supports SSL?)

    The XG intercepts this, can see that it will fail.  It does man-in-the-middle so that it can display a friendly error message.

    Outlook gets a successful SSL connect, but cannot use it.

    Outlook is not happy.

     

    Try the following:

    Go to admin advanced console and type the following command.  This turns off all microapp detection but also affects some HTTPS interception.

    system application_classification microapp-discovery off

     

    Do a packet-capture (wireshark) on the client computer

    Capture the failure.  Look at exactly what it is trying to connect to.

    Create a higher level firewall rule with the destination IP of what you found in the packet capture.  No HTTPS decryption, etc.

    Retest.  If it continues to fail, take another look at the capture to find next thing it tries to connect to.

     

    Remember - When the application fails it is probably when the packet capture says there is a successful connection (unfortunately it is to the XG not to whatever it thinks it is going to).  You need to actually let that connection through so that the connection fails, causing the application to go to the next one and succeed.

  • that seems like a lot of work to fix something that Sophos should be fixing.  I agree with your breakdown of what is happening.

     

    but seriously, deploying the certificate takes much less time and effort than the troubleshooting you are describing here.

  • Deploying the Sophos Cert via Group Policy seems to be working for me. 

  • Finally!!!

    Turned off HTTPS decryption on everything. No luck!

    Turning off all microapp detection did the trick for me:

    system application_classification microapp-discovery off

    Thanks Michael Dunn.

    The only thing I don't know is how is that affecting other functionality of the FW?

    Regards.

  • If you are not using Application Control, this has no effect.

    If you are using Application Control there is an effect.  Application Control uses IPS to watch all tcp/udp stream for certain data.  However IPS cannot watch encrypted HTTPS streams.  "micro-apps" refers to applications that use HTTPS and the web proxy does the application detection instead of IPS.  In v15 - v16.05 turning this flag off has an effect that no applications using HTTPS will be identified and can be blocked.  An example of this would be facebook chat, which uses specific URL paths in HTTPS.

    In v17 the current plan is to change the functionality and meaning of this flag, so that in a default configuration most people will not have this problem.

  • So are you saying if we execute the command  "system application_classification microapp-discovery off" to fix this problem it will break application control BUT it will be fixed in v17?  I.e. we don't have to go back and do anything after the fact?


    -Allan

  • I can confirm this will be fixed in a v16.5 MR, but I don't have a timeline.  In other words before v17.

    Application control works by watching streams for traffic.  "microapps" (terrible name) are when the application is using HTTPS, because it is an encrypted SSL tunnel the application detection does not work without the help of the http proxy.

    So if you run that command most of application control will work, but application control over HTTPS will not.

     

    If you ran:
    system application_classification microapp-discovery off

    Then after the fix is in place you do not need to do anything.  The normal behavior in the future will be with it off and all systems that upgrade will turn it off.

     

    Some of the early information on this workaround also recommended doing this (which turns out to be unnecessary):
    system application_classification off

    If you did this you must manually set it back on.

  • Thank-you for the reply, I will turn it off and not worry about it since it would be off with the update anyway and should fix the issue in the meantime.