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