HTTP/3 Far from Ready September 27, 2019

Both Firefox and Chrome recently announced plans to support the HTTP/3 protocol - a new transport layer protocol that redefines, yet again, how browsers communicate with web servers. With an extra push from Cloudflare, like what they did with HTTP/2, one can only expect an accelerated adoption of HTTP/3.

But hold your horse, cool your jet, or whatever you say to curb your excitement. The switch from HTTP/2 to HTTP/3 may be one day as simple as a keyword in the Nginx configuration script, or a checkbox in some web control panel. However, the implications of using HTTP/3 must be well understood. Looking at today's web landscape, we think that HTTP/3 has a long way to go.

UDP Routeability

HTTP/3 is fundamentally different from HTTP/2 in that it is sitting on QUIC, a protocol that's based on UDP. QUIC implements many TCP features such as reliability, in order delivery and congestion flow control. In addition, QUIC supports multiple logical streams, each has its own flow control.

Despite all these fancy features, we should not forget the essence of QUIC and by association HTTP/3 - that is, it is UDP. In many corporate firewalls, the only open UDP port is 53, used by the DNS to resolve domain addresses. Other UDP applications such as video streaming and P2P file sharing have given the UDP protocol a somewhat naughty reputation. As a result, UDP traffic tend not to be as routeable as TCP.

UDP Performance

Another issue with UDP is its performance on the OS level. There is simply far more engineering hours put in TCP. The TCP stack in Linux is far more optimized than UDP. Until the introduction of QUIC, UDP has not been used in web traffic, so it is impossible that UDP is optimized for the web context.

Server Resource Considerations

QUIC is a complex protocol at its infancy. All of the QUIC implementations at the time of this writing are in user land. An HTTP/3 server requires twice as much CPU resource as an HTTP/2 server. All things considered, in simple words, HTTP/3 is costly and not worth it.

General Security Issues

The power of QUIC and HTTP/3 come from a well-orchestrated dance among many components. Having too many moving parts is precisely a source of vulnerability. Multi-stream in-order delivery and per-stream congestion control are prime targets for denial of service styled exploitation. The protocols may be carefully designed but it will take a long time for various implementations to go through a hardening process.

Alt-Svc Abuse

Nearly all introduction material on HTTP/3 states the main structural difference between HTTP/2 and HTTP/3. We have also pointed out at the beginning of this article that HTTP/2 implements its features on the application layer, whereas HTTP/3, though itself being on the application layer, relies on QUIC, which is on the transport layer.

Now let's translate this difference in the context of protocol upgrade. When a browser contacts the server for the first time, it has no idea whether HTTP/2 is supported. Through an extension in TLS, the browser is informed of the server's added capability during the HTTPS handshake.

HTTP/3 works differently. It relies on the alt-svc server-side header to inform the browser that an HTTP/3 UDP port exists, probably even on a different host. Keep in mind that the alt-svc header has been around much longer than QUIC. It is only now repurposed by HTTP/3 to perform a protocol escalation.

What if alt-svc is abused for routing traffic to a different server? It turns out we are not alone in thinking this. This article confirms that alt-svc provides a DDOS attack platform that is almost trivial.

Connection Caching Complication

QUIC is more suited for HTTP traffic than TCP, even though QUIC can be used for other applications. Establishing a TCP connection takes three steps, or one round trip. This is contrary to some common misconception that TCP takes three round trips to get started. Still, QUIC can start transmission without a handshake, also known as RTT0. This is only possible when a server is previously contacted and trusted by a browser.

A TCP session is like a court proceeding where every party addresses each other formally. The handshake overhead can be at times unbearable.

QUIC on the other hand is like two friends setting in the same room having a casual conversation. After a short silence, one person may add to a previous chat, and the other person can apply the already-establish context. This is where efficiency comes in.

Unfortunately, we are again dealing with a very different web reality. QUIC RTT0 makes the assumption that the server does not move within the RTT0 expiry, and that there is not going to be a proxy in-between, or the UDP path stays viable as the browser switches from Wifi to cell.

At best, an RTT0 handshake may fail and cause extra round trips. At worst, either the browser or the server can be maliciously confused, as illustrated in this article.

In conclusion, the many unique features of HTTP/3 and QUIC are not enough reasons for us to even get excited. The adoption rate of QUIC is still low, and HTTP/3 is even a smaller part of it. For now, let's just sit back and wait for QUIC and HTTP/3 to mature.