[tor-talk] WebRTC to uncover local IP

[Christian Gagneraud]

On 30/01/15 11:36, Aymeric Vitte wrote:
>
> Le 29/01/2015 22:20, isis a écrit :
>> Even better than disabling it, the Tor Browser Team really needs help
>> from
>> someone with a really strong knowledge of WebRTC and its potential
>> privacy
>> caveats to help us assess which parts of WebRTC (if any) that we might
>> be able
>> to safely allow.  The reason it's entirely disabled is because we know
>> some
>> parts are unsafe, and sadly we didn't have the time/resources to sort out
>> which parts are which. :/
>
> I thought that the Tor project team had already a strong knowledge of
> WebRTC since recently we saw that the future might be flashproxy
> combined with uProxy (then WebRTC) to do something unstoppable.
>
> Some time ago I made [1], this drawing is supposed to explain simply how
> WebRTC works and at that time just leaded to the conclusion that the
> signaling servers are the perfect MITM and that the STUN servers can
> correlate the connections, then the IPs.

You forgot to give the url.

>
> But the signaling servers are not mandatory finally, WebRTC peers can
> introduce each others, but you still need some servers accessed usually
> via WebSockets to bootstrap the process, these are the concepts of
> projects like Peersm (which at the same time solves the issue of WebRTC
> DTLS self signed certificates) and WebTorrent.
>
> I did not study it deeply but in the strict context of the current Tor
> Browser, I think that nothing is safe in WebRTC, and it should be
> entirely disabled.
>
> Another more interesting idea that I have repeatedly posted without
> getting any feedback would be to allow to set the browser's proxy to an
> interface, like WebSockets or WebRTC.
>
> Example: let's take the proxy auto config mechanism, the pac file (let's
> forget about the security aspects to retrieve it here) which contains
> findproxyforurl is sandboxed and executed inside browsers, it is called
> by the proxy and returns an url.
>
> Instead of returning an url, you could have the Tor protocol inside the
> pac file (so sandboxed too) and it could return an Object, the Tor
> protocol would establish circuits via WebSockets or WebRTC with the Tor
> network or between browsers, the proxy would use the Object to write to
> those circuits and read from them (like a duplex stream
> proxy.pipe(Object).pipe(proxy))
>
> The interest would be to have Tor on any device, I am not saying that
> the pac file could be a solution, that's just an example of how this
> could work based on what exists today, now still remains the issue of
> implementing all of what the Tor Browser is doing, but it's still
> interesting to study, it certainly applies to projects mentioned above
> and plenty of others, now or later.
>