Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

HTTP1.1 replaced by HTTP/2 in response header?

RV | Last updated: Jun 10, 2021 08:56PM UTC

I intent to use Burp Suite to be able to see in more detail the communication of an application I just started to develop. I am currently using Community Edition v2021.5.2. My application responds normally when I do not use the Burp proxy. With the proxy however, an Exception is thrown within my application: AggregateException: “One or more errors occurred.” at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions) at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken) at System.Threading.Tasks.Task.Wait() InnerException: “An error occurred while sending the request.” InnerException: “The server committed a protocol violation. Section=ResponseStatusLine” at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult) at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar) I tried this for several websites, every single time this exception is thrown. The response status line in Burp shows: HTTP/2 200 OK This seems odd to me because the request was HTTP/1.1, which I confirmed using Burp. RFC 2145 states: "An HTTP server SHOULD send a response version equal to the highest version for which the server is at least conditionally compliant, and whose major version is less than or equal to the one received in the request." So I think the Exception message is correct, returning version 2 for a 1.1 request is indeed a protocol violation. When I do a 'Match and Replace' in Burp to change the version in the response header, my application does process the response without any issues, while it should not be able to handle HTTP/2 response messages. The remaining question is: Does the server cause this problem, or does Burp? I sent requests to multiple websites, and the problem is there only when I use the Burp proxy. Therefore it seems likely the problem is related to Burp.

Uthman, PortSwigger Agent | Last updated: Jun 11, 2021 08:05AM UTC

Hi RV, Are you sure that the server does not support HTTP/2? Have you tried checking this using cURL? Burp will initially send an HTTP/1.1 request and if an 'HTTP/2 200 OK' is received, all subsequent requests will use HTTP/2. It is described in our documentation below: - https://portswigger.net/burp/documentation/desktop/options/http

RV | Last updated: Jul 04, 2021 08:16PM UTC

Sorry about the late response, I expected to be notified by email when getting a reply. A server may never respond with a HTTP/2 200 OK for a HTTP/1.1 request (RFC 2145). All servers I tested with seem to comply nicely and reply with a HTTP1.1 response, when I send the request directly from my client. When sending the request via the Burp proxy however, my client receives a HTTP2 response. I do not think Burp should be sending subsequent requests in this case. In any case it is quite simple: Just as a server should never send a HTTP/2 reply to a client making a HTTP/1.1 request, when acting as a proxy Burp should not be sending HTTP/2 communication to a client making HTTP/1.1 requests either (unless the mistake was made by the upstream server). It should not cause an upgrade of messages ending up at client side. I hope I have made the problem clear. I am pretty sure this is incorrect behaviour.

Michelle, PortSwigger Agent | Last updated: Jul 05, 2021 01:26PM UTC

Thanks for getting in touch, don't worry about the late response. When Burp makes the connection to the target server, it will tell the server that it is prepared to talk both HTTP/1 and HTTP/2 in the ClientHello during the TLS handshake (part of the ALPN). If the server supports HTTP/2 and it responds telling Burp to use HTTP/2 in the ServerHello, then HTTP/2 will be used (even for the first request). You will see this indicated in the request line and status line respectively for subsequent requests. There is an option to disable HTTP/2 under under Project Options -> HTTP -> HTTP/2 if you would prefer Burp not to offer HTTP/2 as an option to the target server. I hope this helps to explain things in a bit more detail. If you've got any questions, please let us know.

RV | Last updated: Jul 07, 2021 02:31PM UTC

I understand. When the request originates from Burp, this is fine. Maybe I did not state clearly what the problem is. My client does NOT support HTTP/2. My client sends out HTTP1.1 requests. Those should never be answered with HTTP/2 responses (because the client will not understand them). Still, when using Burp as a proxy, this is exactly what is happening.

Michelle, PortSwigger Agent | Last updated: Jul 08, 2021 11:15AM UTC

As Burp's acting as an intercepting proxy, each connection has a separate ALPN negotiation, so it's possible that HTTP/1 could be used between the client and Burp whilst HTTP/2 could be used between Burp and the target. In this scenario, the HTTP/2 version in the response line would be converted to HTTP/1.1 prior to sending. Can I check which version(s) of Burp you were using for your tests? If you've not tested it yet, could you try out the same connection using the Early Adopter version 2021.7, please? This version includes all the latest bug fixes relating to HTTP/2 and looking at the date of your first post would not have been available at the time you raised this issue, so this could relate to one of the issues that we have addressed. Please let me know how things go.

Matt | Last updated: Jul 20, 2021 03:02PM UTC

I had the same issue when proxying traffic between a Flutter (dart) app which was using HTTP/1.1. The server request was upgraded to HTTP/2 and the response to the client couldn't be read properly. Can confirm either disabling HTTP2 in the project options, or upgrading to the early adopter version (v2021.7.1-8747) fixed the issue.

Michelle, PortSwigger Agent | Last updated: Jul 21, 2021 07:57AM UTC

Thanks for your message. Yes, that's right, either disabling HTTP2 in the project options in the stable release version 2021.6.2 or upgrading to the early adopter version (v2021.7.1-8747) will fix the issue.

DeySayGo | Last updated: Mar 09, 2023 02:09PM UTC

Hello. I'm passing through HTTP labs at the Academy and I did not get how to change HTTP/2 to HTTP/1.1 in labs. Every time I send POST / HTTP/1.1 Host: ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 150 Transfer-Encoding: chunked Burp switches 1.1 to 2, and it's impossible to complete any HTTP request smuggling labs. What a tragedy

DeySayGo | Last updated: Mar 09, 2023 02:16PM UTC

Oh, I have checked Documentation and found the button in Inspector window. :) It'd be better if You add info about that in the first HTTP smuggling lab

Michelle, PortSwigger Agent | Last updated: Mar 10, 2023 10:59AM UTC

Thanks for the update. We'll pass on your comments :)

Prashanan | Last updated: Mar 26, 2023 04:29PM UTC

Both solutions for HTTP Smuggling lab did not specify to keep the request in HTTP/1.1 Took a few google searches to get here and find the actual solution :)

Michelle, PortSwigger Agent | Last updated: Mar 27, 2023 07:34AM UTC

We will be reviewing the steps described in the solution. HTTP/2 uses a robust mechanism for determining the length of requests and, when used end to end (https://portswigger.net/web-security/request-smuggling#How-to-prevent-http-request-smuggling-vulnerabilities), so when using Burp Repeater and wanting to specify that HTTP/1.1 should be used, you can use the Inspector tab. You can learn more about this tool here: https://portswigger.net/burp/documentation/desktop/tools/inspector

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.