Re: Content-Encoding and MITM devices

More inline...

On Thu, Apr 4, 2024 at 10:24 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

>
> On Thu, 4 Apr 2024, 14:20 Patrick Meenan, <patmeenan@gmail.com> 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.


>
>> - 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.


>
> - 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).