Security advantages and challenges of HTTP3 protocol

HTTP/3 is the third official version of the Hypertext Transfer Protocol (HTTP), which will improve network performance and stability and solve various security and privacy issues, but despite this, some security challenges still exist.

HTTP/3 no longer uses the Transmission Control Protocol (TCP). Instead, it will use the QUIC transport protocol proposed by Google in 2012. In fact, the predecessor of HTTP/3 is HTTP-over-QUIC.

In October 2018, Mark Nottingham, chairman of the Internet Engineering Task Force (IETF) HTTP and QUIC Working Group, proposed renaming HTTP-over-QUIC to HTTP/3.

[[335081]]

QUIC is a transport layer protocol based on a multiplexed version of the User Datagram Protocol (UDP) connection. Unlike TCP, UDP does not follow the TCP three-way handshake, but uses a single UDP round trip. Therefore, each connection between the user agent and the web server uses UDP, and the QUIC protocol greatly improves the network performance of any web component.

Similarly, QUIC relies on multiplexing to seamlessly manage multiple interactions between the user agent and the server on a single connection without one blocking the other, thus helping to improve performance compared to previous versions. From the perspective of performance and stability, HTTP/3 seems to have great advantages. From the perspective of security, HTTP/3 has its advantages and limitations.

Security Advantages

1. End-to-end encryption

The TCP protocol is designed to ensure payload encryption during transmission, but the information for a particular transmission remains unencrypted, which raises many security and privacy issues. The countermeasures to prevent attacks are not on the TCP stack, but on the network devices and middleboxes that handle the protocol and the network. In addition, resolvers can overcome these problems in load balancers and other network devices, but they also have serious performance issues and may limit the speed and reliability of network development.

When using the QUIC protocol, only the mandatory fields in the segment are not encrypted, while the rest of the information is encrypted by default. By looking at the segment for TCP and QUIC, we found that fields including packet flags (Packet NR and ACK NR), window, and options are encrypted in QUIC but not in TCP. The proposed encryption in QUIC helps prevent widespread surveillance attacks (prevalent in predecessors of HTTP/3) and intrusive information collection of protocol artifacts and metadata, application data.

Figure 1 below shows how the QUIC protocol is presented in the network analyzer tool Wireshark. Depending on the QUIC segment, the Internet Protocol (IP) layer saves the source IP address and destination IP address information. UDP preserves the source and destination ports, while QUIC contains public flags, packet numbers, connection IDs, and encrypted payloads.

Figure 1 Wireshark code snippet showing the QUIC protocol network segment

2. TLS secure connection

To support end-to-end encryption during the connection, QUIC relies primarily on encryption and transport layer handshakes. Since QUIC interacts directly with TLS 1.3, it can be used for authorized encryption of all origin connections without disabling TLS. QUIC is also responsible for ensuring that a secure connection is established while taking into account the confidentiality and integrity protection of all origin connections. Unlike HTTP/2 + TLS implementations, QUIC handles the TLS handshake and alert mechanism in its transport context, which in turn helps QUIC leverage the keys exchanged from the handshake to establish cryptographic protections.

If we think about the protocol as a whole, there are two main communications between TLS and QUIC:

QUIC provides a stable stream abstraction for TLS, sending and receiving messages over QUIC.

TLS updates the QUIC component with the following.

• Secret, authenticated encryption algorithm and key derivation function (KDF)
• Packet Protection Key
• Protocol state changes (e.g. handshake status, server certificate)

Unlike HTTP/2, which uses TLS's "application_data" record, QUIC uses STREAM frames, which are presented in the form of QUIC packets. The TLS handshake is formed in the form of CRYPTO frames, which mainly consist 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 because these messages have the same encryption level. This feature provides great advantages for network performance while ensuring that the correct encryption mode is applied during transmission.

3. Perfect forward secrecy

Perfect forward secrecy (PFS) in the protocol is 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, and it has no relationship to the previous session key. By using a separate session key for each transmission, any information from earlier or future sessions cannot be compromised even if any session key is compromised. From a cryptographic perspective, no key exchange can provide perfect forward secrecy. However, perfect forward secrecy, a new term, makes the implementation of PFS possible.

QUIC uses TLS 1.3, which supports elliptic curve (EC) DHE key exchange or pre-shared keys (PSK) and Diffie-Hellman (DH) over finite fields. The 0-RTT key exchange provides perfect forward secrecy because the cryptographic specification only accepts forward-secure connections over a 0-RTT handshake. Although TLS 1.2 also supports forward secrecy, technically, forward secrecy is lost during session resumption when the user agent sends a copy of confidential material protected by a symmetric key known only to the server. The protocol provides perfect forward secrecy even for initial messages between the user agent and the server. In addition, since the QUIC protocol does not support long-term keys, QUIC, with the help of TLS 1.3, can use its protocol layer to provide perfect forward secrecy to applications.

