This is interesting but incomplete. It may not survive to deep packet inspection or rate limiting. Even worse - your only S3 machine could get blacklisted, and I don't see why operators wouldn't share blacklist the way it's done to fight spam.
So my suggestion is to have multiple alternatives instead, as in lines of defense.
First, a simple SSH server also running a socks and a http proxy is useful. Easy to reach and configure - some browser work better with http proxy (or was it sock? Opera only supports one but I can't remember which at the moment)
In the second line, you want to run the SSH server on a nonstandard port as the author does. I suggest multiplexing the port : simply run SSLH on both port 80 and 443, with the patch published on http://rutschle.net/pipermail/sslh/2012-April/000202.html
But that will not look like a standard SSL connection. Even worse, if you use your own certificate - operators could deny all self-signed certificates.
So get stunnel running on port 443 with a "usual" certificate instead, and pass the traffic on port 80 where you'll be happy to have SSLH or whatever you prefer - like Openvpn which can do port sharing or which can be put "behind" stunnel and sslh, so that you will use a standard 443 port, and do a genuine SSL connection on that port. Much better. Have some fun with burst.net - they offer you 2 IP for like $7/month : you can do some routing and give the 2nd IP address to your laptop on the other end of the tunnel. Now that is freedom :-) Every port will be opened in both ways :-)
Still, I do not believe anything of that will be enough to resist to statistical analysis. I've seen interesting tools, but if I down to that I'd better use a standard DNS tunnel (iodine, dns2tcp, ntsx, whatever).
Once again, multiplexing port 53 could be good to have them on different subdomains (you never know which tool you'll have on hand, or can easily recompile on the go) or to run a standard DNS server too (named, maradns, ...).
It will be a good idea to "rate limit" one of them because having too much traffic flow on port 53 to a given IP is something that stands out. (And I have seen DNS tunnels broken by a simple rate limit rule)
I found something interesting to multiplex DNS request in C, which name I don't remember at the moment. If anyone is interested I can dig that up.
Finally, deploy all that setup on at least 2 machines, using different domains and different subnet so that if one of your "lines of defenses" goes down (ie get blacklisted) you can safely move to the next one.
Total time it takes : 2 hours, then you'll always have a way out of a locked connection.
The need for "defense" implies an adversarial game with an opponent. I'm betting that the people who set up this security policy did it out of negligence rather than actively looking at port 22 and deciding not to allow it.
You could identify it as ssh vs SSL because they have different unencrypted headers. So systems which check that you are speaking SSL on port 443 would block ssh.
With HTTPS you get a handshake Client Hello packet sent in the clear, which has a TLS version identifier and a plaintext session ID among other things. With SSH2, you get a literal "SSH-2.0" as part of the protocol identifier which appears before the key exchange.
So my suggestion is to have multiple alternatives instead, as in lines of defense.
First, a simple SSH server also running a socks and a http proxy is useful. Easy to reach and configure - some browser work better with http proxy (or was it sock? Opera only supports one but I can't remember which at the moment)
In the second line, you want to run the SSH server on a nonstandard port as the author does. I suggest multiplexing the port : simply run SSLH on both port 80 and 443, with the patch published on http://rutschle.net/pipermail/sslh/2012-April/000202.html
But that will not look like a standard SSL connection. Even worse, if you use your own certificate - operators could deny all self-signed certificates.
So get stunnel running on port 443 with a "usual" certificate instead, and pass the traffic on port 80 where you'll be happy to have SSLH or whatever you prefer - like Openvpn which can do port sharing or which can be put "behind" stunnel and sslh, so that you will use a standard 443 port, and do a genuine SSL connection on that port. Much better. Have some fun with burst.net - they offer you 2 IP for like $7/month : you can do some routing and give the 2nd IP address to your laptop on the other end of the tunnel. Now that is freedom :-) Every port will be opened in both ways :-)
Still, I do not believe anything of that will be enough to resist to statistical analysis. I've seen interesting tools, but if I down to that I'd better use a standard DNS tunnel (iodine, dns2tcp, ntsx, whatever).
Once again, multiplexing port 53 could be good to have them on different subdomains (you never know which tool you'll have on hand, or can easily recompile on the go) or to run a standard DNS server too (named, maradns, ...).
It will be a good idea to "rate limit" one of them because having too much traffic flow on port 53 to a given IP is something that stands out. (And I have seen DNS tunnels broken by a simple rate limit rule)
I found something interesting to multiplex DNS request in C, which name I don't remember at the moment. If anyone is interested I can dig that up.
Finally, deploy all that setup on at least 2 machines, using different domains and different subnet so that if one of your "lines of defenses" goes down (ie get blacklisted) you can safely move to the next one.
Total time it takes : 2 hours, then you'll always have a way out of a locked connection.