HTTP/3 is the third official version of the Hypertext Transfer Protocol (HTTP), which aims to improve network performance and stability while addressing various security and privacy issues. However, it still faces some security challenges.
HTTP/3 no longer uses the Transmission Control Protocol (TCP); instead, it employs the QUIC transport protocol proposed by Google in 2012. In fact, HTTP/3 is a successor to HTTP-over-QUIC.
In October 2018, Mark Nottingham, chair of the Internet Engineering Task Force (IETF) HTTP and QUIC working groups, proposed renaming HTTP-over-QUIC to HTTP/3.
QUIC is a multiplexed version of a transport layer protocol based on User Datagram Protocol (UDP) connections. Unlike TCP, UDP does not follow the TCP three-way handshake but instead uses a single UDP round trip. Therefore, each connection between the user agent and the web server uses UDP, and the QUIC protocol significantly enhances the network performance of any web component.
Similarly, QUIC relies on multiplexing to seamlessly manage multiple interactions between the user agent and the server over a single connection without one blocking the other, thus improving performance compared to previous versions. From the perspective of performance and stability, HTTP/3 appears to have significant advantages. However, in terms of security, HTTP/3 has both advancements and limitations.
Security Advantages
1. End-to-End Encryption
The TCP protocol is designed to ensure effective payload encryption during transmission, but certain information transmitted remains unencrypted, leading to various security and privacy issues. Countermeasures against attacks are not on the TCP stack but rather on the network devices and intermediaries handling the protocols and networks. Additionally, parsers can overcome these issues in load balancers and other network devices, but they also present serious performance problems and may limit the speed and reliability of network development.
When using the QUIC protocol, only the mandatory fields in the network segment are unencrypted, while the rest of the information is encrypted by default. By examining the network segments of TCP and QUIC, we find that fields including packet flags (packet NR and ACK NR), windows, and options are encrypted in QUIC but not in TCP. The recommended encryption in QUIC helps prevent prevalent monitoring attacks (which were common in the predecessor of HTTP/3) as well as intrusive information collection of protocol artifacts and metadata, and application data.
The following Figure 1 shows how the QUIC protocol is presented in the network analyzer tool Wireshark. According to the QUIC network segment, the Internet Protocol (IP) layer retains the source and destination IP address information. UDP retains the source and destination ports, while QUIC includes public flags, packet numbers, connection IDs, and encrypted payloads.
Figure 1: Wireshark code segment showing the QUIC protocol’s network segment
2. TLS Secure Connection
To support end-to-end encryption during connections, QUIC primarily relies on encryption and transport layer handshakes. Since QUIC interacts directly with TLS 1.3, it can be used for authorization encryption of all original connections without disabling TLS. QUIC is also responsible for ensuring secure connections while considering confidentiality and integrity protection for all original connections. Unlike the HTTP/2 + TLS implementation, QUIC handles the TLS handshake and alert mechanisms within its transport context, which in turn helps QUIC utilize the keys exchanged during the handshake to establish cryptographic protection.
If we consider the protocol as a whole, there are two main communications between TLS and QUIC:
QUIC provides a stable stream abstraction for TLS to send and receive messages.
TLS updates QUIC components with the following:
1. Secret, authenticated encryption algorithms and key derivation functions (KDF)
2. Packet protection keys
3. Protocol state changes (e.g., handshake state, server certificates)
Unlike HTTP/2, which uses the “application_data” record with TLS, QUIC uses STREAM frames, presented in the form of QUIC packets. The TLS handshake is formed in the form of CRYPTO frames, primarily consisting of handshake data in a continuous stream. QUIC is designed to send packets in parallel, sometimes bundling different messages into one message and encrypting them, as these messages share the same encryption level. This feature provides significant advantages for network performance while ensuring the correct encryption mode is applied during transmission.
3. Perfect Forward Secrecy
Perfect Forward Secrecy (PFS) in the protocol can be achieved when temporary private keys are exchanged between the user agent and the server. Each session initiated by the user agent uses a new unique session key, which has no relation to previous session keys. By using a separate session key for each transmission, even if any session key is compromised, information from earlier or future sessions remains secure. From an encryption perspective, no key exchange can provide perfect forward secrecy. However, perfect forward secrecy, a new term, enables the implementation of PFS.
QUIC uses TLS 1.3, which supports Elliptic Curve (EC) DHE key exchange or pre-shared keys (PSK) and Diffie-Hellman (DH) on finite fields. The 0-RTT key exchange provides complete forward secrecy, as the encryption specification only accepts forward secure connections established through 0-RTT handshakes. Although TLS 1.2 also supports forward secrecy, technically, forward secrecy is lost during session recovery when the user agent sends a copy of confidential data protected by a symmetric key known only to the server. The protocol even provides complete forward secrecy for the initial messages between the user agent and the server. Additionally, since the QUIC protocol does not support long-term keys, QUIC can provide complete forward secrecy for applications using its protocol layer with TLS 1.3.
4. Replay Attack Protection
In addition to random numbers, QUIC implementations also store client values derived from keys. The server identifies and rejects any duplicate requests with the same key derivation value and random number. Considering the protocol communication overhead between the user agent and the server, this design is referred to as a performance nightmare. Theoretically, this solution seems applicable, but in practice, the protocol can become memory-intensive and lead to performance issues. The current design is not optimal, but from a protocol perspective, it prevents any server from accepting the same key multiple times. Similarly, QUIC does not provide replay protection in the initial steps but begins protection immediately after the server’s initial response. QUIC is designed to allow initial transactions to receive application protection while reducing the memory footprint of the protocol. Given that web components may use keys derived from session keys, replay attacks may occur at this stage. However, preventive measures can be implemented at the application level to mitigate this situation.
5. IP Spoofing Protection
QUIC supports address validation during the handshake and requires signed address proof, thereby eliminating any IP spoofing attacks. The issue of IP address spoofing is primarily addressed in QUIC through the extensive use of “source address tokens,” which are authenticated encrypted blocks from the server containing the user agent’s IP address and the server’s timestamp. The user agent can reuse the source address token generated by the server unless the connection changes or the IP address does not vary. Since source address tokens serve as bearer tokens, they can be reused, bypassing any IP address restrictions set by the server. Since the server only responds to the IP address in the token, even stolen cookies or tokens will not succeed in IP spoofing.
6. Prevention of SSL Downgrade
TLS 1.3 can prevent TLS downgrade attacks because the protocol specifies the key hash for all handshake communications and requires the handshake recipient to verify the sent key hash. During the handshake, any detected tampering attempts against client capabilities will result in the handshake being terminated with an error. Additionally, detection also involves certificate verification messages between the user agent and the server, including PKCS RSA hash signatures of all previous messages regarding the specific connection. The checksum implementation in QUIC will successfully prevent TLS downgrade attacks.
Security Challenges
1. 0-RTT Recovery Vulnerability
One of the greatest advantages of HTTP/3 is 0-RTT recovery, which can significantly improve connection speed and reduce latency. However, this advantage only applies if a previous connection was successfully established and the current transaction uses a pre-shared secret established during the last connection.
The 0-RTT recovery feature has some security drawbacks. One of the most common attack vectors is replay attacks, which can occur when an adversary resends the initial data packet. In specific cases, this may force the server to believe that the request is from a previously known client. Another security drawback of recovering 0-RTT is the partial failure of complete forward secrecy. If an adversary compromises the token, they can decrypt the content of the 0-RTT communication sent by the user agent.
2. Connection ID Manipulation Attacks
Connection ID manipulation attacks require the attacker to be positioned between the user agent and the server. They can manipulate the connection ID during the initial handshake when exchanging client and server greeting messages. The handshake proceeds as usual, and the server assumes a connection has been established, but the user agent will be unable to decrypt it because the connection ID is needed as input for the encryption key derivation process, and the user agent and server will compute different encryption keys. The user agent will eventually time out and send an error message to the server, indicating that the connection has been terminated. Since the client encrypts the error message to the server using the original encryption key, the server will be unable to decrypt it and will maintain the connection state until the idle connection times out (usually within 10 minutes).
When executed on a large scale, the same attack could lead to a denial-of-service attack against the server, retaining multiple connections until the connection state expires. Another method to keep the connection valid is to change other parameters, such as the source address token, preventing the client from establishing any connections.
3. UDP Amplification Attacks
To successfully execute an amplification attack, the attacker must spoof the victim’s IP address and send UDP requests to the server. If the server returns significant UDP responses, the attacker can exploit this server behavior on a large scale and create a DDoS attack scenario.
Specifically, in QUIC, a UDP amplification attack occurs when an adversary accepts an address validation token from the target and releases the IP address initially used to generate the token. The attacker can send a 0-RTT connection back to the server using the same IP address, which may have been altered to point to a different endpoint. By executing this setup, the attacker can potentially instruct the server to send a large amount of traffic to the victim server. To prevent this attack, HTTP/3 has rate-limiting features and ephemeral validation tokens that can serve as compensatory controls against DDoS attacks while partially mitigating attack scenarios.
4. Traffic Exhaustion Attacks
Traffic exhaustion attacks occur when an adversary intentionally initiates multiple connection streams, which may lead to endpoint exhaustion. The attacker can exploit the exhaustion sequence by repeatedly submitting a large number of requests. Although specific transport parameters may limit the number of concurrently active streams, in some cases, the server configuration may be intentionally set to a higher value. Since the protocol configuration of the server increases protocol performance, the victim server may become a target for such attacks.
5. Connection Reset Attacks
Connection reset attacks primarily involve sending stateless resets to the victim, potentially resulting in denial-of-service attacks similar to TCP reset injection attacks. If the attacker can obtain a reset token generated for a connection with a specific connection ID, a potential attack vector may exist. Ultimately, the attacker can use the generated token to reset active connections with the same connection ID, causing the server to wait for the connection until a timeout occurs. If this attack is executed on a large scale, the server must consume significant resources waiting for connections to complete.
6. QUIC Version Downgrade Attacks
QUIC packet protection provides authentication and encryption for all packets in communication (except version negotiation packets). Version negotiation packets are designed to negotiate the version of QUIC between the user agent and the server. This feature may allow an attacker to downgrade the version to an insecure version of QUIC. This attack is currently not occurring as there is only one version of QUIC, but it will need to be monitored in the future.
7. Lack of Monitoring Support
Although some user agents, servers, and reputable websites support HTTP3/QUIC, many network devices (such as reverse/forward proxies, load balancers, web application firewalls, and security event monitoring tools) do not fully support HTTP/3. Unlike TCP, QUIC connections do not require sockets, making it more challenging to detect hosts and malicious connections. Malicious attackers may be able to relay malicious payloads through QUIC and execute data leakage attacks while remaining undetected, as most detection tools cannot identify QUIC traffic.
The History of QUIC
In 2016, the Internet Engineering Task Force (IETF) began standardizing Google’s QUIC and announced that IETF QUIC would serve as the foundation for the new HTTP/3 version. However, for performance and security reasons, IETF QUIC differs significantly from the original QUIC design.
Traditional web traffic over TCP requires a three-way handshake. QUIC uses UDP, which reduces latency due to fewer round trips and fewer packets sent, thus accelerating network traffic transmission. In addition to being faster, UDP has other advantages, including connection migration, improved latency, congestion control, and built-in encryption. According to Google, “Compared to 1-3 round trips of TCP + TLS, QUIC handshake typically requires zero round trips to send payloads.” The first connection requires one round trip, while subsequent connections require no round trips. Similarly, since QUIC is used for multiplexing operations, it performs better in terms of packet loss compared to TCP and has faster handshake speeds.
Google’s version of QUIC is now gQUIC. The HTTP/3 evolved from gQUIC, featuring significant improvements and contributions from the IETF working group. Although technically HTTP/3 is a complete application protocol, QUIC refers to the underlying transport protocol, which is not limited to serving web traffic. UDP is connectionless and not very reliable. QUIC overcomes these limitations by adding a TCP-like stack on top of UDP, providing reliable connections and retransmitting in a way that incorporates flow control while addressing TCP’s head-of-line blocking issue.
HTTP/3 uses UDP in a manner similar to how HTTP/2 uses TCP. Each connection has several parallel streams, which are used to transmit data simultaneously over a single connection without affecting other streams. Therefore, unlike TCP, packet loss affecting data carried for a specific single stream only impacts that particular stream. Each stream frame can be immediately assigned to that stream upon arrival, allowing the application to continue reassembling without losing any streams. This connection establishment strategy of QUIC is achieved through a combination of encryption and transport handshakes.
Comparative Analysis with HTTP/2
QUIC is designed to enhance performance by alleviating the packet loss and latency issues of HTTP/2. While HTTP/2 uses a single TCP connection for each data source, this leads to head-of-line blocking issues. For example, an object requested may be stalled behind another object suffering from loss until that object is recovered. QUIC resolves this issue by pushing the stream layer of HTTP/2 down to the transport layer, thus avoiding problems between the application layer and transport layer. HTTP/3 also supports multiplexing while providing requests independent of other connection requests, directly integrated with TLS. Although HTTP/2 and HTTP/3 operate similarly, here are some key differences between HTTP/2 and HTTP/3.
| Difference | HTTP/2 | HTTP/3 |
|---|---|---|
| Transport | TCP | UDP-based QUIC |
| Stream Layer | Application | Transport |
| Default Encryption | No | Yes |
| Independent Streams | No | Yes |
| Header Compression | HPACK | QPACK |
| Handshake | Faster 0-RTT | 1-3 RTT of TCP + TLS |
| Connection Elimination | No | Yes |
| Congestion Control Loss Recovery | Performed by TCP | Performed by QUIC |
From the perspective of the network stack, HTTP/2 extensively uses TLS 1.2+ compliant with HTTP standards, with the underlying TCP serving as the transport protocol. However, in HTTP/3, by default, TLS 1.3 is used in addition to QUIC, while UDP serves as the transport protocol. The following diagram illustrates the position of QUIC in the network protocol stack. In contrast, previous versions used TLS 1.2 and relied on TCP’s congestion control loss recovery capabilities, while HTTP/2 handled multi-stream functionality.
Figure 2: The position of QUIC in the network protocol stack
Advantages of Connection ID
TCP connections identify specific connections using data source and destination network entities (primarily addresses and ports). However, QUIC connections use connection IDs, which are 64-bit randomly generated client identifiers. This change is highly beneficial for current web technologies, primarily because it requires them to support user mobility. If a user moves from a Wi-Fi network to a cellular network, the HTTP/2 TCP protocol would require establishing a new connection based on the current address. However, since the HTTP/3 QUIC protocol uses random connection IDs, changing the client’s IP address on HTTP/3 when transitioning from a cellular network to a Wi-Fi connection will continue to use the existing connection ID without interruption.
From a protocol perspective, connection IDs provide additional benefits. The server and user agent can use connection IDs to identify original and retransmitted connections, avoiding the common retransmission ambiguity issues in TCP.
Conclusion
QUIC has gained support from most browsers. Major websites like YouTube and Facebook have enabled this feature, allowing for faster page loads. As of this writing, only 4% of top websites support QUIC. Microsoft has announced that they will deliver a universal QUIC library, MsQuic, in the kernel of Windows to support various inbox features.
QUIC and HTTP/3 are designed to meet the goals of network performance, reliability, and security in today’s internet. The mandatory support for TLS 1.3 significantly improves security, addressing the weaknesses of HTTP/2 and earlier versions of HTTP. The use of end-to-end encryption during the transmission of HTTP/3 helps mitigate some privacy issues for attackers and data aggregators. Despite some weaknesses, HTTP/3 will continue to evolve from both performance and security perspectives, representing a significant improvement over HTTP/2.
Reference Links:
6 Ways HTTP/3 Enhances Security
Recommended Highlights
