HTTPS Inspection issues

[Pedro_Boavida]

Hi,

I'm experiencing some issues with https inspection on SKYPE communications.

Doing a bypass solves the problem, either exempting the source machine, destination site or even the application.

Based on sk112214, this is a known issue and the suggested workaround is precisly.... doing a bypass.

This https inspection (MITM) approach seems to work fine on other technologies.

Doing a bypass is undesirable and unacceptable from a security perspective.

I'm not aware of any tweak, hotfix or configuration that helps to sort this out. Does anyone found a solution ?

I'm using R80.10 + JHF take 70.

Regards,

PB

[PhoneBoy]

HTTPS Inspection only works with...HTTPS.

Skype is not using HTTPS, which is why you need a bypass rule for it (assuming you want to allow it).

[Pedro_Boavida]

I agree with you... https inspection only looks into https traffic.

However, bypass should only apply to https traffic that I don't want to inspect. It makes no sense to bypass non-https traffic, like you are suggesting. Do you usually have a rule to bypass all non-https traffic at the top of your rulebase ?

I can see that Skype uses several ports and protocols and not all of them are https, indeed.... but still why checkpoint is unable to handle it ?

Regards,

PB

[PhoneBoy]

Just to clarify, are we talking Skype for Business (Lync), or Consumer Skype?

Current versions of the former are supposed to work, whereas consumer-grade Skype may not.

To be honest, I don't know the specifics of why it doesn't work.

It could be that some of the traffic looks enough like HTTPS to get inspected as such (and fail).

Or Skype is using Certificate Pinning for the stuff that actually is HTTPS (which is impossible to MITM).

[Pedro_Boavida]

I'm talking about the consumer-grade Skype. The referenced SK lists several applications with the same type of constraint. I see your point with the pinning techniques, but what puzzles me and bring to this discussion is that this works fine with other technologies without bypassing https inspection (ex: bluecoat) 

Regards,

PB

[PhoneBoy]

BlueCoat is an actual (explicit) HTTP proxy.

When forced through an HTTP proxy, Skype has to behave in a more standard way.

[Pedro_Boavida]

Actually BC can also perform in transparent mode (which is the case) but that’s just an example...

So, should I assume that on CP case everything is work as desired and all reported problems are due to application design ?

[PhoneBoy]

In this case, yes, it is working as expected.

When using HTTPS Inspection, if you want to allow Skype, you must configure a bypass rule.

Documented in SK as well: Unable to bypass Skype in HTTPS Inspection policy using a "Category", or a custom "Application/Site"... 

[Pedro_Boavida]

Thanks for your effort Dameon!

[Steve_Pearson]

Are you able to point me towards a list of IP addresses/ranges for Skype?

I've searched but been unable to find details for the consumer version, which is what's causing all my problems!

[PhoneBoy]

I imagine if such a list was available, it would be widely known as Microsoft publishes similar lists for Azure and Office 365.

[Viktor]

I think your description says more about your Bluecoat proxy configuration than either of the products. If you haven't had to manually bypass the Skype traffic in your environment you most likely have "Tunnel on protocol error" enabled or "Detect protocol" disabled on the SSL listener. That would cause protocol (and other interception-related) errors to fail open (TCP Tunnel Proxy vs SSL Proxy with detect protocol disabled ).

Bluecoat (Symantec) ProxySG can't intercept Skype traffic because Skype uses a proprietary protocol and rare ciphers that they can't understand (Processing Skype Through a ProxySG Appliance ).

I think that the behaviour you're dreading is exactly what your Bluecoat (Symantec) Proxy is doing right now.

[John_Fenoughty]

I have been doing a lot of work on Skype and HTTPS inspection in recent months. The document SK114419 (referenced above) simply says:

• Create network objects to represent ranges on IP addresses used by "Skype" clients.
• Configure the above network objects in the HTTPS Inspection Bypass rule.
• Install the policy.

As discussed in my document (below) this is not good enough for many organisations.

The 10 page document contains my findings and the relevant technicalities. The introduction and summary are clear: in almost all cases, disabling probe bypass made things a LOT better! That done, there are factors that can obfuscate this universally (in my experiences) positive result until they are addressed.

My document uses various test sites (13 in the first instance) and one of those, Skype gets a good four or five pages of the document. Summary: I now have Skype working well on a number of sites with HTTPS enabled on those computers using URL based bypasses only (no IP address or ranges).

I have also posted this in the thread about Probe Bypass in general.

The Document and the required CSV file are downloadable and discussed further in this thread. HTTPS Inspection Probe Bypass: To enable or not to enable? 

[Steve_Pearson]

Hi John,

I think there is still more to Skype I think!

Shane was unable to use desktop sharing yesterday, and the versions of Skype were the same!

The strange thing is, I can see drops in the log, but also accepts. What is your opinion on this:

Only difference I can see is that one is a Session, the other is a Connection!

Thanks,

Steve

[John_Fenoughty]

Nope, you've got me these. I have looked over those two log entries you have attached very carefully and I cannot see why the first one does not match your Skype rule. I know Check Point e still working on the HTTPS inspection engine for R80.20 and I have no doubt they will continue to be doing so. There used to be a bug where the first connection got dropped and a subsequent one succeeded, this is theoretically resolved but what you have seen and some observations I have made on a few sites suggest to me that this may not be 100% the case.

Also, on Desktop sharing - I think Microsoft are going to continue to develop that area as it is fairly new and does not yet work in the same way between Skype4B and Skype4C. That said, they are pushing hard for people to move to Microsoft 'Teams' rather than Skype4B for your primary collaboration tool; while we expect they'll support Skype4B for a while yet, it will soon become the 'legacy' option.

I haven't tried Teams with HTTPS inspection yet - the perfect situation would be that it works *with* HTTPS inspection so that we can actually monitor and control the information and content passing into and out of our networks but I'm not holding my breath!

[Sandeep_sharma]

This is the bad experience while enabling https inspection in checkpoint firewall. mostly websites, applications stopped working. Creating bypass rule with their destination ip address is difficult task. sometime application ip changed & issue come again. 

Checkpoint should look in this on priority. there is no fix yet in any gaia version either R80.10 or .20

Thanks

Sandeep Sharma