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

[David Fifield <david@xxxxxxxxxxxxxxx>]

On Sun, Oct 14, 2012 at 02:50:21PM +0100, Matt Joyce wrote:
> On 13/10/12 10:18, David Fifield wrote:
> >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.

Thank you for your reply. I think you have a misunderstanding of how the
system works. Check https://crypto.stanford.edu/flashproxy/#tech-details;
the client doesn't connect to the proxy; rather the proxy connects to
the client. We don't have control of certificate verification--that's
built into the browsers running the proxies. Every censored client would
need a CA cert recognized by the major browsers, and a domain to attach
it to.

For example, the flash proxy JavaScript contacts the facilitator and
gets back a reply stating "your relay is "relay.example.com:9901 and
your client is 1.2.3.4:9000." The JavaScript opens two WebSockets:
	ws://relay.example.com:9901/
	ws://1.2.3.4:9000/
For the first of these, we actually could use TLS (using a wss:// URL
rather than ws://) between the proxy and the relay. It would cost the
relay operators money, and it's also kind of pointless, because the
proxyârelay path is not the one being censored. It's the path between
the proxy and 1.2.3.4 what we want to obfuscate. As far as I know there's
no way from JavaScript to say, "don't do certificate verification for
this one WebSocket connection."

If we had full control of all participants in the communication, we
could of course do all sorts of fancy things, but we're limited on the
proxy to what we can do in JavaScript.

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