In the past, I haven’t given much thought to the problem of Internet censorship – lame attempts like the Chinese firewall and Germany’s censorship lists were always easily defeatable by anyone with a server outside their jurisdiction (or even a 37 second YouTube video, in the latter case). Apparently, the current Iranian censorship seems to be more serious in that they actually responded to this by (at least partially) blocking SSH traffic. This, now, annoys me. I need SSH to read my mail (and have unfetterd access to whatever parts of the public internets I want).
How does one get past this crap? My best guess would be that the usual HTTPS dodge still works – blocking HTTPS to “world” is going to break so many legitimate applications that you might as well just shut down your entire Internets, so “SSL to port 443″ is a pretty safe bet as a carrier protocol. Two issues arise:
- If you have just a single IP address, wasting your port 443 for a rarely-needed redirect is a bit of a pity
- The censors might discover that you’re not actually running HTTPS on this port and block it as well.
A simple solution relies on the lucky accident that the initial step of the SSH protocol calls for the client to wait for a server message, while the initial step of the HTTP protocol is for the server to wait for a client message. Thus, it’s rather trivial to write a simple redirector that initially sits there like an HTTPS server. When it receives a request (or anything, really), it forwards to the HTTP server. If this phase times out, it forwards to the SSH server, which will immediately send its server prompt. This means that it is totally transparent to HTTPS traffic and just slightly annoying (well, depending on your delay) on connect for SSH sessions. A proof of concept is here.
Of course, that still leaves the censors with the options of
- Detecting it by waiting for the session timeout.
- Figuring out what goes on from traffic flow.
Now, number 1 is not much of a technical problem, but I’d still think it hard to find a couple of hidden SSH servers amongst the millions of actual HTTPS out there. Bonus points for doing this on something where the legitimate HTTPS is also popular enough to cause problems when blocked. Number 2 is a threat for me, but it’s less bad if you just want to tunnel your web surfing through it, since it will arguably show quite similar traffic flow behaviour to the actual (direct) HTTPS.
(Inspired by this AskMetafilter thread)

