[tor-bugs] #5578 [Flashproxy]: Investigate WebRTC for flash proxy NAT punching

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Feb 26 06:23:36 UTC 2013


#5578: Investigate WebRTC for flash proxy NAT punching
------------------------+---------------------------------------------------
 Reporter:  dcf         |          Owner:  dcf
     Type:  task        |         Status:  new
 Priority:  normal      |      Milestone:     
Component:  Flashproxy  |        Version:     
 Keywords:              |         Parent:     
   Points:              |   Actualpoints:     
------------------------+---------------------------------------------------
Changes (by dcf):

  * priority:  minor => normal


Comment:

 Replying to [comment:8 cjb]:
 > The largest problem is how the client transport plugin is going to work,
 because there's not yet any headless WebRTC implementation; it's very
 attached to the DOM.  I'd been assuming that node.js will grow a library
 that speaks WebRTC across each of Firefox/Chrome/node with a common API --
 socket.io does this for websockets -- but the requirements for WebRTC are
 far greater.  Ideally you need a full libjingle port, and at the least you
 need ICE and SCTP.  Node currently doesn't have any SCTP support, as far
 as I can see.
 >
 > So our options include waiting for node to grow a lot of code that
 doesn't exist right now, or having the client transport plugin be written
 in C instead of node and linked with libjingle, or finding a way to avoid
 having a full client transport plugin.

 WebRTC is more complicated than I thought. All the things you mention are
 doable, but it sounds like a big development effort.

 I'd rather not have new code written in C. Even if we have to link with C
 libraries, we should find a way to do it in a safer language.

 > Ben's suggestion for avoiding a client transport plugin is that the
 plugin could be a SOCKS-style proxy that bounces the data back into the
 local browser through a websocket on the local machine, and some
 JavaScript in the browser handles brokering between the websocket and an
 outgoing WebRTC datachannel.

 This works, but only as a prototype. I don't want to deploy the "browser-
 as-transport" because it's confusing and leads to mistakes. From the
 user's point of view, you launch your TBB, that's fine, but then for some
 reason you also have to have another browser open, that is ''not'' a TBB,
 and then you have to remember to do your anonymous browsing in one and not
 the other.

 We did something like the above a long time ago when we still used Flash,
 in order to use the Adobe RTMFP transport, which has uses similar to those
 of WebRTC. Our implementation let you register either an IP address or an
 RTMFP address, and then the proxy code used either a TCP socket or a
 socket abstraction over RTMFP. I didn't like it for the reasons above,
 plus the fact that it required running proprietary code on the client.
 (Plus the fact that the code was the same program as the flash proxy code,
 just with a different query string, which was ''way'' confusing. Try
 explaining ''that'' to anyone: "No, the flash proxy runs outside the
 firewall, where it can reach the Tor relay. Well, technically it also runs
 inside the firewall, but that's only for the sake of code reuse.")

 Anyway, here's the ancient RTMFP branch in case it's useful.
 https://gitweb.torproject.org/flashproxy.git/shortlog/refs/heads/rtmfp

 I'm fine if we have an implementation of WebRTC that only does the things
 we need. I realize though, that this may still be most of the hard parts.
 Perhaps an implementation could be pulled out of a browser too.

 Suppose we used the unreliable transport as if it were reliable. What
 could go wrong? If a packet gets dropped or duplicated, it will get
 noticed by the integrity checks in lower-level crypto. It seems the worst
 is that some of your circuits would get killed, if you're dropping
 packets.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5578#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list