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.......
19-03-2012 18:49 - edited 19-03-2012 21:13
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/sk
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.
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.