<div dir="ltr"><div>I have another idea.  (Not "another" in the sense of "do this instead", but "another" in the sense of "maybe do this additionally").</div><div><br></div><div>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.  </div>

<div><br></div><div>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.  </div>

<div><br></div><div>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.</div>

<div><br></div><div>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.  </div>

<div><br></div><div>I think the advantages of this are:</div><div>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.</div>

<div>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.  </div>

<div><br></div><div>I brainstormed this with Daniel Kahn Gilmore, Phillip Winter, Isis, and a few others in Hong Kong.  The notes we took are below:</div><div><br></div><div>Client Side</div><div>        libssh connection using a private key that is distributed w/ the bridge IP</div>

<div>        connect to the server</div><div><br></div><div>        obs normally listens on 1337</div><div>        Two options:</div><div>                1) ssh -L 1337 and obs doesn't listen on anything</div><div>                2) obs listens on 1337 and takes the data and passes it to ssh -W</div>

<div><br></div><div>        ssh -W keeps the same mechanisms that obsproxy uses so it's preferable</div><div><br></div><div><br></div><div>Server Side</div><div>        tor runs on local port 50000</div><div>        ssh -W tells ssh on the other side to connect to the tor port</div>

<div>        obsproxy does not touch data on the server side</div><div><br></div><div>        obsproxy does not open a port</div><div>        it sits there making sure:</div><div>         - tor is running</div><div>         - tor is configured right</div>

<div>         - ssh is listening on the correct port</div><div>         - ssh is configured right</div><div>                - this includes checking that MaxSessions is appropriately sane</div><div>         - users can auth to ssh using the private key that is expected</div>

<div><br></div><div><br></div><div>Open questions:</div><div>        Should we use ssh -L or ssh -W on the client side? (Probably -W)</div><div>        Is the -W option (the control messages) in the clear or in the encrypted transport</div>

<div>                If it's in the clear, this can be fingerprintable</div><div><br></div><div>Libraries</div><div> - paramiko does SSH server and SSH client, could use it</div><div><br></div><div class="gmail_extra" style>

-tom</div></div>