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

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/