Plausibly deniable SSH - does it make sense?

Question

My colleague just told me he can't make outbound SSH connections in his corporate networks, so I advised him to set up a server on 443 port and it worked. I then started thinking that the administrator could detect that it's actually an SSH connection using deep packet inspection and/or by connecting to the server, but I think I found a way to make it more difficult that does not involve protocol obfuscation (which I don't like, because it would break putty).

While it's obvious that if you don't change the protocol, your connection will stay in the logs, but I thought that the admin could feel confused if I could prove to him that there's actually a HTTPS website on the port and the server doesn't really speak SSH. In order to do the trick, I thought of a proxy that wraps the port and always lets in SSL requests, but lets in SSH only after a secure login attempt over HTTPS. Since I don't yet know the protocols of neither SSL nor SSH, can you think of a reason this couldn't work? If not, do you think it could actually be convincing/useful?

Answer 1

Technically, the first bytes of a SSL connection, and the first byte of a SSH connection, differ. Basically, with SSL, the client talks first, and the very first byte has value 22 (0x16) for the record containing its ClientHello (see the standard). With SSH, client and server talk simultaneously, but the server can wait for the client to talk first, and they send their "banners" which starts with "SSH" (see the standard), so the first byte from the client will be 83 (0x53, for an ASCII "S").

Thus, you could write some server software which listens on port 443, looks at the first byte, and, depending on that byte, redirects to a local SSH or SSL server. The two protocols can be multiplexed on the same port that way (I used to do that for SSL vs RDP). However, of course, there will still be SSH traffic on the socket when you do SSH, so packet inspection things will still see "SSH-like patterns".

The same applies to your idea. Even if you do a complete SSL-based dialog first, the moment you switch to SSH on the same socket, the packet inspectors may detect you. If you really want to evade them, you have to do the SSL thing completely: begin with SSL, then do the SSH inside the SSL tunnel. Basically, run a SSL-based VPN. From the outside, it will just be SSL all along; inside, arbitrary IP packets, which may convey some SSH or anything else, really.

(Note that SSL encryption does not hide packet size, and SSH traffic includes a lot of small packets which imply a traffic pattern distinct from "normal Web". A nosy sysadmin may still find out about your attempt at evading the local policies. Crime is not an easy craft !)

Answer 2

A simple solution is to set up an HTTP proxy (over HTTPS, technically), and then configure your SSH client to connect over that proxy. Putty supports this explicitly in the interface, while other clients may take additional work.

Behind the scenes, your client will make an HTTPS request to your proxy server (which could also be your SSH server) and issues a CONNECT command instead of a GET or POST. As far as the organization's proxy is concerned, HTTPS is completely opaque, but also not unexpected.

The primary difference between HTTPS proxy traffic versus standard GET/POST traffic over HTTPS is that proxy traffic is typically more interactively bi-directional. That is, you send a few bytes, I send a few bytes, and back and forth. Typically HTTP traffic on the other hand involves each site taking turns sending the entire request or entire response. But within proxy encapsulation, SSH isn't readily distinguishable from any other interactive protocol without a statistically significant sample and careful timing analysis.

Also, you can run an HTTPS proxy on a normal web server, sharing the address, port, and SSL certificate with the existing live site, which means that the only "smoking gun" so to speak is the traffic volume and timing patterns.