[tor-dev] Building better pluggable transports (Google Summer of Code)

[Tom Ritter]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130528/29fa6b10/attachment.html>