[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #5578 [Flashproxy]: Investigate WebRTC for flash proxy NAT punching
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs