6 ways HTTP/3 benefits security (and 7 serious concerns)

HTTP/3 brings improved performance and reliability, along with various security and privacy benefits, but there are some noteworthy challenges.

1 2 Page 2
Page 2 of 2

QUIC version downgrade attack 
The QUIC packet protection provides authentication and encryption for all the packets in the communication, except for the version negotiation packets. The version negotiation packets are designed to negotiate the QUIC’s version between the user-agent and the server. The feature may allow an attacker to perform version downgrades to a potentially insecure version of QUIC. This attack is currently not applicable, as there is only one version of QUIC, but it's something to watch for in the future.

Lack of monitoring support
Although several user-agents, servers, and reputable websites support HTTP3/QUIC, many network appliances such as reverse/forward proxies, load balancers, web application firewalls, and security event monitoring tools do not fully support HTTP/3. Unlike TCP, sockets are not needed in a QUIC connection, making it harder to detect hosts and malicious connections. A malicious attacker may be able to relay malicious payloads and perform data exfiltration attacks via QUIC and remain stealthy, as most detection tools would not detect QUIC traffic.

History of QUIC

In 2016, the internet engineering task force (IETF) began standardizing Google’s QUIC and recently announced IETF QUIC to be the backbone of the new HTTP/3 version. However, IETF QUIC has diverged significantly from the original QUIC design for both performance and security reasons.

Traditional web traffic over TCP requires a three-way handshake; QUIC uses UDP, which speeds up web traffic due to less delay as a result of fewer round trips and fewer packets sent. In addition to being faster, UDP provides several benefits, including connection migration, improved latency, congestion control, and built-in encryption. According to Google, “QUIC handshakes frequently require zero round trips before sending payload, as compared to 1–3 round trips for TCP+TLS.” The first connection requires one round trip, and the subsequent ones do not need any round trips. Also, because QUIC is intended for multiplexed operation, it deals better with packet loss than TCP and allows faster handshakes.

Google’s version of QUIC is now the gQUIC. HTTP/3 has evolved significantly from gQUIC with contributions and enhancements from the IETF working group. While HTTP/3 is technically the 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 over UDP to add a reliable connection and resends with flow control features on top of it, while solving TCP's head-of-line blocking issue.

HTTP/3 uses UDP, similar to how HTTP/2 uses TCP. Every connection has several parallel streams that are used to transfer data simultaneously over a single connection without impacting other streams. So, unlike TCP, the lost packets that are carrying data for a specific individual stream only impacts that particular stream. Each stream frame can then be immediately dispatched to that stream upon arrival, so streams without loss can continue to be reassembled in the application. This connection establishment strategy of QUIC is enabled by the combination of crypto and transport handshake.

Comparative analysis with HTTP/2

QUIC was designed to improve performance by mitigating issues of packet loss and latency with HTTP/2. While HTTP/2 uses a single TCP connection to each origin, this leads to the head-of-line blocking problem. For instance, a request’s object may get stalled behind another object that has experienced a loss, until it can be recovered. QUIC addresses this issue by pushing the stream layer of HTTP/2 down into the transport layer, thereby avoiding the issue at both application and transport layers. HTTP/3 also enables multiplexing, delivering a request independent of other connection requests, while integrating with the TLS directly. While HTTP/2 and HTTP/3 work in similar ways, below are some of the significant differences in features of HTTP/2 and HTTP/3.

From the network stack perspective, HTTP/2 extensively utilizes TLS 1.2+ in alignment with the HTTP standard, with underlying TCP acting as a transmission protocol. However, in HTTP/3, TLS 1.3 is by default used in addition to QUIC, with UDP being the transmission protocol. The below diagram illustrates where QUIC is located in the network protocol stack. In comparison, the previous version uses TLS 1.2 and utilizes congestion control loss recovery features of TCP, with HTTP/2 handling the multi-streaming capabilities.   

QUIC’s location in the network protocol stack Sandeep Jayashankar and Subin Thayyile Kandy

Figure 2: QUIC’s location in the network protocol stack.

Connection ID benefits

The TCP connections have been designed to utilize source and destination network entities (mainly addresses and ports) to identify a specific connection. However, a QUIC connection uses a connection ID, which is a 64-bit, randomly generated client identifier. This change is very beneficial for the current web technologies, as they are required to support the user’s mobility as the main factor. If a user moves from a Wi-Fi network to a cellular network, the HTTP/2 TCP protocol would need to establish a new connection based on the current address. However, since HTTP/3 QUIC protocol utilizes a random connection ID, a client-changing IP address on HTTP/3, when moving from a cellular network to Wi-Fi connection, will continue using the existing connection ID without interruption.

From a protocol perspective, the connection ID provides additional benefits. The server and user-agents can identify the original vs. the retransmission connections using the connection ID and avoid retransmission ambiguity issues prevalent in TCP.


QUIC has been getting full acceptance and browser support; significant websites like YouTube and Facebook have enabled it for faster page loads. As of this writing, only 4% of the top sites currently support QUIC. Microsoft has announced they will be shipping Windows with a general-purpose QUIC library, MsQuic, in the kernel to support various inbox features.

QUIC and HTTP/3 are designed to meet today's goals of internet and network performance, reliability, and security. There have been significant improvements in security with mandated support for TLS 1.3, addressing the weaknesses with HTTP/2 and prior versions of HTTP.  The usage of end-to-end encryption during transit in HTTP/3 helps in defending against several privacy concerns with state actors and data aggregators. While there are some weaknesses, HTTP/3 will continue to evolve and is a significant improvement over to HTTP/2, both from performance and the security perspective. 


Copyright © 2020 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
How to choose a SIEM solution: 11 key features and considerations