On 13/10/12 10:18, David Fifield wrote:
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.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.
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