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

HTTP/3 will no longer use transmission Control Protocol (TCP) and will instead use QUIC, a transport protocol proposed by Google in 2012. In fact, HTTP/3 was originally http-over-quic.

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

QUIC is a transport layer protocol based on a multiplexed version of user Packet Protocol (UDP) connections. Unlike TCP, UDP does not follow TCP’s three-way grip, but uses a single UDP round trip. As a result, UDP is used on every connection between the user agent and the Web server, and the QUIC protocol dramatically improves the network performance of any Web component.

Similarly, QUIC relies on multiplexing to seamlessly manage multiple interactions between user agents and servers on a single connection without one blocking the other, thus helping to improve performance compared to previous versions. HTTP/3 seems to have major advantages from both a performance and stability standpoint. In terms of security, HTTP/3 has its advantages and limitations.

Security advantages

1. End-to-end encryption

TCP is designed to ensure that the payload is encrypted during transmission, but it is still not encrypted for a particular transmission, so this raises many security and privacy issues. The countermeasures against attacks are not on the TCP stack, but on the network devices and middleboxes that handle protocols and networks. In addition, parsers can overcome these problems in load balancers and other network devices, but they also have serious performance problems and can limit network speed and reliability.

With THE QUIC protocol, only the required fields in the network segment are unencrypted, while the rest of the information is encrypted by default. By looking at the network segments of TCP and QUIC, we see that fields including packet flags (packet NR and ACK NR), Windows, and options are encrypted in QUIC but not in TCP. Encryption is recommended in QUIC to help prevent pervasive surveillance attacks (common in HTTP / 3’s predecessors) as well as intrusive information collection of protocol artifacts and metadata and application data.

Figure 1 below shows how the QUIC protocol is represented in the network analyzer tool Wireshark. The Internet Protocol (IP) layer stores source and destination IP address information based on the QUIC network segment. UDP retains source and destination ports, while QUIC contains the common flag, packet number, connection ID, and encrypted payload.

Figure 1 Wireshark code segments show the QUIC network segments

2. Secure connection over TLS

To support end-to-end encryption during the connection, QUIC relies primarily on encryption and transport layer handshakes. Because QUIC interacts directly with TLS 1.3, it can be used for authorized encryption of all raw connections, and TLS is not disabled. QUIC is also responsible for ensuring that secure connections are established, taking into account the confidentiality and integrity protection of all original connections. Unlike the HTTP / 2 + TLS implementation, QUIC handles the TLS handshake and alert mechanism in its transport context, which in turn helps QUIC establish password protection using the keys exchanged from the handshake.

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, through which messages are sent and received.

TLS updates the QUIC component with the following.

1. Secret, authenticated encryption algorithms and key derivation capabilities (KDF)

2. Packet protection key

3. Protocol state changes (e.g. handshake state, server certificate)

Unlike HTTP/2, which is logged using TLS “application_data,” QUIC uses STREAM frames, which are presented as QUIC packets. TLS handshake is formed in the form of CRYPTO frames, which are mainly composed of handshake data in continuous stream. QUIC is designed to send packets in parallel, sometimes bundling different messages into a single message and encrypting them because they have the same level of encryption. This feature provides a great advantage for network performance while ensuring that the correct encryption mode is applied during transmission.

3. Complete forward confidentiality

Full forward confidentiality (PFS) in the protocol can be achieved when temporary private keys are exchanged between the user agent and the server. Each session started by the user agent uses a new unique session key that has no relationship to the previous session key. By using a separate session key for each transfer, any information from earlier or future sessions is not compromised, even if any session key is leaked. From an encryption perspective, no key exchange can provide perfect forward confidentiality. However, with full forward confidentiality, a new term makes it possible to implement PFS.

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

4. Replay attack defense

