Re: Content-Encoding and MITM devices

[Lucas Pardue <[e-mail]>]

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

> More inline...
>
> On Thu, Apr 4, 2024 at 10:24 AM Lucas Pardue <[e-mail]>
> wrote:
>
>>
>> On Thu, 4 Apr 2024, 14:20 Patrick Meenan, <[e-mail]> wrote:
>>
>>> 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.
>>
>
> I can't speak to MITM HTTP/3 being safe or not, just that HTTP/3 from
> Chrome's current config was clean and HTTP/1.1 and HTTP/2 was fine when not
> MITM but had elevated errors when MITM. I was under the impression that
> enterprises generally block UDP 443 to force TCP that can be intercepted
> with existing equipment but I guess there could be HTTP/3 (well, QUIC
> specifically) interceptors as well.
>

To use an example I am familiar with, Cloudflare has a products for HTTP
inspection that supports HTTP/3 [1]. The typical use case is an
organisation  provisions employees computers with the required trust roots.
Such orgs are not blocking UDP or QUIC, rather Chrome is not accepting
connections that attempt to use certs tied to that root. The MITM
deployment effectively allows all certs to be created this way and there is
no means to pass a wildcard to Chrome, it needs an explicit list. In theory
if you had a set of origin trial domains for an explicit list, you could
ask some volunteers to trial out their MITM to see how it deals with H3 and
compression dictionaries.


>
>>
>>> - 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 ;-) )
>>
>
> For content-encoding specifically, would it be worth greasing different
> encoding types so the next time it is changed we can be sure that MITM
> software correctly modifies the accept-encoding to what they support rather
> than just adding support for each new encoding as it happens.
>

I'm not sure how we would test that unless the server receiving the
accept-encoding knew the request was coming via an intermediary. Which is
possibly your motivations for asking about signalling?


>
>>
>> - 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.
>>
>>
> Agreed that there are likely privacy/fingerprinting things to worry about
> here but there are probably privacy aspects on both sides of it (the
> connections not being e2e private on the network path). Granted, once
> someone has access to the end device, it can't be trusted so whatever
> installed the local trust root could also monitor by other means but it
> also feels a bit wrong to provide no indication of the potential for
> network intercept (maybe it's a product issue more than a protocol issue).
>

The concerns I heard were not about a MITM in the network. Instead it was
more wrt things like on-device Antivirus software. The user (or their
admin) has already made the decision to enroll in the MITM and accept the
risks thst come with it. Revealing that a MITM was in place and used, to
some untrusted third-party (the web server, or the user agent vendor), was
where the privacy concerns were pointed. NB: I'm not supporting nor
refuting those concerns, just trying to clarify


[1] - https://blog.cloudflare.com/cloudflare-gateway-http3-inspection

>