Investigate WebRTC with TCP-ICE and hidden services

[mikeperry]

Mozilla added support for WebRTC over TCP, and WebRTC proxy support in Firefox 34 and 38:
​https://bugzilla.mozilla.org/show_bug.cgi?id=891551
​https://bugzilla.mozilla.org/show_bug.cgi?id=949703

This might mean we can actually enable WebRTC now, if we turn off all of the IP address discovery and non-TCP ICE mechanisms: ​https://github.com/diafygi/webrtc-ips

We could also potentially list a hidden service address as a WebRTC ICE endpoint, though we would need to be careful about this since it means that potentially every Tor Browser user who visits a WebRTC-enabled page would suddenly spin up a hidden service. I wonder if we can have Tor create the keys for a hidden service without actually starting it up unless it is actually negotiated by WebRTC. OTOH, it may not be helpful to have an address that isn't accessible yet. I suppose it depends on how the ICE handshake works and how addresses are tried/negotiated.

This suggestion actually came from wiretapped (leif). WebRTC is no longer just for making calls. Tons of crazy decentralized apps are being built on top of it. Ex: ​https://instant.io/

[mikeperry]

Skimming some docs makes it seem like it may be possible to advertise a non-running HS address before agreeing to use it (​http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/ is very good).

However, it also sounds like signaling/call setup is going to be very custom and webapp dependent. It is likely that many WebRTC apps will simply barf if they see an onion address instead of an IPv4 address passed through their signaling systems . But it sounds like well-designed apps should theoretically be able to handle non-live onion address negotiation properly, in a way that will also allow us to bring up the hidden service only when it has actually been negotiated by both parties.

[gk]

Replying to mikeperry:

Mozilla added support for WebRTC over TCP, and WebRTC proxy support in Firefox 34 and 38:
​https://bugzilla.mozilla.org/show_bug.cgi?id=891551

Well, parts of that bug got fixed, yes, but the important one, part 5, which is adding support for TCP candidates has not even landed on mozilla-central yet it seems. Thus, this won't be in scope for ESR 38 then given the code complexities, I think.

[cypherpunks]

Replying to mikeperry:

Skimming some docs makes it seem like it may be possible to advertise a non-running HS address before agreeing to use it

Is this just to prevent hidden services from being silently created when the user doesn't want them?

I don't think it's necessary or desirable to do something with an ephemeral onion address before publishing its descriptor to the HSDirs. Instead, I think when a website tries to initiate WebRTC in Tor Browser it should initially fail (as it does now) but prompt the user (with the standard permissions prompt, like it does for canvas reads) asking something like "Do you want to allow incoming connections to your browser while you're viewing this site?". If the user says yes, an ephemeral onion should be created and the page should reload.

[zyan]

If there's anything you need from the WebRTC spec in order to do this, let me know. We (the W3C technical architecture group) is in the process of doing a webrtc review.

[gk]

While this is worthwhile this is not related to ESR45 in particular.

[bugzilla]

Seems Mozilla has discovered what Proxy Obedience means: ​https://hg.mozilla.org/mozilla-central/rev/f17f59899b31.

[gk]

​https://bugzilla.mozilla.org/show_bug.cgi?id=1176382 seems relevant. In particular ​https://bugzilla.mozilla.org/show_bug.cgi?id=1179345 needs to land first at least for this to work with e10s.

[gk]

But see: ​https://blog.mozilla.org/webrtc/active-ice-tcp-punch-firewalls-directly/

[cypherpunks]

There is a lot of awesome p2p stuff happening with WebRTC nowadays, and Tor Browser is left out of all of this. Is anyone working on building ephemeral hidden service WebRTC integration?

​https://github.com/Chocobozzz/PeerTube is one example awesome webrtc thing that actually does work with Tor Browser today, albeit not with webrtc, so, Tor users are all leeches (only able to get the video from the peertube instance's server, which typically has limited resources) Ideally TBB users could connect to eachother's onions, but, even lacking that, it would at least be nice of TBB users could make outbound connections to peers even if they can't receive inbound connections.

js-ipfs is also nice but also requires WebRTC.

PLZ CAN HAZ NICE THINGS?

[gk]

Replying to cypherpunks:

PLZ CAN HAZ NICE THINGS?

PLZ CAN HAZ NICE PATCHES?

[gk]

Here is where we are when we switch to ESR 60: ​https://blog.mozilla.org/webrtc/active-ice-tcp-punch-firewalls-directly/.

[HostFat]

Well, Tor Browser v8.0 is arriving, another step forward.

I see that there are updates here:
​https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/

Will it change more with the v1.0 webrtc spec at the end of the year?

[araigumaG]

IMHO, connection with TCP-ICE Candidate is not suitable for concept of Tor Browser. Nevertheless, The concept of using WebRTC over Tor still seems alive.

Conceivable problem of privacy.

As gk said above, TCP ICE candidate is the concept for enable direct connection over TCP. People seems to use this method under relatively simple circumstance (e.g. both ends of peer are in same LAN, or they have each of global IP).

Therefore, in this situation, Tor Browser tells the IP addrress of itself. This seems to be nothing but what people call "WebRTC Leak". I suppose that this scenario is not suitable for the concept of Tor Browser.

Another option for establishing WebRTC connection over Tor(?)

Fortunately, I can show somethings like ideas of the method which enables Tor Browser to use WebRTC:

1. use TURN

WebRTC (ICE) has TURN option. TURN relay the connection, and TURN server can communicate with the browser in TCP. Firefox already has the option(media.peerconnection.ice.relay_only, more information ​here) to force it to use relay (TURN).

I'm afraid to say, this approach is not perfect. The connection between the browser and TURN server can also be over UDP (or TLS over TCP). In conclusion, if tbb make the method possible, the option for banning transport over UDP.

2. use STUN, and TCP connection (not well considered)

I think why cannot we use STUN for TCP connection when the idea of direct TCP connection exist. AFAIK, the specification of STUN (​RFC 5389) said that using STUN in TCP connection is a possible scenario.

Needless to say, this method also needs "Don't use UDP" option.

In any case, given that Tor cannot use UDP, we should find the method using TCP (or TLS) to use WebRTC.

Thank you for your reading.