In addition to random numbers, the QUIC implementation is also used to store client-side values derived from the key. The server recognizes and rejects any duplicate requests with the same key derived value and random number. Given the overhead of protocol communication between user agents and servers, this design has been called a performance nightmare. In theory, this solution seems to work, but in practice, the protocol can become memory intensive and cause performance problems. The current design is not the best, but at the 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 rather begins protection immediately after the initial reply from the server. QUIC allows the initial transaction to be protected by the application and reduces the memory footprint of the protocol. Given that Web components may use keys derived from session keys, replay attacks can occur at this stage. However, precautions can be used at the application level to mitigate this situation.

5.IP fraud protection

QUIC supports address verification during the handshake and requires proof of address for the signature, eliminating any IP spoofing attacks. The IP address spoofing problem is primarily addressed in QUIC by making extensive use of “source address tokens”, which are authenticated blocks of encryption for the server that contain the IP address of the user agent and the timestamp of the server. The user agent can reuse the source address token generated by the server unless the connection changes and the IP address does not change. Because source address tokens are used as bearer tokens, they can be used repeatedly and can bypass any IP address restrictions set by the server. Because the server responds only to the IP address in the token, even stolen cookies or tokens will not succeed in IP spoofing.

6. Prevent SSL degradation

TLS 1.3 protects against TLS degrade attacks because the protocol specifies the key hash for all handshake communications and requires the handshake recipient to verify the sent key hash. Any detected attempts to tamper with the client’s functionality during the handshake will result in the handshake ending with an error. In addition, detection involves certificate validation messages between the user agent and the server, including PKCS RSA hash signatures for all previous messages about a particular connection. The checksum implementation in QUIC will successfully prevent TLS degradation attacks.

Security challenges

1.0-RTT recovery vulnerability

One of the biggest advantages of HTTP / 3 is 0-RTT recovery, which can greatly improve connection speed and reduce latency. However, this advantage only comes into play if the previous connection was successfully established and the current transaction use established pre-shared secrets during the last connection.

The 0-RTT recovery feature has some security drawbacks. One of the most common attack mediums is the replay attack, which can occur when an opponent resends the initial packet. In certain cases, this might force the server to think that the request came from a previously known client. Another security disadvantage of restoring 0-RTT is the partial failure of full forward secrecy. If the adversary destroys the token, then they can decrypt the contents of 0-RTT communication sent by the user agent.

2. Connection ID manipulation attack

Connection ID manipulation attacks require placing the attacker between the user agent and the server. They can manipulate the connection ID during the initial handshake during which client and server greeting messages are exchanged. The handshake will proceed as usual, the server assumes the connection has been established, but the user agent will not be able to decrypt it because the connection ID requires the input step of the encryption key derivation process, and the user agent and the server will calculate different encryption keys. The user agent eventually times out and sends an error message to the server telling the connection has been terminated. Because the client encrypts 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 (typically within 10 minutes) expires.

When executed on a large scale, the same attack may cause a denial of service attack on the server and hold multiple connections until the connection state expires. Another attack to keep a connection valid is to change other parameters, such as the source address token, to prevent the client from making any connections.

2.UDP amplification attack

To successfully scale up an attack, the attacker must trick the victim’s IP address and send a UDP request to the server. If the server sends back a more significant UDP response, an attacker can exploit this server behavior on a large scale and create a DDOS attack situation.

Specifically, in QUIC, a UDP amplification attack occurs when an adversary accepts an address verification token from a target and releases the IP address originally used to generate the token. An attacker can send 0-RTT connections back to the server using the same IP address, which may have been changed to point to a different endpoint. By performing this setting, an attacker can potentially instruct the server to send a large amount of traffic to the victim server. To prevent such attacks, HTTP / 3 has rate-limiting capabilities and ephemeral authentication tokens that act as compensation control for DDOS attacks while partially mitigating the attack situation.

3. Traffic exhaustion attack

A stream exhaustion attack occurs when an adversary intentionally starts multiple connected streams, which can result in endpoint exhaustion. An attacker can exploit exhausted sequences by repeatedly submitting a large number of requests. Although specific transport parameters may limit the number of concurrent active streams, in some cases the server configuration may be deliberately set to a higher value. Because the protocol configuration of the server increases protocol performance, the victim server can be the target of such attacks.

