Re: Content-Encoding and MITM devices

[Lucas Pardue <[e-mail]>]

Hi Pat,

Responding to some points in line:


On Thu, 4 Apr 2024, 14:20 Patrick Meenan, <[e-mail]> wrote:

> As part of Chrome's origin trial for compression dictionaries (which is
> enabled over secure-contexts only), we are seeing elevated connection
> issues on HTTP/1.1 and HTTP/2 but not HTTP/3.
>
> It's visible from both Chrome and from some of the origin trial
> participants, seeing elevated failures. From Chrome's side, it looks to be
> limited to cases where the connection certificate is not anchored to a
> well-known trust root (i.e. likely a MITM proxy using a local trust root).
>
> This seems to match what Edge was seeing with the zsdch deployment:
> https://techcommunity.microsoft.com/t5/discussions/edge-and-bing-search-zsdch-encoding-why-is-it-being-used/m-p/3881170/thread-id/60032
>
> We were hopeful that the work to launch brotli had cleaned up a bunch of
> the MITM issues but it looks like they are an ongoing problem for
> content-encoding.
>
> For any launch with Chrome, we will figure out how to do it as cleanly as
> possible (enterprise policy, tie the feature to a version release, etc) but
> if you know of anyone responsible for a MITM proxy/firewall that might be
> affected, it would be worthwhile to give them a heads-up that it is coming.
>
> Longer-term it would be nice if we can find a way to keep the situation
> from getting worse (I don't want to end up in a place where we can only
> launch features and protocol changes to HTTP/3 connections to well-known
> trust roots).
>

IIUC correctly, Chromium connection policy does not support MITM for HTTP/3
unless there is an explicit list is passed in via a command line option. In
other words, blanket MITM QUlC is not supported and the browser fails back
to TCP-based HTTP.  So the numbers you see are likely affected by that
policy. Just wanted to check if you'd factored that into the analysis or
not.

Other browsers or user agents that don't implement such a policy would, I
suspect, see equivalent error rates across H2 and H3 MITM'd connections.


> Some thoughts:
>
> - Should we start greasing existing HTTP header fields (or at least the
> content-encoding)?
>

I think that depends on the failure types you are observing. Is the
intermediary erroring in the presence of a header field value, or because
of actual content negotiation? It can be hard to grease actual functional
code paths (in effect, it seems like you are already doing so in your
origin trial ;-) )

- Should information about the trust root used for a connection be
> web-exposed, server-exposed or user-exposed?
>

I suspect this might have some privacy implications. There was some chatter
in the last couple of years about how one of the resource/perf timing APIs
that exposes nextHopProtocol could reveal the presence of a proxy and that
it has privacy implications.

There was also some chatter in the community about logging whether
connections had traversed some form of non-MITM proxy (e.g. whether video
had been played over something like private relay), targeted more at trying
to spot on aggregate whether performance characteristics were affected when
going direct vs proxied.

I don't have a direct answer to your suggestion, other than there are
non-technical items to resolve before we might think about any solutions.

Cheers
Lucas

>