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

[Matt Joyce]

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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk