[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Flashproxys' impact on Tors' fingerprint

David Fifield:
> On Fri, Oct 12, 2012 at 06:21:13PM +0200, Sebastian G. <bastik.tor> wrote:
>> beside the case that the connection itself looks different due to the
>> use of (web)sockets (like explained in the paper) is there any impact on
>> how one could fingerprint on Tors' traffic?
> 
> No, using a flash proxy doesn't in principle make protocol detection any
> harder. We just encode the TLS byte stream and package it within a
> WebSocket stream. A filter could unpack the WebSocket stuff, reassemble
> the inside stream, and reuse whatever traffic inspection it is already
> using to block Tor.

"Good" I understood it correctly beforehand. It's more stuff the
adversary has to do either manually or the DPI box has to do more work.

> A few things work in our favor in terms of making it more cumbersome to
> fingerprint traffic within a WebSocket stream:
> 	* One side of each stream has each WebSocket frame XORed with a
> 	  pseudorandom key. (This isn't something we do specially, this
> 	  is just a part of the WebSocket protocol:
> 	  https://tools.ietf.org/html/rfc6455#section-5.3)
> 	* On some browsers that do not support binary WebSocket frames
> 	  (https://tools.ietf.org/html/rfc6455#section-5.6), the payload
> 	  is base64-encoded and sent in text frames, so a censor has to
> 	  decode the base64 too (or, perhaps, just block WebSocket
> 	  connections that appear to contain only base64).

That sounds good.

>> (If it doesn't make fingerprinting more difficult...) how complicated
>> would it to have another layer in flashproxy that helps in this regard?
> 
> As I see it, there are two axes to censorship circumvention, which are
> IP/port blocking, and protocol inspection. obfsproxy, for example, aims
> to defeat protocol inspection, but still uses a relatively small,
> relatively static set of obfsproxy bridges. Flash proxies have the
> opposite problem: flash proxy addresses are hard to block because they
> change all the time, but they don't do anything to disguise the traffic
> within.

Given a wide distribution of the badge it's impossible to block all of
them before new ones pop-up.

> A combined solution to both problems would be very nice. For example, we
> could use obfsproxy-style obfuscation inside of the WebSocket stream. We
> can't, ultimately, disguise the fact that the outermost layer is
> WebSocket, but we can disguise the payloads. To do such a thing is not
> conceptually difficult, it just requires a proposal, and someone willing
> to do it, and deployment of code to the necessary places.
> 
> Unfortunately, though TLS-wrapped WebSocket is standard, we can't easily
> use it because the clients that the flash proxy connects to do not have
> CA-issued certs.

My question was related to disguising the traffic and it was answered
very well.

>> (I want to avoid another thread an it's close enough.) What else could
>> be implemented in WebSockets to have a wide range of "legitimate" use?
>> (In order to make it painful for an adversary to block WebSockets)
> 
> I don't really know the range of things WebSocket is used for. One cool
> application I've seen is this: https://github.com/kanaka/noVNC which is
> a VNC client that uses WebSocket and HTML canvas.

Cool.

Thank you.

Regards,
Sebastian (bastik_tor)

_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk