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

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



On 13/10/12 10:18, David Fifield wrote:
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 have to admit I've followed the thread but it's the first time I heard of the flashproxy project but from what I picked up with a quick google session I wouldn't have thought that problem insurmountable though depending on exactly how you would want the TLS-wrapper to work would be different challenges.

If you are simply looking to for obfuscation then it seems to me utilizing a wrapper from client to proxy and a separate one from the proxy to the origin server of course that would not protect the contents from the proxy itself but when you speak of obfuscation it sounds to me like we are talking about avoiding blocks and/or passive eavesdropping in the path or at the origin server as of course the proxy already knows it's a flash proxy packet whatever it's wrapped in. In this case though it would not be necessary for the clients to have a CA issued cert as they would only be using it for the cypher from them to the proxy and you therefore define the certificate acceptability if it is just for encryption even a snake oil cert would be good enough, if it is intended to authenticate the client to the proxy then the proxy could itself be the CA using openssl, or have a central one so the client could use one cert for all the proxies in the system rather than each generating a new one.

From the proxy to the origin server I could see may be more difficult if that is the origin servers are in general actually performing certificate verification but I suspect that is probably pretty uncommon, TLS supporting mail servers for example will usually take just any old cert for the purposes of transport encryption, that is for cyphers that require certificates on both ends there are strong enough cyphers that only require a single certificate though.

On the web side HTTPS servers rarely use client certificates even for encryption let alone for validation and authentication on even an optional basis. I'm not sure why that would suddenly change with web sockets unless the specification for websockets specifically mandates it? If it comes down to the latter case then perhaps those wishing to offer servers might need to deal with the step of obtaining a CA cert for the proxy, cacert.org does them for free, the ones you can get instantly online are limited to showing only the server hostname even wildcards as it is the only piece of info that can be verified 100% automatically. Some of the commercial vendors offer such as single hostname server certs for free also, yeah in their case it's a hook to try and sell you a wildcard cert or w/e should you need one later but there are options available. This could even be made optional for operators willing to go a bit further, clients could then specify in their configuration whether to accept servers without depending on their security needs.

Just a thought out loud apologies for the long post.
(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
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

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