I would like to test an application running on HTTP2.
Do you have any roadmap for supporting HTTP2?
We do plan to add support for (some) HTTP/2 features into Burp, based on the pace of adoption and usage of those features. We can’t currently promise an ETA for that support.
No updates as yet. We’re continuing to monitor take-up in real-world applications, and the extent to which downgrading to HTTP/1 continues to reach all of the application-layer attack surface.
any news on when burp will support http/2.0 ?
If you create a Proxy match/replace rule to delete the “Upgrade” header in requests, does that help? This will make it look to the server as if the client is not attempting the upgrade to HTTP/2.
No update at present.
Thanks for getting in touch.
HTTP/2 support is definitely on our radar. It’s a major change as it moves away from the traditional request/response model that Burp is based on.
Our view has been that all HTTP/2 apps are also available as HTTP/1.1. Have you found otherwise?
If you can share any information on methodologies you’ve used for HTTP/2 apps and features that would help you, we’ll make a note of those.
When can we excpect HTTP/2-Support in Burp?
So far, most of the Backends support both HTTP/1.1 and HTTP/2. The only tool so far that can be used to intercept and display HTTP/2 Traffic so far is MITMProxy, which offers even an API to deal with the requests. Still, for manual Penetration-Testing, this is not very well suited.
So far, only the standard burp features that are used in HTTP/1.1 would be completely sufficient for testing Apps that are only available HTTP/2.
At present we are not prioritizing HTTP/2 support. The main reason for this is that all apps are also available over HTTP/1.1 and you can perform testing using HTTP/1.1. While testing with HTTP/2 would be more thorough, we don’t think that in practice it will find additional results.
If this changes we may reconsider. For example, if we see examples of application flaws that only occur on HTTP/2 that would be interesting.
If you only need the standard HTTP/1.1 Burp features, maybe you could set up MITMProxy so that Burp talks HTTP/1.1 to MITMProxy which then talks HTTP/2 to the target app?
You mean something like this here?
The HTTP/2 implementation in Apache Tomcat 9.0.0.M1 to 9.0.0.M21 and 8.5.0 to 8.5.15 bypassed a number of security checks that prevented directory traversal attacks. It was therefore possible to bypass security constraints using a specially crafted URL.
Sorry to say, but I would prefer to see burp being able to handle HTTP/2.0 instead of using additional proxies along the way.
I understand that most servers will fall back to HTML 1.1 but we need support when specifically looking for HTTP 2 vulnerabilities. When will Burp Suite support HTTP 2? Really need this feature!
We are getting a lot of requests for this. We are going to work on Web Sockets support first. We’ll get on to HTTP/2 after.
Thanks for letting us know. How does iOS v11 behave with Burp inline? Does it revert to HTTP/1.1?
Can you please let us know if HTTP/2 support is to be shipped with Burp? We are getting increased number of applications using HTTP/2.
Burp will get HTTP/2 support in the future, but it is likely to be some time. In our experience, all HTTP/2 applications also support HTTP/1.1. We also believe that application flaws that only affect HTTP/2 are likely to be rare, as in most cases application code is not aware of the HTTP version. If you have any experience of either of these not being true, please let us know, as it makes a case for bumping the priority of HTTP/2 support.
Has HTTP/2 been supported? natively in Burp Suite Pro?
Sorry, HTTP/2 is not implemented at present. It is in the plan, but it is likely to be some time until we get to it.
We have seen the applications running HTTP/2 applications supporting HTTP/1.1. Now, we are experiencing few applications not supporting HTTP/1.1 anymore. Expecting HTTP/2 support soon.
Hi Gareth, thanks for letting us know about that. Can I ask: what context is this happening in? Are these intranet apps or internet-facing?