4. Replay attack protection

In addition to the nonce, QUIC implementations also store client-side values ​​for key derivation. Any repeated requests with the same key derivation value and nonce are identified and rejected by the server. This design is known to be a performance nightmare given the protocol communication overhead between the user agent and the server. In theory, the solution seems to work, but in practice, the protocol can become memory-intensive and cause performance issues. The current design is not optimal, but from a protocol level, it prevents any server from accepting the same key more than once. Similarly, QUIC does not provide replay protection in the initial step, but starts protection immediately after the server's initial reply. QUIC is designed to allow the initial transaction to be protected by the application and reduce the protocol's memory footprint. Given that web components may use keys derived from the session key, replay attacks are possible at this stage. However, precautions can be used at the application level to mitigate this.

5. IP spoofing protection

QUIC supports address verification during the handshake and requires a signed proof of address, eliminating any IP spoofing attacks. The IP address spoofing problem is primarily addressed in QUIC by extensively utilizing "source address tokens," which are authenticated cryptographic blocks of the server that contain the user agent's IP address and the server's timestamp. User agents can reuse server-generated source address tokens unless the connection changes and the IP address does not change. Since source address tokens act as bearer tokens, they can be used over and over again and can bypass any IP address restrictions set by the server. Since the server only responds to the IP address in the token, even a stolen cookie or token will not successfully spoof IP.

6. Prevent SSL downgrade

TLS 1.3 can prevent TLS downgrade attacks because the protocol specifies a key hash for all handshake communications and requires the recipient of the handshake to verify the key hash sent. During the handshake process, any detected attempt to tamper with the client's functions will cause the handshake to terminate with an error. In addition, detection also involves certificate verification messages between the user agent and the server, including a PKCS RSA hash signature of all previous messages about a specific connection. The checksum implementation in QUIC will successfully prevent TLS downgrade attacks.

Security Challenges

1. 0-RTT recovery vulnerability

One of the biggest advantages of HTTP/3 is 0-RTT resumption, which can greatly increase connection speeds and reduce latency. However, this advantage only works if the previous connection was successfully established and the current transaction uses the pre-shared secret established during the previous connection.

There are some security disadvantages to the 0-RTT resumption feature. One of the most common attack vectors is a replay attack, which can be caused when an adversary resends the initial packet. In certain circumstances, this can force the server to think that the request came from a previously known client. Another security disadvantage of resuming 0-RTT is the partial loss of perfect forward secrecy. If an adversary compromises the token, then they can decrypt the content of 0-RTT communications sent by the user agent.

2. Connection ID manipulation attack

Connection ID manipulation attacks require that the attacker be placed between the user agent and the server. They can manipulate the connection ID during the initial handshake when the client and server hello messages are exchanged. The handshake will proceed as normal and the server will assume that the connection is established, but the user agent will not be able to decrypt it because the connection ID requires an input step to the encryption key derivation process and the user agent and server will calculate different encryption keys. The user agent will eventually time out and send an error message to the server saying that the connection was terminated. Since the client encrypted the error message to the server using the original encryption key, the server will not be able to decrypt it and will remain connected until the idle connection timeout expires (usually within 10 minutes).

When executed at scale, the same attack could cause a denial of service attack on the server and keep multiple connections alive until the connection state expires. Another attack method to keep the connection alive is to change other parameters, such as the source address token, thus preventing the client from establishing any connection.

3. UDP Amplification Attack

In order to successfully conduct an amplification attack, the attacker must spoof the victim's IP address and send a UDP request to the server. If the server sends back a more significant UDP response, 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 a target and releases the IP address that was originally used to generate the token. The attacker can then 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 capabilities and short-lived validation tokens that can act as a compensating control for DDOS attacks while partially mitigating the attack scenario.

4. Traffic exhaustion attack

Stream exhaustion attacks occur when an adversary intentionally initiates multiple connection streams, which can lead to endpoint exhaustion. An 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, server configurations may be intentionally set to higher values. Victim servers may be targets for this type of attack because their protocol configuration increases protocol performance.

5. Connection Reset Attack

A connection reset attack is essentially sending a stateless reset to the victim, potentially creating a denial of service attack similar to a TCP reset injection attack. If an attacker can obtain a reset token generated for a connection with a specific connection ID, a potential attack vector may exist. Finally, the attacker can use the generated token to reset an active connection with the same connection ID, causing the server to wait for a connection until a timeout occurs. If this attack is carried out at scale, the server must consume a large amount of its resources waiting for the connection to complete.

