Skype, Check Point firewalls and HTTPS inspection

Welcome to the Skype community. To get started please read our short welcome post. Thanks!
Showing results for 
Search instead for 
Do you mean 
This topic has been archived.
To keep discussions in the Skype Community relevant we archive topics that haven't seen activity in the past 6 months. Read more about about archiving
Reply

Skype, Check Point firewalls and HTTPS inspection

Hi,

 

We have recently started using Check Points HTTPS inspection capabilities. What this does is allow us, using a specially created certificate, to inspect HTTPS traffic. One certificate secures the connection between the client and the firewall, the firewall opens this, scans it for unwanted content, and then re-encrypts it with the "real" certificate from the destination. This works flawlessly for regular web sites but it completely breaks Skype.

 

What we would like to do is create a rule that allows Skype to pass through the firewall and not be inspected. But because Skype seems to open loads and loads of "seemingly" random hosts and ports ( I am aware that this isn't really the case!), it is nigh in impossible to safely allow this software out of our network.

 

There are only a few ways that I can see that this could work well.

 

1. Allow Skype to use a particular certificate at the client end, allowing us to inspect it then pass it on.

2. Force Skype to use only a certain port or ports that we could then create exceptions for.

3. For the Mac version to allow SOCKS proxy access, where the SOCKS proxy server is not inspected.

 

How do the rest of you allow Skype out safely? Perhaps we are missing something. Please no replies along the lines of "Why are you scanning your outgoing traffic?" though.......

memnoch
Novel Adventurer
Kudos: 0
Posts: 4
Registered: 19-03-2012
Message 1 of 4 (4,653 Views)

Re: Skype, Check Point firewalls and HTTPS inspection

[ Edited ]

HTTPS traffic is normally only a subset of Skype traffic, but I guess you force Skype to use proxy anyway

not sure why #2 scenario is not doable already, but is it not possible to authorize traffic by app name rather than port or traffic type?

 

I assume you know about this http://download.skype.com/share/business/guides/skype-it-administrators-guide.pdf

Regards,
Neil
Neil
Super Adventurer
Kudos: 273
Posts: 4827
Registered: 27-06-2011
Message 2 of 4 (4,603 Views)

Re: Skype, Check Point firewalls and HTTPS inspection

Hi Neil,

 

Thanks for the reply. As I mentioned you can't use a proxy for the Mac version which is a pain as we have quite a few Mac users.

 

Regarding allowing the application, the problem is that the Check Point firewall is an off-host firewall and not a software firewall running on the host so there is no way to allow this traffic. The firewall does have application intelligence but it has no way of determining the traffic is Skype as it is encrypted. With HTTPS inspection enabled it has to be able to decrypt the traffic to even possibly determine the application. Because it cannot do this it cannot allow it.

memnoch
Novel Adventurer
Kudos: 0
Posts: 4
Registered: 19-03-2012
Message 3 of 4 (4,563 Views)

Re: Skype, Check Point firewalls and HTTPS inspection

The problem is not with Skype's genuine HTTPS connections, but with the way Skype attempts to tunnel through HTTP proxies.

 

HTTP proxies implement an addition 'verb' in the HTTP protocol: CONNECT. When an HTTP proxy receives a 'CONNECT' request, it will usually just instantiate a TCP connection to the requested address and then just shovel packets back and forth without bothering about what's going on inside. This allows browsers to still make secure, end-to-end encrypted HTTPS connections through the proxy. It also potentially allows any other app to make any other kind of TCP connection, potentially bypassing firewall rules. For example, an unrestricted proxy could allow an SSH client from a user's computer to connect to port 22 on a remote server, even if the organization's firewall blocks that kind of connection directly. This is why any decent proxy limits the ports on which 'CONNECT' requests can be served, and so is why Skype does what I'm about to describe.

 

When Skype makes a connection from a network where it has to use an HTTP proxy, it will use the 'CONNECT' method to connect to port 443 on a peer computer. However, unlike a real browser doing HTTPS, the data it sends over that connection is not real HTTPS. This is fine if the proxy doesn't expect to do anything with the content, but can cause problems if the proxy is trying to scan inside HTTPS connections.

 

When a proxy is trying to scan HTTPS, it no longer ignores the content of the network traffic sent through the CONNECT tunnel. It's expecting to see certain things, and if an application uses the CONNECT tunnel in an unexpected way, the proxy may not be able to handle it. There are two chief stages where this can fail.

 

First of all, the proxy expects to see an SSL handshake - it will try to intercept this as a man in the middle, simulating the web server to the browser, and simulating the browser to the web server. If the tunneled traffic is not SSL, the proxy may barf on the traffic rather than letting it through unmolested. If the client is not a browser, the client may barf on the fact that the SSL session has been intercepted - the spoofed certificate may appear invalid.

 

But if the SSL session is successfully established, the proxy will now be expecting to see real HTTP transactions going on. If the client program (Skype) sends anything other than HTTP over this tunnel, the proxy won't know what to do with it and will probably barf.

 

So the problem you are seeing is because Skype is trying to tunnel through the proxy by pretending to be an HTTPS connection.

 

Many web gateway products have ways to bypass HTTPS scanning for certain destinations - for example, customers may want to do this for financial sites. Unfortunately because Skype is trying to connect repeatedly to arbitrary IP addresses of Skype peers, it's not possible to set this up reliably.

 

So the short answer is that Skype's network protocols need an update so they can detect when they're in this sort of situation and find another way to connect.

RichB1066
Novel Tourist
Kudos: 0
Posts: 1
Registered: 05-04-2013
Message 4 of 4 (3,356 Views)
Reply

© 2014 Skype and/or Microsoft. The Skype name, associated trade marks and logos and the "S" logo are trade marks of Skype or related entities. Use of this website constitutes acceptance of the Terms of Use and Privacy and Cookie policy.

No emergency calls with Skype
Skype is not a replacement for your telephone and can't be used for emergency calling