[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

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" The JavaScript opens two WebSockets:
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 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
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.
tor-talk mailing list