http: allow ignoring unknown upgrade requests

[ggreenway]

Fixes #36305

Add configuration to ignore either all unknown upgrade requests, or specific upgrade requests. This is allowed in https://datatracker.ietf.org/doc/html/rfc7230#section-6.7:

A server MAY ignore a received Upgrade
header field if it wishes to continue using the current protocol on
that connection.

Risk Level: Medium
Testing: TODO
Docs Changes:
Release Notes: TODO

[repokitteh-read-only]

As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

🐱

Caused by: #37150 was opened by ggreenway.

see: more, trace.

[repokitteh-read-only]

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/).
envoyproxy/api-shepherds assignee is @abeyad
CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).

🐱

Caused by: #37150 was opened by ggreenway.

see: more, trace.

[ggreenway]

Initial questions:

1. Is this the right way to ignore upgrades?
2. Is it better to default the global-ignore to true or false?
3. Do we need to handle h2/h3 specially? My understanding is that the Upgrade header doesn't apply to them at all (https://www.rfc-editor.org/rfc/rfc9113#name-the-upgrade-header-field).

[alyssawilk]

cc @RyanTheOptimist for spec thoughts

[alyssawilk]

I'm fine with this conceptually but as commented would like @RyanTheOptimist (or @DavidSchinazi but he's less likely to respond) thoughts from a spec perspective
and tests, obviously but it's still a draft so can wait for those =P

[alyssawilk]

I think move the comments below up here in case the enum gets used multiple places

[RyanTheOptimist]

Yes, Upgrade is HTTP/1 only. However Extended CONNECT provides similar capabilities for H2 and H3. Do we have a similar configuration method for this?

[chlunde]

It would be nice if you could explicitly describe what this means.

Ignore could mean pass through or the header could be discarded. Also, there are two headers involved, connection and upgrade. The user should understand the implication for both of them, without reading the source code.

[ggreenway]

As mentioned by @chlunde above, we also need to remove the parts of the Connection header for upgrades. When looking at that, I found other code that removes h2c upgrades, and found that there is another portion for h2c that needs to be removed (http2-settings). Are there similar bits for other types of upgrades? And if there are, is there any risk if they are not removed?

[DavidSchinazi]

There's an important distinction between HTTP versions here:

• Upgrade is used only in HTTP/1.1, it is documented in Section 7.8 of RFC 9110
• Extended CONNECT is used only in HTTP/2 and HTTP/3, it is documented in RFC 8441 and RFC 9220

(As a quick side note, RFC 7230 has been obsoleted by RFC 9110 and RFC 9112, please do not refer to it as some parts of it are incorrect).

They behave differently: in particular, in HTTP/1.1 the server can "ignore" the Upgrade and still send a successful HTTP/1.1 response without upgrading to a different protocol. In HTTP/2 and 3 however, that is not possible. If the server does not wish to use the other protocol, it has no choice but to reject the request.

This gets particularly tricky because Envoy normalizes every Extended CONNECT internally to look like Upgrade. So the information of whether ignoring is allowed or not gets somewhat hard to track down inside Envoy.

I worry that this will cause protocol confusion or request smuggling attacks, unless there are strong safeguards in place to ensure that this cannot happen in HTTP/2 or HTTP/3.

[ggreenway]

@DavidSchinazi thanks for the clarification on this. I added a check, and renamed the config fields, to document and ensure that ignoring upgrades only happens on http 1.1.

[DavidSchinazi]

Thanks @ggreenway ! As far as I can tell, this looks safe from a spec perspective. But I'll let folks more familiar with Envoy internals do the detailed code review.

[ipoval]

@ggreenway 👋 , hi, what is going to be the expected behavior after this fix for the HTTP2 upstreams? Is it going to be safe to use HTTP2 clusters when clients supply -H "Connection: Upgrade" -H "Upgrade: TLS/1.3" headers for example? Just want to double check expectations after reading (https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-upgradeconfig) that upgrade config does not work with HTTP2

[ggreenway]

@ipoval when Envoy ignores a downstream http/1.1 upgrade request, it will remove the upgrade headers from the request, so the request should be fine for any upstream http version because it no longer requests an upgrade.

[ggreenway]

Integration tests reveal that this doesn't work. The http1 codec handles request processing differently if it thinks an upgrade is happening; see handling_upgrade_ in http1/codec_impl.cc.

[ggreenway]

A fix for this would probably have to be in the http1 codec_impl, but that doesn't have access to the configured upgrades which are processed later, so it would probably need to be a change that specifically ignores TLS upgrades.