Private Gateways

[Winterhuman]

Private Gateways

Note: This idea will be significantly reworked in future, encrypting with the PeerID of the Listener is not good for security and so will be replaced with better means, for now this discussion is kept for historical purposes.

Intro

(See Dusk-Labs/dim#175 for use-case)

For the above example, Dim is a media manager, they want to expose their service on a server such that the user can access their media outside of their LAN, but, they need to be the only ones able to access it. How do we accomplish this?

Solution

Currently, gateways are trusted by entering their domains into the trusted gateways list and using their public keys to encrypt the Manifest's ciphertext, however, gateways embedded within apps have neither of these and so Private Gateways get around this.

Instead of trusting specific gateways, we can accept any gateway which knows a secret needed to decrypt the ciphertext.

1. ipns-link gen my-site
2. ipns-link config my-site
3. ipns-link expose -g all|trusted|private my-site

• all (Default): Ciphertext is encrypted with string ipns-link thus trusting all gateways.
• trusted: Ciphertext is encrypted with the public keys of trusted gateways thus only trusting trusted gateways.
• private: Ciphertext is encrypted with the PeerID of the Listener node thus only gateways which know the PeerID are trusted.

For a Private Gateway to find the Origin, it will ask you to enter the IPNS address of the service and the PeerID of the Listener node. For apps with embedded Private Gateways, the IPNS of the service and the PeerID could be combined into a QR code for the app to scan. To revoke a Private Gateway's access, you can run ipns-link -n daemon to generate a new PeerID for the Listener node, Private Gateways would then be unable to use the old multiaddresses of the Listener and would need the new PeerID to read the ciphertext to find the new multiaddresses.

Here's an example Manifest for if -g private is used, since no specific gateway is trusted the <meta> and <a> sections are removed from the Manifest:

<!--IPNS-Link--
ciphertext in multibase (base64, inline)  [Encrypted by PeerID of Listener node]
--IPNS-Link-->

[SomajitDey]

@LynHyper Thanks for providing 401.jpg.

[SomajitDey]

@LynHyper During implementation I noticed that the redirect URL is causing a few problems, to resolve which we gotta bloat the manifest with keywords and stuff. The main problem lies with this: when a gateway fails to decrypt the ciphertext, is the URL below it a public site or a trusted gateway? In case it is a trusted gateway it should be redirected to as https://gateway.tld/ipns/ipnskey/path, otherwise it would simply be redirected as https://public.site - so the resolution is necessary.

Most of the gateway is already implemented. Adding new keywords to enable such resolution would complicate things at this moment. I suggest we leave the redirect URL out....After all, chances are that any user who gets to know the IPNS-key of the hidden service would also know its public site. So, on failing to decipher, let any gateway just show your 401.html file.

Also I realized this. Once a gateway decrypts the Manifest, it stores the multiaddress of the Listener in its cache. Hence, even if you change the secret while re-exposing your http-server, unless you do not change the PeerID of the Listener too, there's a chance the cached multiaddress would work, e.g. if the Listener is using the same Relay or has a static IP. So changing a secret doesn't give you any security unless you change the peerID of the listener too, thus invalidating all prior caches. In view of this, why can't Listener's PeerID itself serve as the secret? It's long and random, has every desirable quality of being a great secret and the best thing is no one can link it with the exposed IPNS-Key apriori.

If we go with the above then the user no more needs to configure any local.private.secret or local.private.on_fail. What I suggest is this. Simply add a -g option for the expose command and a -n option for the daemon command.

ipns-link expose [ -g=private | trusted | all ] <IPNS-key-name>
If -g=private, the user is immediately shown the PeerID of the listener that he passes to his desired end-users, and the exposer encrypts with that as the secret.
If -g=trusted, the exposer encrypts for trusted gateways.
If -g=all, the exposer encrypts with "ipns-link" as usual.

Note that this avoids breaking changes as well.

To generate a new PeerID when launching the daemon.
ipns-link -n daemon
We are not generating new PeerID's by default as for -g=all case (default), we don't wanna invalidate any existing caches.