Hello,
My name is Danilo Carvalho, I am from ITA, Brazil, and I'm thinking about enabling flash proxy to use WebRTC, specially Data Channels, to connect between the client and the flash proxy. Some of the benefits involved would be:
1 - Flash proxies now would be able to receive incoming connections, this would remove the current need for the flash proxy to connect to the client. With the client being able to connect to the flash proxy, ticket( https://trac.torproject.org/projects/tor/ticket/5426) would be solved. If the client is the one controlling the connection, it wouldn't be needed for the flash proxy to guess his usage time.
2 - We could use the built in resources of the WebRTC to do nat traversal, through ICE and STUN servers. Although it isn't quite right to use public, company-owned ICE and STUN servers for that, we could build that functionality into the flash proxy, allowing the ones that are not behind nat to work as STUN and ICE servers for the others. Also, with the WebRTC already in use, it would be easy to port to NAT-PMP or UPnP, with I believe will be integrated into it in the future.
Now, on the regards of how well spread WebRTC is, it's already built into Firefox and Chrome, and they both interoperate( http://blog.chromium.org/2013/02/hello-firefox-this-is-chrome-calling.html).
On how much work it would demand: Some work would be required to enable the use of WebRTC in the javascript part of the flash proxy, and probably some parts will require rewriting, since the flash proxy will not operate in the same way anymore. The client plugin will need big changes, since it will need to connect via Data Channels, that is not trivial( https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-04#section-1), and most of the controlling would be done there. On the facilitator part, I believe only minor parts will require change, mostly to handle the flash proxy address giveaway(It should be controlled in some way, else an attacker could keep polling enough address to know the majority of them).
Well, that's about it, I'll be pleased to hear your opinions about it,
Greetings, Danilo
On Mon, Apr 29, 2013 at 02:02:19AM -0300, Danilo Carvalho wrote:
My name is Danilo Carvalho, I am from ITA, Brazil, and I'm thinking about enabling flash proxy to use WebRTC, specially Data Channels, to connect between the client and the flash proxy. Some of the benefits involved would be:
1 - Flash proxies now would be able to receive incoming connections, this would remove the current need for the flash proxy to connect to the client. With the client being able to connect to the flash proxy, ticket( https:// trac.torproject.org/projects/tor/ticket/5426) would be solved. If the client is the one controlling the connection, it wouldn't be needed for the flash proxy to guess his usage time.
What you say about incoming connections is likely true, but let's forget about it for now. The WebRTC project is about built-in NAT traversal, nothing more. Changing the connection model is an architectural change that may be worthwhile but I don't think it should be part of this project.
2 - We could use the built in resources of the WebRTC to do nat traversal, through ICE and STUN servers. Although it isn't quite right to use public, company-owned ICE and STUN servers for that, we could build that functionality into the flash proxy, allowing the ones that are not behind nat to work as STUN and ICE servers for the others. Also, with the WebRTC already in use, it would be easy to port to NAT-PMP or UPnP, with I believe will be integrated into it in the future.
I think you will have to elaborate on this idea. I don't see any problems with using public ICE and STUN servers (except that it's one more party we disclose usage of flash proxy to). I don't think we can run our own ICE or STUN server just for flash proxy because a censor can block it with no cost.
Is it really possible for a browser-based JavaScript program to act as an ICE or STUN server? I don't really know those protocols, but don't they involve sending UDP packets? There's no way to do that from a browser, as far as I know.
NAT-PMP and UPnP don't depend on WebRTC, do they? Couldn't we implement NAT-PMP and UPnP in flashproxy-client even using WebSocket?
On how much work it would demand: Some work would be required to enable the use of WebRTC in the javascript part of the flash proxy, and probably some parts will require rewriting, since the flash proxy will not operate in the same way anymore. The client plugin will need big changes, since it will need to connect via Data Channels, that is not trivial([3]https://tools.ietf.org/html/ draft-ietf-rtcweb-data-channel-04#section-1), and most of the controlling would be done there. On the facilitator part, I believe only minor parts will require change, mostly to handle the flash proxy address giveaway(It should be controlled in some way, else an attacker could keep polling enough address to know the majority of them).
Have you seen https://trac.torproject.org/projects/tor/ticket/5578? Much of this research has been done already, and we made a plan for a prototype implementation. A full implementation looks to be nontrivial and will probably take at least the summer.
David Fifield
-
Danilo Carvalho -
David Fifield