6. QUIC version downgrade attack

QUIC Packet Protection provides authentication and encryption for all packets in the communication (except for version negotiation packets). Version negotiation packets are designed to negotiate the version of QUIC between the user agent and the server. This feature could allow an attacker to downgrade to an insecure version of QUIC. This attack does not currently work because there is only one version of QUIC, but it is something to be aware of 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, no sockets are required in QUIC connections, which makes it more difficult to detect hosts and malicious connections. Malicious attackers may be able to relay malicious payloads and perform data exfiltration attacks over QUIC and remain stealthy because most detection tools cannot detect QUIC traffic.

History of QUIC

In 2016, the Internet Engineering Task Force (IETF) began to standardize Google's QUIC and announced that IETF QUIC would become the basis for the new HTTP/3 version. However, due to performance and security considerations, IETF QUIC is very different from the original QUIC design.

Traditional web traffic over TCP requires a three-way handshake. QUIC uses UDP, which speeds up network traffic due to reduced latency due to fewer round trips and fewer packets sent. In addition to being faster, UDP has other advantages, including connection migration, improved latency, congestion control, and built-in encryption. According to Google, "QUIC handshakes typically require zero round trips to send the payload, compared to 1-3 round trips for TCP+TLS." The first connection requires one round trip, while subsequent connections do not require any round trips. Also, because QUIC uses multiplexing, it does better with packet loss and has faster handshakes than TCP.

Google's version of QUIC is now gQUIC. HTTP/3, which evolved from gQUIC, has significant improvements and has been contributed and enhanced by the IETF working group. While HTTP/3 is technically a full 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 to add reliable connections and resends with flow control capabilities on top of it, while solving TCP's head-of-line blocking problem.

HTTP/3 uses UDP, similar to how HTTP/2 used TCP. Each connection has several parallel streams that are used to transfer data simultaneously over a single connection without affecting other streams. Therefore, unlike TCP, a lost packet carrying data for a specific single stream only affects that specific stream. Each stream frame can then be assigned to that stream as soon as it arrives, so it can continue to be reassembled in the application 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 aims to improve 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 can lead to head-of-line blocking issues. For example, a requested object may be stuck behind another object that suffered loss until that object is recovered. QUIC solves this problem by pushing HTTP/2's stream layer down to the transport layer, avoiding both application and transport layer issues. HTTP/3 also supports multiplexing, providing requests independent of other connection requests while integrating directly with TLS. Although HTTP/2 and HTTP/3 work similarly, here are some important differences between HTTP/2 and HTTP/3.

From the perspective of the network stack, HTTP/2 makes extensive use of TLS 1.2+, which is compliant with the HTTP standard, with the underlying TCP acting as the transport protocol. However, in HTTP/3, TLS 1.3 is used by default in addition to QUIC, and UDP is the transport protocol. The following figure illustrates the position of QUIC in the network protocol stack. In contrast, previous versions use TLS 1.2 and use TCP's congestion control loss recovery features, while HTTP/2 handles the multi-stream feature.

Figure 2: QUIC’s position in the network protocol stack

Advantages of Connect ID

A TCP connection uses data source and destination network entities (mainly addresses and ports) to identify a specific connection. However, QUIC connections use a connection ID, which is a 64-bit randomly generated client identifier. This change is very beneficial to current Web technologies, mainly because they are required to support user mobility. If a user moves from a Wi-Fi network to a cellular network, the HTTP/2 TCP protocol will need to establish a new connection based on the current address. However, because the HTTP/3 QUIC protocol uses a random connection ID, a client on HTTP/3 that changes its IP address will continue to use the existing connection ID without interruption when moving from a cellular network to a Wi-Fi connection.

From a protocol perspective, connection IDs provide other benefits. Servers and user agents can use connection IDs to identify original and retransmission connections and avoid the retransmission ambiguity problem that is prevalent in TCP.

in conclusion

QUIC has gained support from most browsers. Important websites such as YouTube and Facebook have enabled the feature to load pages faster. At the time of writing, only 4% of the top websites currently support QUIC. Microsoft has announced that they will ship Windows with a generic QUIC library, MsQuic, in the kernel to support various inbox features.

QUIC and HTTP/3 are designed to meet the performance, reliability, and security goals of today's Internet networks. Security has been significantly improved with mandatory support for TLS 1.3, which addresses weaknesses in HTTP/2 and earlier versions of HTTP. The use of end-to-end encryption during HTTP/3 transmission helps to protect against some privacy issues from attackers and data aggregators. Despite some weaknesses, HTTP/3 will continue to develop from a performance and security perspective and is a significant improvement over HTTP/2.