HTTPS Inspection and Office 365 - Anyone got it playing nicely?

[Stuart_Green]

Hi,

Until recently we'd had an application-based rule which covered HTTPS inspection for Office 365 nicely but in the past month or so, something has changed at the Office 365 end which means that they don't play nicely any more.

To that end, I've visited Microsoft's Office 365 IP address and URL pages to get all of the IP addresses and URLs to craft destination-based rules for HTTPS Inspection.

However, it seems that Microsoft aren't entirely truthful when it comes to giving out their IP addresses as it seems that some traffic is still inspected and a basic install of Office 2016 can't complete as the streaming side of things doesn't work.

Turn HTTPS inspection off and it'll stream nicely and do everything it should do.

Has anyone had any success in getting this working with HTTPS Inspection on?

TIA,

S

[PhoneBoy]

The main issue is, as you noted, excluding all the various IP addresses, which change from time to time.

We are working to address this limitation.

[Stuart_Green]

Thanks Dameon.

Is there a workaround?  It isn't just a problem with Office 365 but is also starting to creep in to Adobe Creative Cloud and various parts of that are randomly stopping.

Creating the hosts in SmartConsole is fine but as IP addresses of FQDNs change, the host needs to change too.

As I understand it, using the Application-based approach isn't foolproof as the application needs to be detected first so what can be done in the interim?

TIA,

S

[PhoneBoy]

I'm not aware of a clever workaround here.

It's something I know we are working to address, but I don't believe there is a finalized timeline.

I've asked R&D to comment on this thread who can hopefully provide a little more color to the situation.

[Dor_Marcovitch]

From what i know there is an sk that says exactly how to configure office365. This application should automaticly update and that is they way to configure. 

Problem with office365 and https inspection that i have noticed were only with skype applications.

I am working in a project that will automaticly update an dynamic object woth data from microsoft api

[PhoneBoy]

My guess is the SK you're talking about is: How to allow Office 365 services in Application Control R77.30 and above 

This does require HTTPS Inspection to be configured. 

[Stuart_Green]

Yep, so that sk is fine BUT the most it mentions about HTTPS Inspection is:

   "Of course, HTTPS Inspection is mandatory for the proper usage of the Office 365 services"

and HTTPS Inspection still inspects some of the packets which kills the streaming installation.

Even in sk110679 which sk112354 refers to, the most that is mentioned is:

     "HTTPS Inspection is mandatory on Security Gateway to achieve proper detection."

So both SKs in this instance aren't that clear as to what needs to be done within HTTPS Inspection to allow the streaming install to work.

Disable HTTPS Inspection and the streaming install works.  Switch HTTPS Inspection back on and the install fails.  That even rules out Geo Protection and IPS meddling...!

[Pedro_Espindola]

Do you have probe bypass enabled? I had issues with most microsoft services when probe bypass was enabled.

Check:

fw ctl get int enhanced_ssl_inspection

[Stuart_Green]

enhanced_ssl_inspection = 0

No dice there, then...!

[Limor_Ganon · Accepted solution]

Hi,

We plan to introduce the support for dynamically updated office-365 objects.

These objects will be supported in both Access Policy and in HTTPS Inspection policy for both source and destination columns.

Plan is to release a special HF on top of R80.10 with this capability in Q4 2017, and to support this capability in R80.20.

Could you share some more info regrading what IPs are not included in Microsoft feed as you tested it?

[Sergej_Gurenko]

Was this released for R80.X? Is this Management, Gateway or Both hot-fix?

Any plans to introduce HF for pre-R80 platforms? We are running MDS and has no ability to upgrade to R80 due to multiple reasons.

[PhoneBoy]

Both gateway and management fixes will be required.

As far as I know there are no plans to provide this hotfix on R77.30. 

[Georg_Reichau]

Is there any ETA for this feature?

Furthermore, is this also applicable for Skype for Business Online?

I have the challenge to enable Skype for Business Online, but would like the best possible security there.

Dynamic objects would help here, as I can define the exact rules for S4B.

The plan would be, to allow only connections to Skype with the ports for a defined user group, every other traffic from these clients will still need to pass my proxy etc.

Best regards,

Georg

[Stuart_Green]

Hi Georg,

Apparently this feature is coming in R80.20 which is in EA at the moment.

With Skype, if you have Identity Awareness running hooked in to AD/LDAP/Internal DB, you can create an Access Role and then define an application policy for the Skype application that uses the access role as the source.

If you’re using HTTPS Inspection you’ll need to add the IP Address group as the destination for the bypass rule so that the first packet doesn’t get inspected. 

[Kevin_Petermann]

Hi,

dynamically updated office-365 objects in the access rule means you will update the o365 ip addresses so that we don't have to use HTTPS Inspection to detect the applications?

[heavysoul]

Guys - I wish to use application control to permit O365 destined traffic as described in sk112354.

Could someone please explain the suggested rules below as per sk112354: -

rule 2 has source and destination as 'internal networks'?

rule 4 - will this deny all other internet bound traffic?

many thanks in advance

[Stuart_Green]

Rule 2 uses the topology table to ensure that if you have multiple interfaces connected to internal networks, the traffic flow for internal traffic is afforded free movement between those interfaces across the firewall. 

Rule 4 will deny internet access to known applications. It’s the standard clean-up rule for the application blade. 

[heavysoul]

many thanks Stuart

[Dor_Marcovitch]

i really enjoy this statesments "It’s the standard clean-up rule for the application blade"... when when it will be changed R80.10 do little work about this cleanup rule to be really cleanup rule?

by the way if those rule does not work contact checkpoin TAC they say this configuration should work...

[PhoneBoy]

You mean the default cleanup rule in App Control being "drop" instead of "accept"?

The reason the default is what it is is because in R77.30 and earlier, the cleanup rule for the App Control rulebase was Accept.

This is because App Control was designed to work more like a blacklist, not like a whitelist.

For R80.10 gateways where a unified policy can be deployed, you can deploy a "whitelist" or a "blacklist" policy.

Further, you can set the default cleanup rule for the specific layer.

[Tomer_Sole]

Dor Marcovitch wrote:

i really enjoy this statesments "It’s the standard clean-up rule for the application blade"... when when it will be changed R80.10 do little work about this cleanup rule to be really cleanup rule?

by the way if those rule does not work contact checkpoin TAC they say this configuration should work...

Hi, a guideline which we maintain is - Check Point does not change enforcement on behalf of its users. So even when new versions introduce new features, they do not get applied if they influence traffic Post upgrade, your cleanup rule remains the same. See Layers and the cleanup rule