[guardian-dev] WebRTC

[Timur Mehrvarz]

On 07/31/2013 04:44 PM, Daniel Pocock wrote:
> On 31/07/13 16:29, Timur Mehrvarz wrote:
>> On 07/30/2013 04:17 PM, Nathan of Guardian wrote:
>>> While the idea of peer-to-peer always seems great initially, if you are
>>> unable to route that through Tor, or bounce it off a middle mix server
>>> of some sort to mask end-points, I hesitate from adopting that as a tool
>>> for activists and journalists, say, who need to protect their networks
>>> and sources.
>> Actually, WebRTC traffic does *not have* to travel peer-to-peer. It can
>> also be pushed through proxies. Probably even through TOR. (Does TOR
>> route UDP?)
> 
> 
> The bigger question: do you want to risk an arbitrary ICE client such as
> a browser discovering all the local addresses and sending them to the
> peer?  It defeats the purpose of TOR
> 
> For ICE to find the optimal connectivity path, it implicitly has to
> share topology information between the two endpoints. 

You don't have to use ICE/TURN. The WebRTC app can choose any
infrastructure it likes. If used in non-p2p fashion, there is no need
for the agents to share (or even be aware of) each others addresses or
topology. The only "original" info visible to the other side may be the
UDP port. Which has to do with the hole punching mechanism.

The bigger problem (when using WebRTC through TOR) is not routing UDP
traffic. But matching two clients. This is much simpler, if both sides
happen to use the same relay server. Which is easy to achieve, if the
party providing the web server (that is hosting the WebRTC app) will
also offer the relay server.

Using WebRTC through TOR would require some kind of (TOR compatible)
advertising+discovery mechanism. But all three options should be
possible: p2p, relayed, routed through TOR.

I'm still not sure if I can/should trust the browser encrypting WebRTC
traffic.