Proposal: HTTP and TCP Tunneling

[EternityForest]

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.

[ckcr4lyf]

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?

[EternityForest]

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 https://github.com/bittorrent/bittorrent.org/issues/142#issuecomment-1709601136, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFZCH5NEHBTBOZUUFN6GOLXZFX3BANCNFSM6AAAAAA2HQT5CI . You are receiving this because you authored the thread.Message ID: @.***>

[ckcr4lyf]

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.

[EternityForest]

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 https://github.com/bittorrent/bittorrent.org/issues/142#issuecomment-1709804193, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFZCHYTABMAN44EJKJM4HLXZGHJZANCNFSM6AAAAAA2HQT5CI . You are receiving this because you authored the thread.Message ID: @.***>