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

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

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

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.

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

David Fifield