fix: workaround for CVE-2023-44487

[lzap]

How to test this:

curl --http2 .... stage_url

Stage environment is accessible via the proxy and I just verified that HTTP2 works fine through curl, let’s merge this and see if it is disabled.

[lzap]

For the record, before the patch:

$ curl -vso --http2 -s --header XXX --proxy XXX URL 2>&1 | grep HTTP
> CONNECT xxx:443 HTTP/1.1
< HTTP/1.1 200 Connection established
* using HTTP/2
> GET /api/sources/v3.1/sources/XXXXXXX/authentications HTTP/2
< HTTP/2 200 

[ezr-ondrej]

Can you pls link to https://issues.redhat.com/browse/HMS-2765?

EDIT: I've squashed commited it with proper ref.

[ezr-ondrej]

Lets try, I'd still love to reenable as fast as possible, but if this helps to give us time for proper solution, perfect :)

[lzap]

And it does NOT work. :-)

< HTTP/1.1 200 Connection established
* using HTTP/2
> GET /api/provisioning/v1/ready HTTP/2
< HTTP/2 200 

[lzap]

It might work, this needs to confirm it:

#714

Here is also a revert PR - do not merge until we upgrade to patched Go runtime.

#713

[lzap]

So I can say that HTTP/2 is not in use after I added "proto" field into logs:

That does not prove the setting does work, 3scale could have been using 1.1 before the change as well.

[lzap]

Ah I have found a field that actually shows HTTP version for the whole time: @log_group: "provisioning-cloudwatch-stage" and @log_stream: "api" and http.flavor: 1*