ANALYSIS The HTTP/3 protocol has received RFC 9114 standardization – a boost for internet security, but not one without hurdles for web developers.
This week, the Internet Engineering Task Force (IETF) released HTTP/3, published as RFC 9114.
The HTTP protocol is the backbone of the web. The Hypertext Transfer Protocol (HTTP) acts as an application layer for facilitating communication between servers and browsers, fetching resources, and transferring data. HTTPS is HTTP with additional security via encryption.
HTTP/3 is the latest revision of the HTTP protocol, taking over from 2015’s HTTP/2. HTTP/3 is designed to address some of the performance issues inherent in HTTP/2, improving the user experience, decreasing the impact of packet loss without head-of-line blocking, speeding up handshake requirements, and enabling encryption by default.
The protocol utilizes space congestion control over User Datagram Protocol (UDP).
QUIC step
One of the major differences in HTTP/3 is QUIC. Developed by Google, Quick UDP Internet Connections (QUIC) was adopted by the IETF, and a tailored version provides a cornerstone of HTTP/3.
As noted by Cloudflare, implementing QUIC sets up encrypted connections by default at the transport layer, combining handshakes into one action and encrypting the metadata exchanged between connections.
Packet numbers and header information is, therefore, removed from eavesdroppers and attackers. This improvement might potentially lower the success of manipulator-in-the-middle (MitM) attacks, IP spoofing, and denial-of-service assaults.
“This feature was not included in HTTP/2,” Cloudflare notes. “Encrypting this data helps keep actionable information about user behavior out of attackers’ hands.”
Encryption at the transport layer isn’t the end of the story. Akamai says that as HTTP/3 runs on QUIC, this also paves the way for future innovations in encrypted transport and communication – as we’ve already seen with the QUIC Datagram extension (RFC 9221), a technology to manage both UDP and TCP traffic securely.
Furthermore, the protocol supports zero round-trip time (0-RTT), introduced in TLS 1.3, which skips the handshake requirement in trusted settings – but a downside is that this could lead to replay attacks without adequate protection.
‘Challenging prospect’
Rustam Lalkaka, director of product at Cloudflare, previously told us that while HTTP/3 has a range of security and performance benefits, enabling QUIC can be a challenging prospect for developers as many widely-sed technologies are yet to add QUIC and HTTP/3 support.
Some transit providers and ISPs may be hostile to UDP traffic, and there may also be a need for increased CPU usage when HTTP/3 is implemented, a detriment to both servers and web browsers.
Support for HTTP/3 has been rolled out gradually across major browsers including Google Chrome, Mozilla Firefox, and Microsoft Edge. Apple Safari also provides support, although at the time of writing, this must be enabled in the ‘Experimental Features’ tab in the developer menu.
Cloudflare scans have revealed that the majority of online traffic is facilitated by HTTP/2. The majority of current HTTP/3 requests are made by Chrome users, followed by Edge and Firefox. Safari volumes are minimal, but Cloudflare expects an uptick once Apple enables HTTP/3 support by default.
Cloudflare Radar estimates that 8% of internet traffic is HTTP/1-based, followed by HTTP/2 at 67%, and HTTP/3 at 25%.
Source: https://portswigger.net/daily-swig/http-3-evolves-into-rfc-9114-a-security-advantage-but-not-without-challenges
