[tor-dev] GSoC 2013: Enable flashproxy to use WebRTC

[Danilo Carvalho]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130429/a7c1c65b/attachment.html>