Proposal: HTTP and TCP Tunneling #142
Comments
Could you explain a bit more as to how what you're describing achieves this? E.g. let's say Bob (Public IP = If Alice (Public IP = Are you saying that now Alice's |
|
Yes, Alice would just access localhost:4444(For example's sake let's say
with a browser) and she would see whatever webpage Bob was hosting on his
machine, as long as Bob was running his end of the torrent tunneling
service.
For extra security on sites that were not public, the torrent files or
links could contain a PSK in addition to the certificate, so that you could
not even establish the torrent connection at all without actually having
the torrent file.
Unless Bob chose to publish that file publically, Alice would be the only
one who could access it.
Bob could also create multiple torrents for the same service, and give
Carol a different one, so that he had the option to later revoke individual
users just by deleting their torrent.
…On Thu, Sep 7, 2023, 1:13 AM Raghu Saxena ***@***.***> wrote:
There is clearly a lot of interest in things like ngrok, and a P2P
alternative would have many use cases.
Could you explain a bit more as to how what you're describing achieves
this?
E.g. let's say Bob (Public IP = 1.2.3.4) is running a webserver on
localhost:3000 . He then prepares a "webservice torrent" for this.
If Alice (Public IP = 8.8.8.8) wants to access this, she would acquire
the "webservice torrent" (for simplicity let's just assume Bob emails it to
her), add it to her client, and select a port e.g. 4444.
Are you saying that now Alice's localhost:4444 would be tunneled to Bob's
service running on his localhost:3000?
—
Reply to this email directly, view it on GitHub
<#142 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFZCH5NEHBTBOZUUFN6GOLXZFX3BANCNFSM6AAAAAA2HQT5CI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Well, where does the TCP connection happen then? I.e. how does a packet from Alice's computer (localhost:4444) get to Bob's service (i.e. his localhost:3000)?
I'm not sure I quite understand how Bob's service would be exposed for others to connect to over the internet, assuming he doesn't manually open any ports. Even BitTorrent behind an ISP which doesn't let you port-forward would only allow outgoing connections, so I don't see how torrents would solve it in a |
|
There's a lot of ways to implement it, but the one I had in mind was:
Bob's application discovers his own public IP address and application
port, and puts a record containing that address into the DHT, or into a
tracker.
The DHT key is the hash of the public key, salted with the current date for
a little extra privacy.
His application then uses UPNP to open that port on his local router.
Alice's application, upon detecting an incoming local connection, uses this
hash to look up Bob's public IP, and opens an encrypted connection to
Bob's computer through.
Data is forwarded over this encrypted connection.
Should the router not have UPNP, or the ISP do something to get in the
way, the usual hole punching methods(
https://stackoverflow.com/questions/37367769/how-nat-traversal-works-in-case-of-peer-to-peer-protocols-like-bittorrent)
can be used.
Essentially, the connection is established mostly the same way as normal
BitTorrent traffic.
…On Thu, Sep 7, 2023, 3:25 AM Raghu Saxena ***@***.***> wrote:
Well, where does the TCP connection happen then? I.e. how does a packet
from Alice's computer (localhost:4444) get to Bob's service (i.e. his
localhost:3000)?
ngrok etc. solve the problem of needing to open ports by basically making
a reverse tunnel, and they forward traffic on a Public IP with an open port
that they have.
I'm not sure I quite understand how Bob's service would be exposed for
others to connect to over the internet, assuming he doesn't manually open
any ports.
Even BitTorrent behind an ISP which doesn't let you port-forward would
only allow outgoing connections, so I don't see how torrents would solve it
in a ngrok like manner.
—
Reply to this email directly, view it on GitHub
<#142 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFZCHYTABMAN44EJKJM4HLXZGHJZANCNFSM6AAAAAA2HQT5CI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Right now, self hosted software cannot be fully automated well without being bound to some cloud service, due to the need for certificates, DNS, and firewall ports.
There is clearly a lot of interest in things like ngrok, and a P2P alternative would have many use cases.
I'm suggesting a standardized way to make a local service accessible over the web, in the same way torrents currently make files accessible.
In your torrent client, you would create a Webservice Torrent, that connects to a specific local port. This would produce a torrent file and public key hash, placed on the DHT as an updatable value under that key.
On the client side, one would import that torrent and be prompted to select a port on the client machine. The service would be tunneled to appear as if it were on the clients localhost on that port. The client software would periodically update the torrent file by looking on the DHT.
Alternatively, if the service is HTTP, the client could visit HASH.localhost, and the client software would intercept the header, and automatically set up an ephemeral tunnel for that connection, so that one could share links like regular URLs.
All communication could be done via TLS, with the server certificate self signed, and embedded right in the the torrent.
Similarly, the servers WAN IPs would be embedded in the torrent file for instant setup.
This would allow for just about any service to be self hosted in only a few clicks provided the client had the app, greatly simplifying IoT.
The text was updated successfully, but these errors were encountered: