In principle, it should be possible to run a QUIC and a WebTransport listener on the same IP / port.

In practice, this is how this would play out:

1. We accept a new incoming connection. The GetConfigForClient callback of the tls.Config is called.
2. In this callback, we have access to the ALPN that the client sent. If the ALPN is “libp2p”, we select a config that serves the libp2p-tls certificate and requires client auth. If the ALPN is HTTP/3, we use a config that serves the webtransport certificate, which doesn’t require client auth.
3. Once a QUIC connection is established, we either use it ourselves (for QUIC) or pass it to the WebTransport stack. This might require some refactoring in quic-go / webtransport-go.

Privacy Implications

There’ve been proposals to use the HTTP/3 ALPN instead of “libp2p”, to avoid observers from identifying libp2p connections. This clashes with this proposal, since it uses ALPN to decide which certificate to use and how to proceed with an established connection.

One might argue that this proposal was suboptimal to begin with. Using the HTTP/3 ALPN, but then not speaking HTTP/3 certainly isn’t the cleanest approach.

On the other hand, simply using WebTransport should be an acceptable tradeoff for peers that wish to evade ALPN-based censorship. Of course, there’s also ECH on the horizon, which would encrypt the entire ClientHello (including the ALPN values), which would allow such clients to use pure QUIC.

Implementation Considerations

It’s possible to add listen addresses at any point. Any solution we adopt needs to be handle initialization of QUIC and WebTransport in arbitrary order, with arbitrary time in between. This will probably make it necessary to introduce a more abstract QUIC / WebTransport listener, that’s then used by both transports.

Progress:

• http3: add http3.Server.ServeQUICConn to serve a single QUIC connection quic-go/quic-go#3579
• http3: expose ALPN values quic-go/quic-go#3580