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