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

Wed May 29 05:16:20 UTC 2013

On Tue, May 28, 2013 at 02:33:40PM -0400, Tom Ritter wrote:
> 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.
> 

I assume they're more likely to simply whitelist IP addrs than allow
unimpeded connectivity for all. As Philipp said, SSL/TLS connections are
throttled heavily, if not entirely blocked, in similar situations.

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

We could go slightly further than this and build into the PT a rekey-gen
period such that bridge (IP addr, priv key) pairs are only valid for a
certain amount of time. We could even increase this to a (addr, privkey,
port) triplet, if we're ambitious. (Ideally BridgeDB will support
similar limited-time tokens for most/all future PTs, also).

(I also enjoy the slight irony of the fact that obfs2 was based on brl's
obfuscated openssh [0] and now we're trying to use SSH as a means of
obfuscation. :) )

> 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 found an interesting comment on a blog post the other day [1]:
  "
  On January 23rd, 2011 Anonymous said:
  First Tor. Next Ultrasurf. Then freegate. Then everything else. What
  if Iran gets tired of the shell game and whitelists the Internet? Then
  what?
  "

This was two years ago. We can mimic existing protocols for a while, but
eventually - it somehow seems - whitelisting actually becomes an options.
What if this trend grows? In which direction do we go?

One idea I've been thinking about may actually be applicable for this,
but it's still in a this-is-probably-a-bad-idea stage. Basically, create
a whitelist of sockets we know the censor will not block, maybe
including google.com:80 or the-iranian-govt-loves-me.ir:22. Once these
are known, setup a system of facilitators similar to (if not the same
as) what flashproxy uses but instead of having the flashproxy connect to
the censored user, the client sends out a single udp packet to one of these
hosts that is on the whitelist. She then includes the information about which
socket she chose in the introduction to the facilitator. The server-side PT
then receives the information from the facilitator (client IP addr:port,
unblocked server addr:port, public key, etc) and spoofs a packet from that
node which includes the PT's information (real IP address, token, etc) and
they can then proceed to handshake over some protocol.

There are at least half a dozen ways this is fingerprintable right now, so
it won't work as-is, and the fact that it requires raw sockets, hence 
root, is not ideal in any scenario.

> 
> 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

For the sake of Windows users I think we'd only be able to consider 2).

> 
> 
> 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
> 

The -W option on my man page says:
     -W host:port
                  Requests that standard input and output on the client
		  be forwarded to host on port over the secure channel.

Is this the option you're referring to? As far as I can tell, this
option only exists in ssh, what am I missing? :) Below you specify that
this would be used on the client side...I guess I may just be confused
by your wording and definition of "ssh on the other 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

I think this is a fine idea to investigate further, I'm glad you all
spent some time to think about this and sketch it up. 

One thing I fear about implementing these schemes where we use/mimic existing
protocols to obfuscate our own traffic is that we are inevitably
increasing the censorship in the respective country because the censor
eventually figures out a way to get what she wants while blocking
the circumvention tools, accepting any collateral damage. It is one
consequence with obfs* when the censor blocks the ip addr:port of the
bridge - no harm, no foul, only the loss of a bridge. I worry about the
reprecussions we'll see with this.

As a side note, I had an interesting find earlier when I stumbled upon
an "obfs2ssh" [2] implementation. "obfs2ssh used obfsproxy to obscure
SSH tunnel to avoid the DPI detection recently installed in China." I
haven't reviewed the code, just thought it was an interesting find.

- Matt

[0] https://github.com/brl/obfuscated-openssh
[1] https://blog.torproject.org/blog/update-internet-censorship-iran
[2] https://code.google.com/p/obfs2ssh/