4. Connection reset attack

Connection reset attacks mainly send stateless resets to the victims, which can result in denial of service attacks similar to TCP reset injection attacks. If an attacker can obtain a reset token generated by a connection with a specific connection ID, there may be a potential attack vector. Finally, an attacker can use the generated token to reset active connections with the same connection ID, causing the server to wait for a connection until a timeout occurs. If this attack is carried out on a large scale, the server must consume a lot of its resources waiting for the connection to complete.

5.QUIC version degradation attack

QUIC packet protection provides authentication and encryption for all packets (except version negotiated packets) in communication. The version negotiation packet is intended to negotiate the version of the QUIC between the user agent and the server. This feature may allow an attacker to degrade a version to an insecure version of QUIC. This attack will not happen at the moment, as there is only one version of QUIC, but it will need to be noted in the future.

6. Lack of monitoring support

Although some user agents, servers, and reputable Web sites 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, a socket is not required in a QUIC connection, making detection of hosts and malicious connections more difficult. A malicious attacker may be able to relay a malicious payload through QUIC and perform a data leak attack while remaining invisible, as most detection tools cannot detect 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 be the basis for the new HTTP / 3 version. However, due to performance and security concerns, THE 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 by reducing latency due to fewer round trips and fewer packets being 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 a round trip, and subsequent connections do not require any round trips. Also, because QUIC is used for multiplexing operations, it does a better job of packet loss and a faster handshake than TCP.

Google’s version of QUIC is now gQUIC. HTTP / 3 evolved from gQUIC with significant improvements, with contributions and enhancements from the IETF working group. Although HTTP / 3 is technically 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 UDP to add reliable connections and resending on top of them with flow control, while addressing TCP’s line-blocking problem.

HTTP / 3 uses UDP, similar to how HTTP / 2 uses TCP. Each connection has several parallel flows that are used to transfer data simultaneously over a single connection without affecting other flows. Thus, unlike TCP, missing packets carrying data for a particular single stream only affect that particular stream. Each stream frame can then be assigned to the stream immediately upon arrival, so it can continue to be recombined in the application without losing any streams. QUIC’s connection establishment strategy is implemented through a combination of encryption and transport handshakes.

And HTTP/2

QUIC is designed to improve performance by alleviating HTTP/2 packet loss and latency issues. Although HTTP/2 uses a single TCP connection for each data source, this can cause row blocking problems. For example, a requested object may be left behind another object that has suffered a loss until that object is recovered. QUIC solves this problem by pushing HTTP/2’s flow layer down to the transport layer, avoiding the application layer and transport layer problems. 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.

From a network stack perspective, HTTP/2 makes extensive use of THE HTTP standard TLS 1.2+, 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 where QUIC fits in the network protocol stack. In contrast, previous versions use TLS 1.2 and use TCP’s congestion control loss recovery functionality, while HTTP/2 handles multi-streaming functionality.

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

Advantage of connection ID

TCP connections use data sources and target network entities (primarily addresses and ports) to identify specific connections. However, QUIC connections use connection IDS, which are 64-bit randomly generated client identifiers. This change is very beneficial to current Web technologies, mainly because they are required to support user mobility. If the 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 random connection ids, when moving from a cellular network to a Wi-Fi connection, a client on HTTP/3 changing its IP address 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 the connection ID to identify original and retransmitted connections and avoid the retransmission ambiguity that is common in TCP.

conclusion

QUIC is already supported by most browsers. Major sites such as YouTube and Facebook have enabled the feature to load pages faster. At the time of writing, only 4% of the top web sites currently support QUIC. Microsoft has announced that they will ship Windows with the 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. The security improvements in mandatory support for TLS 1.3 address the weaknesses of HTTP/2 and earlier versions of HTTP. The use of end-to-end encryption during HTTP/3 transport can help defend against some of the privacy concerns of attackers and data aggregators. Despite some weaknesses, HTTP/3 continues to evolve from a performance and security perspective and is a significant improvement over HTTP/2 in any case.