Enabling /wss in go-ipfs

[lidel]

Current state

Ideally, browser nodes should be able to dial go-ipfs nodes over /wss.

We already have /ws and /wss support in go-ipfs, however setup is complex: requires a reverse proxy in front of go-ipfs to handle certs and terminate TLS befor passing to /ws in go-ipfs.

Ideally, go-ipfs would listen on /wss without the need for a reverse proxy.
The missing part is to add TLS cert magic for peers that are publicly diallable.

Notes on improving /wss situation

• We should enable /ws on localhost by default (Enable the websocket listener by default kubo#5251 (comment))
• Injection of self-signed certs is something we should never touch – brittle, and often gets false-positive from antivirust/security software, and it is hard to get removed from those badliststs once your binary gets listed on them.
• There is a safe route, where user brings their own domain: Cert could be obtained automatically via ACME protocol and Let's Encrypt when user enables transport by adding DNS addr like /dns/some.example.com/tcp/4423/wss to Addresses.Swarm.
  • I believe this is safe to implement because it does not abuse CA in any way (user has to opt-in with the domain they own).
  • ACME automation would be enabled when Addresses.Swarm has /dns*/example.com/../wss/ and ACME.Endpoints map has mapping example.com → https://acme -endpoint
  • Having this, we could demonstrate value to CA like Let's Encrypt and look into full automation (next step)
• Fully automatic route is tricky: We could provide a hostname for each peer, most likely via our own version of a service like http://xip.io/ – this way user would not have to opt-in, and /wss could be enabled automatically.
  • The caveat here is that ToS of Let's Encrypt and other providers most likely guard against this type of "delegated cert mining" (either directly, or have some vague clauses about generating a cert for a third-party being bad). We should reach out to Let's Encrypt or other CA that provides ACME and confirm they are okay with the way we want to use this before this is even explored.
  • Potential solution (at least for consumer ISP/NAT setups) is to do reverse-DNS lookup to learn about domain name provided by ISP and if present, use uPNP to configure port forwarding for port 80 (routers seem to allow forwarding low ports on external interface – main limitation is to use >1024 on the inside)
    • PoC by @achingbrain

Broad strokes plan (TBD)

This is TBD, please comment below if there is a better way.

Stage 0: bring your own certs for TLS

As suggested by @whyrusleeping:

We could add a /wss transport that takes in your certs

This would include part of work required for Stage 1, and be useful for people who don't want to use ACME for some reason.

Stage 1: bring your own domain for TLS

Seamless ACME support to go-ipfs and js-ipfs: entering /dns4/.../wss/ addr in Addresses.Swarm and setting up ACME endpoint for the domain name in something like TLS.ACME.Endpoints is all the user needs to do to have Secure WebSockets transport enabled.

Because a dedicated domain is used go-ipfs could prove ownership by completing HTTP-01 Challenge. It is fairly well understood and full automation only requires port 80 of used domain to point at go-ipfs instance.

Stage 2: you get a free domain for TLS out-of-the-box

We may need to provide peers with something like {peerid}.libp2p-peer.io name for TLS and partner with ACME provider to ensure that mining TLS certs for third-parties under our name like that is ok.

It could also be leveraging the reverse-DNS lookup + uPnP forwarding trick to piggy-back on domain name provided by ISP.

References

• Enable the websocket listener by default Enable the websocket listener by default kubo#5251