Full Report
A few months ago I was exploring the write-ups and video solutions for the retired HackTheBox machine – Quick. It’s during this exploration that I came across HTTP/3. For those that are not aware, HTTP/3 is the upcoming third major version of the Hypertext Transfer Protocol used to exchange information on the World Wide Web, succeeding HTTP/2. Now, to be honest, my knowledge of the Hypertext Transfer Protocol (HTTP) has mainly been restricted to the HTTP/1.0 and HTTP/1.1 specifications. In particular, as that is the main specifications of the protocol we (security pentesters) observe in Burp (our intercepting proxy) when assessing web applications. We are familiar and comfortable seeing HTTP GET/POST requests and the myriad of responses that can be received (e.g., 400, 503…)
Analysis Summary
# Research: Adventures into HTTP2 and HTTP3
## Metadata
- Authors: Jacques Coertze
- Institution: SensePost
- Publication: SensePost Blog
- Date: May 27, 2021
## Abstract
This analysis explores the evolution of the Hypertext Transfer Protocol, focusing on the transition from HTTP/1.x to HTTP/2 and the emerging HTTP/3 standard, which utilizes the QUIC transport layer. The primary motivation, spurred by observations during penetration testing engagements (specifically around a retired HackTheBox machine), is to understand the technical differences—particularly at the OSI network and application layers—and to ascertain any new security assessment opportunities or risks introduced by these newer protocols. The work contrasts the textual nature of HTTP/1.x with the binary framing and multiplexing of HTTP/2, and the stream-based, UDP-over-QUIC implementation of HTTP/3.
## Research Objective
The main research objective was to understand the critical differences between HTTP/1.x, HTTP/2, and HTTP/3 specifications to identify potential new security assessment vectors and vulnerabilities relevant to penetration testing and security assessments of modern web applications.
## Methodology
### Approach
The methodology involved a dual approach:
1. **Theoretical Review:** Deep-diving into the HTTP/2 and HTTP/3 specifications to build a foundational understanding of how they operate differently from incumbent protocols (HTTP/1.x).
2. **Practical Application and Tooling Assessment:** Interacting with existing internet-based web servers and local test environments utilizing HTTP/2 and HTTP/3 to observe the specifications in action, and subsequently assessing how standard penetration testing toolsets (like Burp Suite) handle these newer protocols.
### Dataset/Environment
The study involved examining publicly known web servers and applications supporting HTTP/2 and HTTP/3, alongside locally configured web servers running the new specifications.
### Tools & Technologies
The research referenced common penetration testing tools, specifically mentioning Burp Suite as the primary intercepting proxy for observing HTTP interactions, and included hands-on interaction with web servers utilizing the newer protocols.
## Key Findings
### Primary Results
1. **HTTP/1.x Limitations:** HTTP/1.0 suffered from creating a new TCP connection for every request, incurring significant latency penalties due to repeated TCP/TLS handshakes and TCP Slow Start overhead.
2. **HTTP/1.1 Improvement:** Introduced "keep-alive" connections to reuse TCP connections, amortizing the slow start penalty, but concurrency was limited by sequential request/response exchanges over the single connection.
3. **HTTP/2 Security Impact is Network-Layer Focused:** HTTP/2's adoption of a binary protocol introduces potential for traditional vulnerabilities like buffer overflows and DoS attacks due to complexity or flawed implementation, as highlighted by external studies.
4. **HTTP/3 Foundation (QUIC):** HTTP/3 leverages QUIC, which runs over **UDP datagrams**, fundamentally changing its transport layer mechanism away from TCP. This introduces new concurrency benefits but may also lead to unforeseen firewall compatibility issues.
### Novel Contributions
The analysis provides a security-centric comparison of the OSI layers, specifically noting that HTTP/2's binary nature shifts security concerns to the network layer (implementation flaws), while HTTP/3's reliance on UDP/QUIC introduces potential new complexities regarding firewall traversal and network inspection. The work aims to bridge the knowledge gap for security professionals accustomed primarily to HTTP/1.x traffic patterns seen in proxies.
## Technical Details
The transition from HTTP/1.x to HTTP/2 involved moving from a textual wire format to a **binary protocol**, enabling features like HPACK compression and stream multiplexing over a single TCP connection. HTTP/3 replaces TCP entirely with **QUIC**, a protocol developed by Google that runs on top of **UDP**. This allows for faster connection establishment (potentially 0-RTT after initial setup) and better Head-of-Line blocking mitigation because streams are independent at the transport layer, unlike TCP where packets for one stream can block others.
## Practical Implications
### For Security Practitioners
Security assessments must evolve beyond relying solely on plaintext inspection of requests/responses common in Burp Suite for HTTP/1.1. Practitioners need to understand how to proxy, manipulate, and understand encrypted binary frames (HTTP/2) and UDP-based traffic (HTTP/3/QUIC) to effectively test modern applications.
### For Defenders
Defenders must be aware of implementation-specific vulnerabilities in HTTP/2 parsers (binary protocol risks) and begin planning for the network implications of widespread QUIC adoption, particularly concerning any deep packet inspection or stateful firewall rules that rely strictly on TCP behavior.
### For Researchers
The research suggests a need for further investigation into the stability, adoption landscape, and resulting security surface area of QUIC-based implementations, as the HTTP/3 specification is still evolving.
## Limitations
The analysis notes that the HTTP/3 specification and QUIC adoption are still in early development ("early in its development") and subject to future changes. The practical exploration of security flaws specific to HTTP/3 was limited by its nascent stage, contrasting with the more observable risks already documented for HTTP/2.
## Comparison to Prior Work
The work systematically reviews the evolution from HTTP/1.x (defined by RFC 1945 and RFC 2616) through to the newer specifications, contextualizing the motivations (latency reduction, concurrency) that drove the development of HTTP/2 and HTTP/3 (QUIC). It builds upon existing industry research regarding HTTP/2 vulnerabilities (citing Imperva's study) but focuses on contextualizing this knowledge for the pentesting workflow.
## Future Work
The author implies future work will involve tracking the real-world materialization of potential UDP/QUIC-related firewall issues and continuously updating tooling to accommodate evolving HTTP/3 standards.
## References
* RFC 1945 (HTTP/1.0 Specification)
* RFC 2616 (HTTP/1.1 Specification)
* Imperva Study on HTTP/2 vulnerabilities
* QUIC Working Group Drafts (quicwg.org)