Used HTTP protocol version information lost

[sleeyax]

Currently there's no way to know which HTTP version was used to actually send the request because the "spoof TLS proxy" part of the extension is basically a HTTP 1 web server and thus burp automatically assumes HTTP 1 was used. This can cause confusions like #73.

I don't think there's a straightforward way to solve this issue because from Burps POV the protocol version is the version that the "spoof TLS proxy" server uses. We can't magically switch protocols after the actual request completed, i.e. when we know the actual used HTTP version after ALPN with the "destination".

If there's no convenient way to set it directly via Burp's Java API (so to manipulate the request viewer directly), perhaps we can simply provide another way to provide it like in the extension logs and document it as a limitation.

[AmmeySaini]

how about we forcefully use the protocol of the original request during the interception? we can use ForceAttemptHTTP2 ?? however, it will still not give us clarity on what protocol was used but at least we will have the security of the right one being negotiated.

[sleeyax]

how about we forcefully use the protocol of the original request during the interception? we can use ForceAttemptHTTP2 ??

Not sure what you mean or how this would work in practice. The HTTP protocol is not hard-coded by burp, it's determined based on the ALPN with the intercept proxy. Assuming that's what you're trying to do.

From the burp suite docs:

By default, Burp uses HTTP/2 to communicate with all servers that advertise support for it during the TLS handshake.

It's kinda hard to explain, maybe I should try to create a diagram to help explain the problem I have in mind.

[AmmeySaini]

I got your point, just for simplicity can we add below as a feature for future releases When we write back the response to the burp can we add an additional response header example: x-proto-negotiated For example if a request was done using http2 we can write x-proto-negotiated: h2

[sleeyax]

That's another possibility, but I'd like to avoid that approach if possible because it may be confusing. Something like x-proto-negotiated is not a standard header and people might accidentally include it in external tools or scripts.