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

[Matt Joyce]

On 14/10/12 17:44, David Fifield wrote:
> 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Thanks for the link helps a lot was the sort of thing I was looking for 
earlier but didn't have a lot of time to work on it and didn't help with 
the large number of conflicting results that show up on google for 
similar terms.  In particular there are a lot of hits mostly academic re 
some system for remote executing flash applets on proxy machines on 
behalf of embedded devices like phones all neatly interspersed with the 
usual suspects that appear en mass for any search term with the 
sub-string proxy or similar. Having just read over that though I do see 
how it doesn't work now, as for the no check certificate situation I 
would strongly suspect that there is no such option, it is one thing to 
permit that for some local software on the host quite another for 
remotely sourced JS code.

If there were any workaround in that regard my suspicion would be that 
it would likely require some plugin running at a high privilege level 
than JS to initate the call locally, a signed java applet or something 
similar would possibly have that level of access though I don't know 
when it comes to most coding it is in the I wish I could category my 
best is usually more limited to hacking minor modifications into code 
that someone far more skilled kindly made available.  I am aware that 
signed applets do have significant access in most browsers at the same 
time a signed applet can open raw sockets anyway so they would have no 
real need for such control over the websocket interface, that said if 
applets etc were limited to what they actually *need* or was sane to 
provide there would be a lot less issues with them.  It may be worth 
checking as if the ability is there is may only take a tiny function 
inside a signed container provided the user grants permission.

Concerns me some that JS is able to do even this much without the 
browser prompting for permission, this is a use I can approve of but at 
the same time it once again makes me glad of my noscript while browsing 
the rest of the internet I don't think too much of the wisdom of 
allowing arbitrary pages to open connections completely at will without 
even so much as an alert to the user. Something I need to find some time 
to read up on find out what, if any sanity checks these websockets have 
the outbound connecting only thing doesn't give me confidence that it 
was well thought out, a connection once open is bidirectional so the 
limitation makes no sense to me but the only reason I can see for having 
it is a misguided security mechanism that is asking for trouble.