Chris Blankenship's Ramblings

Looking over the previously posted article about how Iran is filtering internet access got me thinking about SSH.  This little protocol provides an all in one package for circumventing corporate policies by allowing you to tunnel almost any traffic through SSH.  By tunneling your traffic you can effectively hide your nefarious behavior from your company, or in this case an unfriendly government. 

This must have been obvious to the Iranian government because included in the Arbor Networks post was a diagram that showed SSH to be the most blocked protocol, at a whopping 84.05%:

But then I started wondering how accurate the SSH traffic blocking was due to the ability to configure a SSH server to listen on virtually any port you choose.  Perhaps they have a way to filter the outgoing traffic regardless of the port used, maybe some sort of signature that could be detected.

So then I wondered how I would go about hiding SSH traffic, if the need ever came up.  It occurred to me that perhaps SSH could be hidden in plain sight by selecting a common port that is allowed in almost every corporate environment: TCP/443 used by HTTPS traffic. 

I could configure a SSH server to listen on TCP/443 and then configure my SSH client to connect over that port.  Most companies allow HTTPS traffic to travel out of their internal networks, either directly from the client or more commonly through a forward (CERN) proxy server.

Sounds good in theory but I have to see it work before I am convinced.  So I built a lab that consisted of a SSH server listening on TCP port 443, a stand-alone proxy server configured to allow only HTTP and HTTPS traffic to the internet, and then configured my SSH client, WinSCP, to connect to my SSH server over TCP/443. 

There is one more special ingredient that is required to make this all work:  the SSH client must support sending the request through a proxy server.  Turns out that WinSCP supports proxy servers (and I suspect almost all other SSH clients too) so I was all set.

After getting all of the pieces together I made a connection attempt while watching the proxy logs and the network monitor.  Turns out my hunch was correct.  The SSH client was able to make a connection to the SSH server through a typical HTTPS proxy server.  Here is what it looked like to anyone looking at a network capture:

You can clearly see that WinSCP sends a legitimate HTTP CONNECT to the proxy server which is accepted by the proxy server as if it’s normal HTTPS traffic.  Following the CONNECT there is the usual SSL negotiation between WinSCP and the SSH server that is simply passed through the proxy server.  After that all of the traffic is encapsulated in what appears to the proxy server as HTTPS traffic.  RFC 2817 defines the HTTP CONNECT method and discusses the security implications of this mechanism.

Imagine being a firewall administrator tasked with preventing unknown traffic passing from your internal organization to an outside network.  Forget about it!  Perhaps the admin could look for character signatures like WinSCP or strange (strange for HTTPS traffic) encryption offerings like blowfish but good luck with that moving target filter.

So what’s the harm, really?  Someone can’t really do that much damage by tunneling their web traffic through SSH, right?  Well, actually you can do almost anything you want with SSH tunnels.  For example…

Suppose you want to map a network drive from your work to your home computer?  No problem.  What about browsing the internet without having to follow the corporate policies?  No problem.  Finally, let’s just cut to the chase and tunnel everything through the SSH tunnel.

So by now you’re asking yourself… what can we do about it?  Turns out the answer is very little.  One option is to use something like forward proxy inspection that will inspect outbound traffic.  With forward proxy inspection you are able to see inside the SSL tunnel by performing what I will call Forward Proxy SSL Bridging.  Essentially the outbound SSL traffic is terminated at the proxy server, inspected, and then requested by the proxy server on behalf of the client.  Forward Proxy SSL Bridging, however, is still pretty new and not usually built into proxy servers.

Unfortunately ISA 2004/2006 doesn’t include Forward Proxy SSL Bridging and relies on third party vendors to fill the void.  One particular company called Collective Software produces a product called Clear Tunnel.  In addition to Clear Tunnel, the next version of ISA, now called Threat Management Gateway, will include Forward Proxy SSL Bridging:

HTTPS-encrypted sessions can be inspected for malware or exploits. Specific groups of sites—such as banking sites—can be excluded from inspection for privacy reasons. Users of the TMG Firewall Client can be notified of the inspection.

So with the absence of SSL tunnel inspection there really isn’t any way to prevent someone determined to punch a hole through your proxy server using SSH.  So in the end I would guess the ability to accurately identify how much SSH traffic was being blocked by the Iranian government is seriously low.