https://github.com/eyedeekay/samrtc
Enable webRTC on i2p. Create a tunnel to your own SAM bridge over i2p with whitelisting for the local destination. DANGER: Of all the potentially stupid things I have done with i2p, this is probably the most risky.
https://github.com/eyedeekay/samrtc
Last synced: 6 months ago
JSON representation
Enable webRTC on i2p. Create a tunnel to your own SAM bridge over i2p with whitelisting for the local destination. DANGER: Of all the potentially stupid things I have done with i2p, this is probably the most risky.
- Host: GitHub
- URL: https://github.com/eyedeekay/samrtc
- Owner: eyedeekay
- License: mit
- Created: 2018-07-15T23:24:50.000Z (over 7 years ago)
- Default Branch: master
- Last Pushed: 2018-08-07T22:40:46.000Z (about 7 years ago)
- Last Synced: 2025-04-19T03:34:41.404Z (7 months ago)
- Language: Go
- Size: 2.81 MB
- Stars: 6
- Watchers: 4
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
- awesome-i2p - samrtc - webRTC over I2P via SAM. (Libraries / Other)
README
# samrtc(Experiments with making webRTC applications use the SAM bridge, in particular WebTorrent)
**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.
## Status
Broke the absolute shit out of it in order to make it much easier to work with
later.
## About
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](https://github.com/eyedeekay/si-i2p-plugin)
project, I establish browser connections over the SAM bridge as well. I plan
to incorporate this into that application.
## This diagram shows the basic idea
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.