Office 365 Bypass Decryption

[DarrenR]

I'm creating a firewall policy to support Office 365 traffic and I'm running into an issue (by design) regarding the decryption of Office 365 endpoint traffic. I've enabled HTTPS inspection globally, as well as inspection bypass for Office 365 endpoints, but the challenge I'm running into is that the Checkpoint will still perform SSL decryption on all traffic (because inspection is enabled globally). 

Microsoft recommends against decryption of Optimize and Allow category endpoints...Is there any way to bypass decryption (easily) for these endpoints? Ideally using updatable objects?

Obviously a bit of a catch-22 here. We need HTTPS inspection so we can recognize traffic that we'll allow out, but the global decryption settings create an issue for these two endpoint categories. 

Any thoughts are appreciated!

[PhoneBoy]

R80.40 Gateways will allow the use of Updatable Objects in the HTTPS Inspection policy.
In earlier releases, this would have to be manually maintained.
However, there is a script that can be used for this.
In this case, it's in the context of an Encryption Domain, but you can use the group for anything.
https://community.checkpoint.com/t5/Remote-Access-VPN/Route-O365-traffic-local-and-not-in-VPN-tunnel...

[DarrenR]

Very familiar with the R80.40 enhancement allowing the use of Updatable Objects in the HTTPS inspection policy, and this is working as designed (logs are reporting that O365 endpoints have been bypassed). The challenge, however, is that because HTTPS inspection is enabled globally, the Checkpoint will still perform SSL encrypt/decrypt, evident in the fact that the firewall will replace the SSL certificate.

I can't think of any way to completely bypass SSL encrypt/decrypt functionality, so thought I'd throw this out to the larger community. Attached are a couple of screenshots detailing the issue when testing connectivity from https://connectivity.office.com. 

[FedericoMeiners · Accepted solution]

Darren,

Hope you are doing well. My first guess would be that the updateable objects for Microsoft/Office don't include the involved wildcards / FQDN according to sk163595: HTTPS Inspection bypass list object

*.broadcast.skype.com
*shared.officeapps.live.com

Have you tried to create a specific custom application object containing those entries? Then add them to the TLS Inspection policy + bypass.

In previous version you could enable Probe Bypass so the bypass action doesn't inspect even the first packet of the TLS handshake.

However in later version probe bypass was discontinued. I have to perform more research on R80.40 but so far the best way that I found to complete bypass traffic is to not even include those hosts / networks on the SSL/TLS policy.

This approach is difficult to implement on large scale environments and of course it will disable TLS inspection completed on those hosts.

More information here: Outbound SSL Inspection: A war story 

[DarrenR]

Adding the custom application did the trick (somewhat surprisingly). I had assumed that the Network Onboarding tool was complaining about the SSL decryption/certificate replacement. Once I whitelisted the two application URLs and configured them for HTTPS Inspection Bypass, all health checks came back positive.

Thanks!

[PhoneBoy]

Seems like we're missing these URLs as part of Office 365.
In which case, it's probably worth a TAC case.
In the meantime, adding specific Custom Application Sites for these two FDQNs as exclusions should help (e.g. *.broadcast.skype.com and *shared.officeapps.live.com)