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?

  • 3
    So you are asking us to help you figure out a way to circumvent a company's IT security measures and keep it hidden from them?
    – GdD
    Commented Oct 2, 2013 at 11:26
  • 2
    It's a theoretical question - I, personally, am not employed, still a student. I believe there could be other uses for this technique and I'm just curious if this has a chance of working.
    – d33tah
    Commented Oct 2, 2013 at 11:27
  • 2
    BTW, in the explanation for closing you ticked "Questions asking us to break the security of a specific system for you are off-topic unless they demonstrate an understanding of the concepts involved and clearly identify a specific problem.". Please note the "unless" part.
    – d33tah
    Commented Oct 2, 2013 at 11:40
  • 1
    @GdD Circumventing security measures is on-topic here. It's a big part of what security is about, after all: how security measures work, what they're good against and what they fail to prevent. This has been discussed numerous time on meta. Commented Oct 2, 2013 at 12:32
  • 1
    For a more practical approach, discriminate between SSH and HTTPS based on the first packet in the connection. A few implementations: sslh, HAProxy, sshttp. Commented Oct 2, 2013 at 12:34

2 Answers 2


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 !)

  • The packet size and also time characteristics of the communication can be hidden by padding (sending of dummy data) and traffic shaping at the cost of consumed bandwidth and encryption power. BTW I would be interested how many application detection solutions would discover start of an SSH session in middle of a TCP connection. :) Commented Oct 2, 2013 at 11:59
  • I dimly remember there is a reference implementation for an SSH/SSL switch already, not sure it is actively maintained. Commented Oct 2, 2013 at 13:59
  • The SSH standard does allow for client and server to talk simultaneously. But historically the openssh client has been waiting for the server to talk first. If the server was to wait as well the connection could stall.
    – kasperd
    Commented Jan 5, 2015 at 13:21
  • Conceivably the server could decide to switch to SSH behaviour (and sending a banner) if it did not get a SSL ClientHello within, say, 5 or 10 seconds after the connection. A 5-second initial delay is usually not a serious problem for SSH (SSH connections are long-lived).
    – Tom Leek
    Commented Jan 7, 2015 at 14:58

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .