[tor-dev] RFC: obfsproxyssh

Tue Jul 2 22:42:20 UTC 2013

On 28/06/13 10:13, Yawning Angel wrote:
> Hello,
> 
> I have been talking about this in #tor-dev for a while (and pestering
> people with questions regarding some of the more nuanced aspects of
> writing a pluggable transport, thanks to nickm, mikeperry and asn for
> their help), and finally have what I would consider a pre-alpha for the
> PT implementation.
> 
> obfsproxyssh is a pluggable transport that uses the ssh wire protocol to
> hide tor traffic.  It uses libssh2 and interacts with a real sshd
> located on the bridge side.  Behaviorally it is identical to a user
> sshing to a host, authenticating with a RSA public/private key pair and
> opening a direct-tcp channel to the ORPort of the bridge.
> 

What sort of PKI are you using to verify the pubkey claimed by either side, to
prevent MitM? SSL has the hierarchical PKI of X.509, whereas SSH does not have
a "standard" PKI. Do you know about monkeysphere?

(Generally, I prefer SSH to SSL because it authenticates both ways by default.
But you must have a good PKI in mind to prevent MitM.)

> It is more aimed at non-technical users (because anyone with an account
> on a bridge can create a tunnel of their own using existing ssh
> clients), and thus can be configured entirely through the torrc.
> 
> It still needs a bit of work before it is ready for deployment but the
> code is at the point where I can use it for casual web browsing, so if
> people are interested, I have put a snapshot online at
> http://www.schwanenlied.me/yawning/obfsproxyssh-20130627.tar.gz
> 

Great, please let us know when it's easier to use!

> Note that it is still at the "I got it working today" state, so some
> parts may be a bit rough around the edges, and more than likely a few
> really dumb bugs lurk unseen.
> 
> Things that still need to be done (in rough order of priority):
>  * It needs to scrub IP addresses in logs.
>  * I need to compare libssh2's KEX phase with popular ssh clients (For
> the initial "production" release more than likely Putty).  It currently
> also sends a rather distinctive banner since I'm not sure which
> client(s) it will end up mimicking.
>  * I need to come up with a solution for server side sshd logs.  What I
> will probably end up doing is writing a patch for OpenSSH to disable
> logging for select users.
>  * In a peculiar oversight, OpenSSH doesn't have a way to disable
> reverse ssh tunnels (Eg: "PermitOpen 127.0.0.1:6969" allows clients to
> listen on that port).  Not a big deal if Tor starts up before any
> clients connect, but I'll probably end up writing another patch for this.
>  * Someone needs to test it on Windows.  All of my external dependencies
> are known to work, so the porting effort should be minimal (Famous last
> words).
>  * The code needs to scrub the private key as soon as a connection
> succeeds in authenticating instead of holding onto it.  Probably not a
> big deal since anyone that can look at the PT's heap can also look at
> the bridge line in the torrc.
> 
> Nice to haves:
>  * Write real Makefiles instead of using CMake (I was lazy).
> src/CMakeLists.txt currently needs to be edited for anyone compiling it.
>  * It currently uses unencrypted RSA keys.  libssh2 supports ssh-agent
> (on all of the relevant platforms) so key management can be handled that
> way.  I do not think there is currently a mechanism for Tor to query the
> user for a passphrase and pass it to the PT, but if one gets added,
> support it would also be easy from my end.
>  * The code does not handle IPv6 since it uses SOCKS 4 instead of 5.
> When Tor gets a way to pass arguments to PTs that are > 510 bytes, I
> will change this.
>  * libssh2 needs a few improvements going forward (In particular it does
> not support ECDSA at all).
>  * Code for the bridge side that makes the tunnel speak the manged PT
> server transport protocol would be nice (For rate limiting).
>  * libssh2_helpers.c should go away one day.  Not sure why the libssh2
> maintainers haven't merged the patch that I based the code in there on.
> 
> Things that need to be done on the Tor side of things:
>  * 0.2.4-14-alpha does not have the PT argument parsing code, so this
> requires a build out of git to function.
>  * The code currently in Git fails to parse bridge lines with arguments
> that can't be passed via SOCKS 5 (size restriction).  The PT tarball has
> a crude patch that removes the check, but the config file parser needs
> to be changed.
>  * The Tor code currently in Git likes to forget PT arguments.  asn was
> kind enough to provide me with a patch that appears to fix this (though
> the PT has a workaround for when it encounters this situation), but
> moving forward a formal fix would be ideal.
>  * All the PT related cleverness in the world won't do much vs active
> probing if there is an ORport exposed on the bridge.  Tor should be able
> to handle "ORPort 127.0.0.1:6969" (It may currently work, I'm not sure.
>  There should be a way to disable the reachability check if only to
> reduce log spam).
> 
> Open questions:
>  * Is this useful?
>  * Is it worth biting the bullet and rewriting this to use Twisted Conch
> instead of being a C app?
>  * Would it be simpler to write a wrapper around existing ssh clients?
> (Probably not.)
>  * How should people handle distributing bridge information?
>  * How to handle the private key to a given bridge getting compromised?
>  (Correctly configured, all that someone who obtains the key would be
> able to do is talk to the OR port so it's not a security thing, but it
> opens the bridge to being blocked).
>  * Does Tor tunneled over SSH look distinctive?  No effort is made to
> change the traffic signature, though this can be added if needed.
> 
> The tarball contains a more detailed README explaining how to set it up
> and how it works.  obfsproxyssh_client.c has a more in-depth TODO list
> as a large comment near the top of the file.
> 
> Comments and feedback will be appreciated.
> 
> Regards,
> 

-- 
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130702/5b43c783/attachment.sig>