On 28 May 2013 14:51, adrelanos adrelanos@riseup.net wrote:

How good are SSH connections with hiding what's inside?

Website fingerprinting has demonstrated, that SSH connections may hide communication contents, but which website was visited, could be guessed with a fairly good results.

Tor isn't a website, but if SSH leaks which website has been visited even when using a SSH tunnel, will it also leak the fact, that someone is using Tor through a SSH tunnel?

I think that if we make the adversary upgrade from probing and byte matching (e.g. look for specific ciphersuites) to statistical protocol modeling, especially with a small time investment on our part, we have won a battle. Development effort isn't free.

You probably can detect Tor traffic inside of SSH with some probability X after some amount of traffic Y. But what X, what Y, and how much effort on behalf of the adversary will it take? I don't know, but I do think we should work to move the fight beyond something as simple as byte matching.

-tom

On 2013-05-28 4:42 PM, adrelanos wrote:

The more pluggable transports, the better. Maybe if there are enough transports, the other side just gives up.

My interest is piqued by this statement and similar sounding ones that I hear, and myself also think, when talking about censorship. I suspect that if certain information leakage events (ILE) are important for the censor then I don't think giving up is an option, even if it means doing the hard(?) task of blocking all the pluggable transports. Of course this is all conjecture---I don't know the censor---which brings me to my main point:

It is important that we have a model of which censor we are wanting to defeat (or at least annoy). I don't mean every censor or every use case, just the one we are currently discussing. Also, we can have different descriptions of the same censor depending on the situation. The same censor can bring to bear very different tools depending on if the users are being annoying enough, or if ultimately the problem can be dealt with by non-Internet means. This also allows us to talk about the same censor and produce different censorship solutions depending on our goals and the censorship conditions that apply. We can through our actions (like becoming popular) shift the censorship context and thus have to reevaluate our solution.

I know that it is fiendishly difficult to get correct but it would help the discussion if we knew exactly what we're up against, at least in qualitative terms.

My attempt from what I think we're talking about, please correct/add to this where I err:

Circumvention strategies: 0. Collateral damage and obfuscation.

Censor Capabilities: 1. View all traffic coming in and out of a network (most likely has visibility of all AS and IX level traffic). We'll call this the visibility bubble. 2. Can manipulate (add, delete, change) said traffic in time and data dimensions.

Motivations: 3. Block *all* information leakage events. This means if even one ILE occurs the circumventor wins. 4. Limit collateral damage but some is acceptable.

Censorship Target: 5. General user population (G) within the visibility of the bubble. 6. Circumventor population (Cr) in visibility bubble. 7. Cr/G << 1; the incidence rate (R).

I think that this censor, while in a seemingly powerful position due to 1 and 2, is in a difficult dilemma due to 3 and 4, especially if 7 is a small number. Of course if we relax the condition of blocking *all* ILEs then the situation becomes more favorable for the censor.

I hope that descriptions such as the above really help identify the issues at hand helps focus on what is pertinent. I suspect that with Tor being useful to a diverse user-base the censorship scenarios are just as varied and the solutions (even within the plugabble transport space) can be useful in ways we did not think of.

Cheers, -mtee

On 2013-05-29 5:48 AM, Philipp Winter wrote:

On Tue, May 28, 2013 at 07:55:45PM -0400, Tariq Elahi wrote:

...

2. Can manipulate (add, delete, change) said traffic in time and data

dimensions.

The challenge is to predict what can actually be done with these three simple atoms. Be it terminating non-whitelisted TCP connections after 60 seconds, hijacking TCP connections after authentication or actively probing suspicious traffic.

It is challenging to predict, but since the censor is a black box we can only make assumptions and hope that they are over estimations of the censor's capabilities, that is if the capabilities can be ordered (partially or totally).

Also, Tor tries to satisfy a range of users behind a range of censorship regimes. Circumvention solutions that work with Tor inherit this diverse user base. Balancing diversity of user base (with censorship regime) with efficacy of circumvention is something that needs further looking in to.

...

Motivations: 3. Block *all* information leakage events. This means if even one ILE occurs the circumventor wins.

I suppose, in practice it's absolutely sufficient to block most of it. Plenty of deployed censorship systems are trivial to circumvent by exploiting specific DPI shortcomings (should we call it "spear circumvention"?).

I like that. Like a spear it attacks one weak link, but like a spear it doesn't catch (feed) much.

But only if you have the knowledge to do that. If only the very small technical elite is able to bypass the filters, you effectively win.

Going back to the point above, the tech elite are just some of the Tor user base. If this is who the circumvention system should serve then awesome. If not then we have more thinking to do.

There's also a social component. If you, as a censor, can spread enough FUD about the national filter, people might not even try to circumvent it.

This is true. FUD works. But I don't think that is something we can address through technological means, unless we're talking about keeping ppl anonymous so that they may test the FUD without repercussions.

mtee

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/