Nginx support for TLS ALPS extension for ACCEPT_CH?

[Maxim Dounin]

Hello!

On Sun, Feb 25, 2024 at 08:18:56PM +0100, Matthias Saou wrote:

> Hi,
> 
> On Sat, 24 Feb 2024 03:02:35 +0300
> Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > Any specific details about "dropping the User-Agent"?  From 
> > https://developers.google.com/privacy-sandbox/protections/user-agent 
> > it looks like User-Agent is still here, provides basic information 
> > about client browser version and platform, and it is not going 
> > anywhere.
> 
> I got it wrong. Looks like all browsers are going to be Netscape 6.1
> until the end of times! :-)

Well, not really, but the only meaningful information included now 
is:

- browser name and version (also in Sec-CH-UA);
- mobile flag (also in Sec-CH-UA-Mobile);
- platform name (also in Sec-CH-UA-Platform).

This is a lot, and I tend to think this should be enough for most 
sites.  Still, it is certainly not the all information the browser 
can provide.

> My particular issue is actually with what is now sometimes missing from
> the User-Agent by default, such as the device brand (Samsung,
> Xiaomi...) or the OS version (Windows 10 or 11...).
> 
> If you know you need this data, then having a mechanism to keep having
> it included in the first http client response would make things a lot
> easier.

Yep, device brand and OS version are not available by default now.

> > Note that the draft-davidben-http-client-hint-reliability draft 
> > referenced in the Chrome feature (and the user-agent page) expired 
> > in 2021, and the same applies to the vvv-tls-alps and 
> > draft-vvv-httpbis-alps drafts.  This makes it highly unlikely to 
> > be ever supported by OpenSSL.
> > 
> > OTOH, if draft-davidben-http-client-hint-reliability is supported, 
> > the Critical-CH header should make it trivial (though potentially 
> > suboptimal, compared to ALPS) to request any specific hints if 
> > they are actually needed.  Without ALPS implemented, using the 
> > Critical-CH header might be a good alternative.
> 
> Thanks for the pointer! I just read up on
> https://datatracker.ietf.org/doc/html/draft-davidben-http-client-hint-reliability
> and the Critical-CH header probably wouldn't be suitable for our use
> case (since it will typically trigger a second client connection), but
> the ACCEPT_CH frame definitely would, especially given all these recent
> clients would be connecting over HTTP/2 or newer. But that draft seems
> to also have expired in 2021, no?

Yep, the particular Chrome feature is based on this draft, and it 
expired in 2021.

The difference between the Critical-CH header and the ACCEPT_CH 
frame sent via ALPS is that ALPS information is sent to the 
browser before the first request, so the browser is able to 
provide requested headers in the first request.  With the 
Critical-CH header, the browser instead sees the list of requested 
headers with the first response.  But it's browser's 
responsibility to retry the request with appropriate headers 
provided, so there is no need to do anything on the server side.  

That is, the Critical-CH header implies additional HTTP request, 
while ACCEPT_CH sent via ALPS implies additional information sent 
during SSL handshake.  ALPS-based negotiation might be more 
optimal, but it's certainly a layering violation, and hence 
somewhat questionable solution (I haven't followed IETF 
discussions about the drafts, but I guess that's the main concern 
here, and might be the reason why these drafts expired).

As far as I understand, the Critical-CH header should be good 
enough for most use cases, except might be for statistical 
counters which often use just one HTTP request, and therefore 
another one will be a huge change.

If you are able to share, it would be great if you'll provide more 
details about your use case.

> So it seems like as of right now, with recent Chrome & Edge clients,
> there is no way to have nginx receive more than the 3 default client
> hints during the first client http connection?

Yes, there is no support now (except the patch you've mentioned).

-- 
Maxim Dounin
http://mdounin.ru/