Burp Suite’s HTTP/2 support is surprisingly limited, primarily acting as a transparent proxy that tunnels HTTP/2 traffic over HTTP/1.1, meaning you won’t be directly inspecting HTTP/2 frames.
Let’s see Burp in action with HTTP/2. Imagine you’re testing a modern web application that exclusively serves content over HTTP/2.
Here’s a typical scenario:
1. Client (Browser) Initiates Connection:
Your browser, configured to use Burp as its proxy, attempts to connect to https://example.com.
2. Burp Intercepts:
Burp, listening on 127.0.0.1:8080, receives the connection request.
3. Burp’s HTTP/2 Handling (The Illusion):
Burp doesn’t speak HTTP/2 natively for inspection. Instead, it establishes a new HTTP/1.1 connection to the target server (example.com). It then uses the h2c (HTTP/2 Cleartext) or h2 (HTTP/2 over TLS) protocol upgrade mechanism to negotiate an HTTP/2 connection between itself and the server. However, Burp itself only sees and processes this as a series of HTTP/1.1 requests and responses from its perspective.
4. Data Flow:
- The browser sends an HTTP/1.1 request to Burp.
- Burp translates this into an HTTP/2 request to the server.
- The server responds with HTTP/2.
- Burp translates the HTTP/2 response back into an HTTP/1.1 response for the browser.
The Mental Model:
Burp acts as a protocol translator and passthrough for HTTP/2, not an interpreter. It’s like a universal adapter that takes one plug type (HTTP/1.1 from browser) and converts it to another (HTTP/2 to server), then reverses the process. The core problem Burp is solving here is allowing you to use your existing HTTP/1.1-centric tooling (like Burp’s Repeater, Intruder, Scanner) on applications that have moved to HTTP/2.
What you can do:
- Basic Interception: You can see the requests and responses as they flow through Burp, but you’re seeing them as HTTP/1.1. The underlying HTTP/2 framing, multiplexing, header compression (HPACK), and stream management are invisible at the Burp UI level.
- Modify and Resend (with caveats): You can modify the HTTP/1.1 representation of the request in Burp’s Repeater and resend it. Burp will then re-negotiate the HTTP/2 connection to the server. This allows you to test for common web vulnerabilities like XSS, SQL injection, etc., on the application logic, but not on the HTTP/2 protocol itself.
- Target Configuration: Ensure Burp is configured to support TLS for HTTPS traffic. For HTTP/2 over TLS, this is standard. For
h2c(HTTP/2 cleartext, less common), you’d still configure Burp to proxy unencrypted traffic.
The Configuration Levers:
-
Burp’s Proxy Listener:
- Go to
Proxy->Proxy Listeners. - Ensure a listener is running (e.g., on
127.0.0.1:8080). - Crucially, for HTTPS, ensure
Support invisible proxyingis checked. This is what enables Burp to handle the TLS negotiation and protocol upgrades necessary for HTTP/2 over TLS.
- Go to
-
Browser Proxy Settings:
- Configure your browser to use
127.0.0.1and the port specified in your Burp listener (e.g.,8080) for both HTTP and HTTPS traffic.
- Configure your browser to use
-
Target Server Configuration:
- The target server must support HTTP/2. Burp doesn’t force a protocol. If the server only supports HTTP/1.1, Burp will happily proxy that.
The One Thing Most People Don’t Know:
When Burp "upgrades" to HTTP/2 with the server, it’s not just a simple Upgrade: h2 header like you might see in WebSockets. It involves a TLS ALPN (Application-Layer Protocol Negotiation) extension for h2 or an explicit Connection: Upgrade, HTTP2-Settings header for h2c. Burp handles this negotiation transparently after the initial HTTP/1.1 proxy connection is established. What you see in Burp is the result of this negotiation, presented as HTTP/1.1, effectively abstracting away the HTTP/2 specifics from your direct view in the proxy history.
The next challenge you’ll likely face is understanding how to test the actual HTTP/2 protocol features themselves, like stream prioritization or flow control, which Burp’s current proxying model doesn’t expose for direct manipulation.