HTTP/3 — Challenges to security and possible response
It’s been a year since RFC 9114, defining HTTP/3 was published. I have been interested and tracking this technology for some time, because for the first time probably since the birth of Internet, a foundational change was brought about due to this.
We have all grown up understanding the TCP 3 Way handshake and TCP has had a ubiquitous presence everywhere on the networks. But that’s changing with HTTP/3 and how.
I recently read a report from Cloudflare on “Examining HTTP/3 usage one year on” and it mentions that HTTP/3 accounts for nearly 30% of Internet traffic already. With most major web browsers, including mobile browsers supporting HTTP/3, and more and more sites supporting it, the percentage is likely to grow.
What is HTTP/3
HTTP/3 is the first major upgrade to the hypertext transfer protocol since HTTP/2 was approved in 2015. All versions of HTTP protocol, ever since its release of HTTP/1.0 in 1996, focused on improving speed without much change in the underlying building blocks, namely TCP. HTTP/3 changes that and shifts to User Datagram Protocol (UDP). It runs on QUIC, a new transport protocol.
The QUIC protocol was developed by Google in 2012 and was adopted by the Internet Engineering Task Force (IETF) — a vendor-neutral standards organization — as they started creating the new HTTP/3 standard. After consulting with experts around the world, the IETF has made a host of changes to develop their own version of QUIC. QUIC is a transport layer protocol based on a multiplexed version of UDP connections. Unlike TCP, UDP does not follow the TCP three-way handshake.
Key advantages of QUIC and HTTP/3 over TCP+TLS+HTTP/2 include:
- Connection establishment latency
- Improved congestion feedback
- Multiplexing without head-of-line blocking
- Connection migration
- Optional unreliable or partially reliable delivery
HTTP/3 fundamentally alters the technology stack as can be seen below.
The TLS + TCP stack in HTTP/2 has been replaced with QUIC + UDP stack in HTTP/3. QUIC protocol integrates not only TCP typical functionality but also embeds TLS to provide security and stream multiplexing as well. In QUIC implementation, usage of TLS is mandatory, so there is no plain-text HTTP anymore with HTTP/3.
The biggest advantage as a result of this implementation is faster and more secure connections with lower overhead.
TLS and Network Security Monitoring
The European Union Agency for Cybersecurity (ENISA) came up with a great report on Encrypted Traffic Analysis in 2019. The document explored the challenges of achieving the goals of security and privacy in the world of increasingly complex network encryptions.
From the document:
it becomes evident that the efficacy of rule-based monitoring and detection controls; e.g. Application firewalls, Intrusion Detection and Prevention Systems (IDPS), Data Loss Prevention\Protection (DLP) tools etc., which to a great extent relies on having access to the unencrypted traffic, is negatively affected. Organizations relying on such controls for their information security lose valuable insight and end up having blind spots in their managed infrastructure. To counter this vulnerability many organizations try to break end-to-end encryption by installing TLS inspection solutions (aka SSL/TLS proxies, middleboxes etc.) in key points of their network. This solution allows for the decryption of the encrypted traffic, to provide access to the plaintext payload for network monitoring and analysis tools, before re-encrypting it and forwarding it to its destination. While this method reclaims [partial] control for the organization, it also affects negatively the privacy of end users and is not guaranteed to detect all malicious traffic, which might employ custom or non-TLS encryption protocols to avoid detection. An alternative, and in our view complimentary, solution would be to employ Machine Learning (ML) and Artificial Intelligence (AI) techniques to perform encrypted traffic analysis.
Network Security Monitoring (NSM) has been a great source for monitoring infrastructures for malicious or suspected traffic. In fact, early days of security monitoring relied heavily on IDS. The “The Tao of Network Security Monitoring: Beyond Intrusion Detection” was a seminal work by Richard Bejtlich in 2004, followed up by “The Practice of Network Security Monitoring, review: A hands-on guidebook” in 2013.
NSM provides the ability to pick up telemetry that augments those from endpoints and is vital for comprehensive detection. However, as network traffic began to get encrypted, the capabilities of NSM was adversely affected.
One possible response was to introduce inline SSL/TLS inspection tools to be able to read the network data in plain text, before re-encrypting and forwarding to the destination. This has been the most popular approach in enterprises, and it still being widely used, although, this may not be the ideal solution in privacy conscious world of today. The National Security Agency (NSA) issued an advisory in 2019 as referenced in the ENISA report mentioned above.
On December 2019, National Security Agency (NSA) published a report describing a potential risk from the improper usage of TLS inspection (TLSI). Claiming that “network owners should be aware that TLSI is not a cure-all” and there should be a big effort to set TLS Inspection properly. Otherwise the network can become more vulnerable and dangerous with TLS Inspection than without it.
However, even this is under threat due to introduction of HTTP/3 as we will explore later in this article.
It is well established that all encrypted traffic sessions begin unencrypted. The client and the server have to exchange certain information in clear text to establish the TLS handshake before they can start exchanging encrypted traffic. This is typically the initial Client Hello and Server Hello packets exchanges during initial phase of TLS handshake.
Prior TLS 1.3, there was no encryption of the TLS handshake. As a result, a vast amount of metadata was available, including the server certificate that allowed traffic analysis to reveal who was talking to whom and how much, even if the eavesdropper could not see what was being talked. Even in TLS 1.3, there are parts of the TLS handshake that are unencrypted. See below.
Initially, when most of the TLS handshake process got encrypted, as in TLS 1.3, it still left behind enough clues about the exchange such as Server Name Identification (SNI) field in Client Hello message which gave an indication about the server on the other side. Security solutions started using meta data such as JA3 and JA3/S TLS signatures for detecting TLS exchanges (more on it at GitHub — salesforce/ja3: JA3 is a standard for creating SSL client fingerprints in an easy to produce and shareable way.) But then, JA3 was passive, dependent upon visibility into network traffic. As more and more parts of the traffic started getting encrypted, including the digital certificate, JA3/S no longer remains potent.
The next evolution of SNI was Encrypted SNI or ESNI, but that relied on DNS for key distribution, which would potentially reveal the server on the other side. However, this itself was closing the door on the defensive solutions that relied on SNI fingerprinting.
ESNI gave way to Encrypted Client Hello (ECH). This aims to fully encrypt the TLS handshake, including the Client Hello, making the exchange fully resistant to traffic analysis. All this makes it harder and harder for the cyber defenders to extract information from network traffic analysis.
One potential solution for ECH is JARM. JARM actively fingerprints a TLS connection by sending out 10 specifically crafted Client Hello packets to identify the server. Read more on it at Easily Identify Malicious Servers on the Internet with JARM | by John Althouse | Nov, 2020 | Salesforce Engineering. Even with ECH, JARM may be able to identify the server, but given the fact that it is active and involves multiple TLS handshakes, it can perhaps never scale. It could perhaps be of much help in investigations though.
What is obvious from above that door is progressively being closed for network traffic analysis making it harder and harder as more parts of the TLS handshake gets encrypted.
Thus, the obvious alternative is TLS inspection, which most enterprises rely on. With HTTP/3, even that is under threat.
Impact of HTTP/3 on Network Traffic Inspection
HTTP/3 is based on QUIC. Earlier part of this article mentions QUIC briefly and it fundamentally differs from the ubiquitous TCP that we have all grown up with. A good read on this topic can be found at https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/.
We will limit ourselves to its impact on NSM. As can be seen below, unlike TLS, where only the HTTP data is encrypted, QUIC encrypts almost all the transport layer metadata, including few of the header flags. The only clear text parts are the UDP packet header, few header flags and the Connection ID.
Some of the challenges that may be caused due to HTTP/3 usage in enterprises include:
- Almost negligible clear text metadata available for network traffic analysis. All existing NSM tools that rely on “understanding” traffic primarily based on metadata analysis will be challenged.
- Most security systems are unfamiliar with scrutinizing the content sent on top of UDP. TLS Proxy based tools, such as firewalls, Secure Web Gateways (SWG), network proxy and other such tools, will be challenged since decrypting QUIC traffic in the middle is extremely challenging and as of writing, only a few vendors support QUIC decryption, that too in their newest firmware.
- Network devices that were primarily optimized for TCP stack, may not be as capable of analyzing the UDP stack. Many of them will have to optimized for UDP, and this may not be trivial. Also, performance numbers for these devices may have to be revisited.
- All network devices in the environment will have to be HTTP/3 and QUIC aware. Considering that any large enterprise will have a complex mix of modern and legacy network components, this may take many years before the entire stack becomes QUIC aware.
- Large network services providers such as ISPs and cloud providers may not support QUIC or may not handle UDP in the same manner as TCP.
Do we need to worry about QUIC now?
As of August 2023, 26.5% of all the HTTP traffic already uses HTTP/3. Some of the popular sites that use, or support HTTP/3 include Google, Facebook, YouTube, Netflix, Instagram, Bing. Mozilla etc. This list is expected to grow as well as the percentage of HTTP/3 traffic. Furthermore, almost all leading web browsers have already built in support for HTTP/3.
That’s already a large number and enterprises are blind to that traffic if their network security tool does not support QUIC inspection.
How to respond?
Here are a few things that enterprises can do to respond:
- Be aware of this fundamental shift and its impact on their networks.
- Inventory all network devices, intermediate firewalls content inspection and decryption mechanisms along with their firmware versions for compatibility with QUIC protocol.
- If everything supports QUIC, you may choose to allow QUIC and HTTP/3.
- If there are legacy components that do not support QUIC, you may choose to block QUIC protocol in the firewalls, either at UDP level or at Application-ID level. In most cases, blocking UDP destination port 443 should block the QUIC protocol. However, this is not 100% since QUIC is not limited to use only port 443. It may also be beneficial to block UDP over port 80 or any other port that the web server is using. The best solution is to block at Application-ID level, where supported.
- Disable QUIC protocol in web browsers:
- For Google Chrome, go to chrome://flags and disable the Experimental QUIC protocol option
- For Microsoft Edge, go to edge://flags/ and disable the Experimental QUIC protocol option
- For Mozilla Firefox, go to about:config and disable the network.http.http3.enabled option - HTTP/3 has many advantages over earlier versions and is the future. More and more internet traffic will support HTTP/3 in the coming years. Hence enterprises should start planning for its adoption by:
- upgrading firmware to QUIC supported version, where available
- checking with your network and security appliance vendor when the support is likely to be introduced
- plan to replace legacy and end of life network and security tools that are not likely to support QUIC even in future.
The good news is that HTTP/3 elegantly falls back to HTTP/2 (TLS+TCP) where QUIC is not supported. Hence, end users are not likely to feel any impact.
Conclusion
TCP has been ubiquitous ever since the advent of internet. After many decades, QUIC promises to fundamentally alter the way we think about network protocols. The TCP 3-way handshake has been one of the first things network engineers learn and has been part of many interviews. While TCP is not going anywhere, the future Internet will belong to QUIC and UDP.
Although introduced in 2012, it has only been two years since QUIC was adopted by IETF and published as RFC 9000. Getting all the worlds network and security devices to become QUIC aware will take a long time. Meanwhile, enterprises need to be aware of the challenges (especially for security) and take proactive steps to mitigate them. This could be in the form of blocking QUIC in the short term and planning to build support for QUIC across the enterprise in the medium to long term.
It’s going to be an exciting next decade with major changes including QUIC, Quantum computing, AI developments and more. We can proactively embrace them or be left behind.