Sophos XG breaks SSL when connecting to Outlook Anywhere

Hi Ben,

This is the certificate you want to download and install as a trusted root certificate on your computers:

Hope that helps,

Emile

Emile,

I cannot agree with you that installing the Sophos SSL CA is a solution and it is the only solution.  This is not acceptable.

I have different vendors visit my office all the time.  A lot of them use Office 365 emails.  How am I going to accommodate these visitors?  This is very embarrassing when I had to explain the issue to each of them.  These vendors might find my work unprofessional or suspect our firewall is lacking protection.

More importantly.  How do I know if this SSL certificate issue will not break other things?

I currently have to set the Web filter to None in order to avoid warning messages on my office staff's Outlook.  This work around is no good.

I agree with Matthias that there is a bug within the XG's web filtering module.

Ben

I've just noticed that this breaks Outlook using Office365 too. It's fine with Windows, since I can install the Sophos certificate, but on the iPhone Outlook client it's a no go.

Time to disable Webfilter again I guess.

No idea why it is SO difficult to get things to work with this product!

Hi all,

we have been experiencing this problem with the outlook certificate issue for the last 6 months, the more we query what’s going on the more no one really knows and we are forced to deduce it’s a bug. Introduced somewhere after a 9.3 update. We are not sure which one but the short version is that Sophos have changed the way the proxy works.

So we have deduced that this problem is encountered in 2 scenarios.

Scenario 1

This scenario, is only for users that are running Sophos UTM and using any other AV product in their internal network. Before the Sophos UTM proxy would actually receive the error message about the certificate but not forward that back to the end user. Hence the problem never arose but it did exist. They changed that and now the error actually goes to the end-user’s computer causing the pop up to occur. Not really certain if this is due to the ports issue as explained in the knowledgebase below, but I know that this command has resolved the certificate problem for some clients.

1. Your organization is running Sophos UTM with some other AV vendor
   1. To fix this please run the following command as root on the backend
   2.   #cc set http display_http_blockpage_explicit_mode 1

Scenario 2

This scenario might be un-related however the logs we find prove to be different, this scenario requires you to be running Sophos AV using live protect on your internal network and the Sophos UTM to be your DNS proxy.

We dug deeper on this matter and found it to be something with relation to DNS limitation on the backend, specifically Bind9 currently only allows 1000 DNS requests per second, and we saw the following error in the log:

1. "no more recursive clients (1000/0/1000): quota reached”

Every time this happened a enduser would experience the certificate pop up, so this is what I’m thinking… since Sophos changed the way the proxy works, when the DNS quota is reached and the proxy times out the error pops up, clients wouldn’t see this previously because the error would simply not be returned to the endpoint and the endpoint would try again. And the user would be none the wiser, but Sophos UTM proxy now sends the error back causing the popup to happen.

Since then we have implemented a fix on our clients UTM to allow 2000 requests per second on the DNS (bind9).

To confirm this was DNS proxy related we removed the Sophos UTM as the main DNS proxy and let our AD servers request directly to google DNS, the pop up disappeared.

please note we are hitting the DNS limit because the actual live protect in the Sophos AV is making thousands of unique DNS queries causing the Bind 9 limit to be reached at certain times of the day.

Command to change DNS recursive limit

1. Log into the shell and elevate to root

2. run the command cd /var/chroot-bind/etc

3. edit the following files, with VI

            Named.conf

            Named.conf-default

            Named_split.conf-default

4. under the options section on all of the files add the line: press I to insert text.

recursive-clients 2000;

so it would look something like this

options {

   directory "/var/named";

   recursive-clients 2000;

};

5. write and save the changes eg: ESC, wq!

6. then restart the Bind service using the following command

            # /var/mdw/scripts/named restart

If you have HA setup, this will also need to be carried out on the slave unit as well

I would also run the command in Scenario 1 afterwards

• # cc set http display_http_blockpage_explicit_mode 1

so as a summary:

1. on Scenario 1 we believe that this works were still monitoring
2. on Scenario 2 I also believe this to be the cause and I am not getting the errors at the moment
3. proven fact is removing the utm as the DNS proxy and using another DNS server to query google directly stops the certificate pop up from happening.

Anyone else with some ideas or solutions would be appreciated.

Hey Mark, do your suggestions only apply for the UTM or do these work for XG boxes as well?

Hey there,

I haven't taken a look at the xg backend yet, however I believe as it is Linux, it's just a matter of finding the same config files and editing them! So I hope so..

I would load a vm and play around there on the xg before implementing it on the actual production box but I don't see why this won't work!

This has been quite the nightmare for my clients! But try it! If your results are successful post it here then we know what the fix is and Sophos can action the changes. :)

Hope this helps

We are investigating what is probably a related case.  AFAIK the issue is something like:
Outlook tries several ways to connect.  It knows some will fail and some will succeed.  In a normal situation it tries Method 1 (which involved HTTPS), which fails, then Method 2 which succeeds.  And Outlook is happy.

Now when you put Outlook behind an XG, it tries Method 1.  The XG sees that Method 1 is failing and it wants to give an error message back to the client.  So it does a decrypt on the HTTPS so that it can send back a nice error message.  Outlook sees that Method 1 failed but not for the normally expected reason but because of a certificate.

An example of this would be if you have scanning turned off and then go to https://asdfasdfdf.com/  The XG does man-in-the-middle to tell you Host Not Found.  I think Matthias Hess described this earlier in the thread (March 5).

The final solution would possibly be the XG detecting that is Outlook and not sending custom error messages back.
I don't know if there is a configuration solution in the XG right now.  Possibly if you knew exactly what it was "supposed" to fail at and then putting in a higher firewall rule that just handled that case.

Any updates on this? I'm having the same issue with a new XG 115 - turning off Web Filter and the problem goes away.

Hello Friends,

I found this post is more interesting and I want to jump into it. I may answer to your problems at some levels. Other than this, it's a development only. Some might get a clue what is about am I talking. Right?

Actually, to improve user experience, there was an additional development taken into SF OS proxy.  Whenever there is an error because of web request blocked or network error, proxy will try to inform the end user about the error. And yes if your request is HTTPS then proxy will handshake with its own CA (SSL CA) to send the error message.  I guess this is gonna wrong here for some user (might for all)  if https request is blocked because of network error.

In outlook case (most probably Office365), autodiscover domain connection (say for example: https://autodiscover.example.com/autodiscover/autodiscover.xml OR https://example.com/autodiscover/autodiscover.xml) gets failed because of server which sends RST signal, I mean server is not accepting the connection request which leads proxy to send the same "connection error" with 502 response code to end user because proxy is also failed to connect to server and which is resulting into certificate error. 

Note: You may have different reason other then this. But this is what I found at some customer place.  

And the good news is, we have an enhancement in which we are going to revert the changes. That means proxy won't send any error message if there is a network issue.  

This is what all about the issue is but what is the solution?  hold on...hold on...

To resolve this issue, we can have two options.

(1) Install the SSL CA certificate: 

I know this is not a good solution, even I don't think it is a solution especially when I didn't configure SSL scanning.  But for a suggestion, I think it is a good solution. just kidding...

(2) Using FQDN base rule:

Create a FQDN host, in that configure your domain of Office365  like, example.com & autodiscovery.example.com etc...

Create network base security policy and in that configure FQDN host as a destination network.

Note: Don't apply any web filter policy in this rule. 

2nd solution is more helpful instead of disabling whole web filter policy feature. It requires only less configuration.

Hope it clears to you and helpful to you.

Regards,

Vishal Patel

I can confirm this works on XG (Second option)

Make sure you put it before you default outbound rule.