[tor-talk] WebRTC to uncover local IP

[Aymeric Vitte]

Indeed, thanks, the link is http://www.peersm.com/img/webrtc.png

But looking at it since this drawing is now out of its context I am 
afraid that it could be somewhere confusing.

This was an attempt to see how to combine WebRTC signaling with an 
anonymizer network, in order not to be mitmed by the signaling server 
(ORDB in the drawing) Alice and Bob need to encrypt their IP:port, which 
means that they should share a secret, know each other, etc, which is 
difficult and not very realistic.

I think the concepts of WebRTC with an anonymizer network are better 
explained now here: 
https://github.com/Ayms/node-Tor#anonymous-serverless-p2p-inside-browsers---peersm-specs

But this project can only fetch, not browse, that's why I am thinking to 
something like the proxy concepts explained below.

Le 29/01/2015 23:58, Christian Gagneraud a écrit :
> 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.
>>
>

-- 
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms