Universal Browser Connectivity using HTTPS/Secure Websockets

[marten-seemann]

Every (public) node should have a Subdomain and a trusted TLS certificate, so that browser nodes can connect using /wss (Secure WebSockets transport).

We will support manual certificate configuration, and ACME automation for user’s domain names (see #1331 for details), but these setups require some manual step/input from the user.

Here, we discuss a protocol for providing TLS cert for /wss for all remaining nodes in a way that happens automatically, without user’s involvement.

Obtaining a Certificate using the DNS01 ACME Challenge

For the purpose of this discussion, let’s assume that we have one PL-controlled "gatekeeper" node that has (programmatic) access to the DNS configuration of libp2p.direct (or some other domain).

1. The gatekeeper node is run by PL and has a fixed DNS name, e.g.dns.libp2p.direct.
2. When a node wants to get a certificate, it requests a subdomain name from the gatekeeper.
3. The gatekeeper then generates a new subdomain: <subdomain>.libp2p.direct.
   • TBD: this could be a random string, or a certain encoding of the peer ID.
4. The node then runs its ACME client and requests a DNS-01 challenge from LE. It forwards the ACME challenge to the gatekeeper via a yet-to-defined libp2p protocol.
5. The gatekeeper verifies the ACME challenge (i.e. checks the subdomain, that it is well-formed, etc.) and publishes the TXT record. It un-publishes the TXT record when the ACME challenge is done, or after the expiration of a short timer (10 minutes?).
6. LE now issues a certificate directly to the nodes’ ACME client.
7. The node can now advertise <ip-multiaddr>.<subdomain>.libp2p.direct. Our DNS resolver makes sure that this resolves to <ip>.

Steps

• [x] implement a DNS server that can
  • resolve ..libp2p.directto`
  • programmatically set the TXT records for the ACME challenge
  • Done in: https://github.com/marten-seemann/wildcard-dns
• [ ] coordinate with LetsEncrypt (or ZeroSSL) that we can get an unlimited number of wildcard certificates for subdomains of libp2p.direct
• [ ] transfer ownership of libp2p.direct to the infrastructure team (earliest possible date: Apr 24)
• [ ] specify and implement a libp2p protocol to request a subdomain from the gatekeeper and to set TXT records
• [ ] integrate into go-ws-transport, so we can use and advertise /wss addresses

[thattommyhall]

I've requested the Pathfinder team at PL to contact @marten-seemann about transferring the domain

[marten-seemann]

Closing, since we now have WebTransport and that's 100x better than WebSocket. Specifically, it doesn't require any DNS setup.

[aschmahmann]

I'm reopening this issue. While there's been a lot of progress on WebTransport as a whole and (go-)libp2p's WebRTC implementation in the last year using those transports browsers is still tough:

• https://github.com/libp2p/js-libp2p/issues/2572
• https://github.com/libp2p/js-libp2p/issues/2592

Given that the major browsers seem to be much more reliable at handling HTTP(S) and WS(S) finding a way to be able to use those transports in a p2p context would be a major unblocker for users wanting to build distributed p2p applications that are accessible from browsers.

Note: libp2p's HTTP story has also improved a lot in the last year so this issue has been renamed to cover both HTTPS and WSS although the mechanics required are the same for both. Although I've left Marten's initial post alone

[marten-seemann]

While there's been a lot of progress on WebTransport as a whole

Unfortunately, things are not as rosy on the implementation side. Due to a persistent lack of funding, development of webtransport-go was paused indefinitely: https://github.com/quic-go/webtransport-go/pull/156/files

This means that WebTransport support will break as soon as browsers update to a new IETF draft version.