Microsoft Activation negatively impacted by HTTPS Inspection

[Larry_Birch]

I recently turned on HTTPS inspection with application control URL filtering and have had several instances where URL site bypasses did not work.  Microsoft O365 product activation is one of these, imagine the headache.

The behaviour is outlined in SK122158 which claims that if a certificate cannot be validated that the traffic will show as "Detect" and not bypassed even if the site URL is bypassed.  The solution is to either bypass an IP host object, or add the site's CA certificate to the trusted CA list under HTTPS inspection.  I am guessing that in order for the prior to work, the certificate is not validated for an IP host object.

Has anyone else run across this, and how did you resolve?  Any suggestions and wisdom would be appreciated.  I am also being asked to bypass ALL Microsoft traffic.  For context I am at R77.30 JHA286 in order to leverage the time quota hot fix.

Thank you in advance.

[PhoneBoy]

Did you try adding the relevant CA key to the gateway's key store as mentioned here: Bypass by URL in HTTPS Inspection does not work when the site certificate is invalid (same SK you mention above)?

Note that, in general, we are adding "Online Services" to R80.20 Gateway, where you will be able to create objects that represent specific online services like Office 365.

These objects will be dynamically updated by the gateway based on information provided by the provider, e.g. Microsoft.

I believe it will be possible to add these to HTTPS Inspection, but I'm not 100% certain of this.

[Larry_Birch]

Thank you very much for the quick response.  I have not done so as of yet, but will.  Is there an easy way to determine all the CAs, Microsoft and the like, that I may require to add in order to be proactive?  Could tracker be used?  Thank you again.

As for moving to R80, I am bound to R77.30 until such time that Time Quota is available.

[PhoneBoy]

The Time Quota feature is part of a "Customer Release" and you'll have to check with your local office to see what the plan is for bringing this into the maintrain.

Offhand, I'm not sure there's an easy way to find all the CAs you need to add, except maybe by looking in the CA store of a local PC and ensure all the Microsoft-specific ones are added.

[Larry_Birch]

Thank you very much.  You read my mind, I am doing that right now.

[Stuart_Green]

Hi Dameon,

It isn't in the HTTPS Inspection option in R80.20 just yet but feedback has urged its inclusion...!

[Gaurav_Pandya]

Hi Larry,

You can add CA of Microsoft as trusted CA in HTTPS Inspection. Other option is you can completely bypass the Microsoft O365.

As Dameon said, You will find Dynamic services of Microsoft O365 and for others in upcoming R80.20

[Larry_Birch]

Thank you for the input.  Bypassing O365 entirely would be a last resort I believe.  O365 seems an obvious point of exfiltration.  I don't know if there are mitigating controls in that cloud that we could leverage.

[PhoneBoy]

We do have a CloudGuard SaaS‌ offering, which will be generally available in short order.

[Stuart_Green]

HTTPS Inspection is a nightmare with O365 as you rightly point out.  We've been trying to get it to work for well over a year now and there's always something that just breaks ever so slightly.  Adding CAs in to HTTPS Inspection never seems to fully work.  It is also a problem with online services such as Sophos Central, Adobe Creative Cloud and other online services that don't like MITM attacks.

Hopefully R80.20's online services will fix this but it seems a long time coming...

The most success that we've had is to create network objects on the gateway by manually defining these object from Office 365 URLs and IP address ranges - Office 365  and then adding source and destination rules in to HTTPS Inspection.  Adding in the category to HTTPS inspection means that the first packet always gets inspected so that also breaks O365.  Not ideal but it is a workaround until R80.20 comes of age.