I have another idea. (Not "another" in the sense of "do this instead", but "another" in the sense of "maybe do this additionally").
Can a country block SSH? Surely state-sponsored network operations take place over SSH, so I suspect a country cannot block it quickly, easily, and without internal retaliation from it's legitimate users. Bureaucracy.
What if one of the obfuscated proxy protocols was SSH? And not "Let's make Tor look like SSH" but "Let's just put Tor inside of SSH". Have obfsssh-client use libssh to connect to a obfsssh bridge. When you get the Bridge IP, you also get a SSH private key to connect to the SSH daemon.
On the serverside, obfsssh-server makes sure SSH is listening on port whatever, and connected to Tor's local port 50000 (using the -W option). When you login, the client just talks Tor into the SSH stream, and on the server it's passed right into Tor.
This also very neatly absolves the issue of "What if a censor tries probing a obfs-bridge to see if it's a Tor bridge?" The server is a perfectly legitimate SSH daemon showing a perfectly legitimate key-based login prompt. Unless the censor has the private key, they can't login. The key is distributed next to the bridge IP - it's not intended to be anymore secret than the IP.
I think the advantages of this are: 1) While it does require some development effort - it's not nearly as much as other proposals. Accordingly it's lightweight. It's easy to deploy and experiment with and just see if or how it works. 2) It allows us to test a theory: that if we can identify a particular service or protocol that a censored country's government relies on, we can disguise Tor as it, and make it painful or difficult for them to block.
I brainstormed this with Daniel Kahn Gilmore, Phillip Winter, Isis, and a few others in Hong Kong. The notes we took are below:
Client Side libssh connection using a private key that is distributed w/ the bridge IP connect to the server
obs normally listens on 1337 Two options: 1) ssh -L 1337 and obs doesn't listen on anything 2) obs listens on 1337 and takes the data and passes it to ssh -W
ssh -W keeps the same mechanisms that obsproxy uses so it's preferable
Server Side tor runs on local port 50000 ssh -W tells ssh on the other side to connect to the tor port obsproxy does not touch data on the server side
obsproxy does not open a port it sits there making sure: - tor is running - tor is configured right - ssh is listening on the correct port - ssh is configured right - this includes checking that MaxSessions is appropriately sane - users can auth to ssh using the private key that is expected
Open questions: Should we use ssh -L or ssh -W on the client side? (Probably -W) Is the -W option (the control messages) in the clear or in the encrypted transport If it's in the clear, this can be fingerprintable
Libraries - paramiko does SSH server and SSH client, could use it
-tom