Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Illegal HTTP/2 Upgrade

Felix | Last updated: Jul 02, 2021 09:33AM UTC

We are currently testing an application that requires NTLMv2 authentication. When first visiting the App over HTTP with the Embedded Browser, NTLMv2 authentication works. The application the immediately redirects the Browser to HTTPs and requires Authentication again. GET / HTTP/1.1 Host: xx.xx.xx.xx User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:89.0) Gecko/20100101 Firefox/89.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: Keep-Alive Upgrade-Insecure-Requests: 1 HTTP/1.1 307 Temporary Redirect Location: https://xx.xx.xx.xx/ Server: Microsoft-IIS/10.0 Persistent-Auth: true Date: Thu, 01 Jul 2021 07:35:17 GMT Content-Length: 0 This second request is then "upgraded" to HTTP/2 by Burp. GET / HTTP/2 Host: xx.xx.xx.xx User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:89.0) Gecko/20100101 Firefox/89.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Upgrade-Insecure-Requests: 1 Te: trailers Connection: Keep-Alive The Server does not respond to that request as it is not configured for HTTP/2. A similar issue is present when using "Platform Authentication" with NTLMv2. Sending the requests through a MiTM proxy somehow worked as a workaround. Disabling HTTP/2 in the "Project Options" -> "HTTP" tab did fix the issue and NTLM authentication works again. However the question for me is, why is Burp adding the HTTP/2 header whilst there is no "Update: HTTP/2" header? This seems to be a bug with Burp.

Michelle, PortSwigger Agent | Last updated: Jul 02, 2021 12:48PM UTC

Thanks for your message. Burp will only use HTTP/2 if the target server confirms that HTTP/2 is supported during the negotiation of the connection, we should fall back to HTTP/1 with a target that does not support HTTP/2. Based on the information you've sent over though we have been able to identify a bug that is then causing problems with the NTLM authentication when HTTP/2 is enabled, so thank you for getting in touch and sending all the detail over. We've linked this thread to the bug report so we can let you know when a fix is released. Please let us know if you have any further questions.

Liam, PortSwigger Agent | Last updated: Nov 02, 2021 12:21PM UTC

We now support trailing headers in HTTP/2 responses. - https://portswigger.net/burp/releases#professional

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