HIGHLY EXPERIMENTAL. IF I MAKE A MISTAKE SECURING THIS APPLICATION, I COULD ACCIDENTALLY EXPOSE YOUR SAM PORT TO THE WHOLE I2P NETWORK. IF SOMEONE FINDS IT, THEY CAN USE YOUR I2P ROUTER TO CREATE NEW CONNECTIONS, SEND MESSAGES, AND A WHOLE BUNCH OF OTHER STUFF AS YOU. DO NOT DEPEND ON IT FOR ANONYMITY UNTIL DESTINATION WHITELISTING IS IMPLEMENTED COMPLETELY, WITH 100% TEST COVERAGE AND LOTS OF DOGFOODING BY ME. That said, I can't stop you.
Enable WebTorrent on i2p. Create a tunnel to your own SAM port over i2p with whitelisting for the local destination.
Broke the absolute shit out of it in order to make it much easier to work with later.
First of all, sure, it's possible to proxy WebRTC over a regular SOCKS proxy or whatever. But when it comes to the more interesting WebRTC applications, it appears to me that this approach would be very limiting. Many WebTorrent-based applications would be problematic in this scenario, for instance. A better idea, I think, would be to make it possible for WebRTC Applications to use the safer i2p API's like the SAM port to make connections. But the obvious problem arises, when in a properly configured browser, unproxied connections to the localhost are disabled, which means that javascript in the browser can't talk to the SAM port directly, and that's the right thing to do. Otherwise, one could be attacked by making requests for resources from local services.
So, how do we make it possible for our browser, and only our browser, to talk to our SAM port, and only our SAM port? Well, we could forward the SAM port to an i2p destination, with the destination of the proxy we're using as the only allowed connection, using the i2cp.accessList and i2cp.enableAccessList options. That would allow applications in the browser to connect to the SAM bridge using a .b32.i2p destination, which could be added to the local addressbook in a bunch of ways, I haven't decided yet, which would allow modified webRTC applications to use the SAM bridge to establish connections over i2p.
What this application is intended to do is to automate the process of creating the zero-hop forwarding tunnel to the SAM port and an API for exchanging whitelist destination information. That way you have a fast tunnel leading back to your own SAM port that only you can talk to for youe webRTC-enabled applications to use safely, which would also use only direct connections to itself so it would be as fast as possible. I think a kind of attack here could be possible, because I don't want a WebTorrent application to be able to determine what i2cp and streaming library options to use. Those need to be set by the samrtc application, and some kind of sanitization is probably necessary.
One thing I'm pretty sure you could also do if I'm successful is use Privoxy with two i2p proxy connections, one with your desired number of anonymous hops, and one with zero hops to use to connect to your own SAM destination. I'll put an example here as soon as I do one.
In my destination-isolation project, I establish browser connections over the SAM bridge as well. I plan to incorporate this into that application.
sam port+-->samrtc service+-->i2p network+{browser i2p tunnel talks to this destination}
| |
(exchange destination whitelists)+ |{zero-hops tunnel}
| |
browser +-->samrtc enabled client+-->i2p network+{WebTorrent client connects to this destination}
The drawback, however, is it's only half of what you need. The other half is, unfortunately, that the procedure is no longer generic. Instead, you need to modify the webRTC applications and libraries to use the SAM Bridge to establish connections over i2p instead.