Nginx support for TLS ALPS extension for ACCEPT_CH?

[Maxim Dounin]

Hello!

On Mon, Feb 26, 2024 at 06:13:42PM +0100, Matthias Saou wrote:

> On Mon, 26 Feb 2024 01:34:31 +0300
> Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > [...]
> > 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.
> 
> A very simple use case is basic contextual ads. Presenting a somewhat
> targeted ad with no user information, no session cookie, nothing more
> than what a single http request provides. This means using in real time
> things like the referer header, the accepted languages and the
> user-agent string.
> 
> The Mobile and Platform UA-CH headers do still provide the most
> critical information for this, so it's more about the corner cases: If
> an Android app is only compatible with Android 10 and up, you don't
> want to be advertising to users of Android 9 and below.

Thanks for the use case description.

> Delivering such a targeted ad currently requires only one http request.

You mean - only one http request, assuming the javascript code to 
show ads is previously loaded from another domain?  Note that 
loading the code from the same origin with appropriate Accept-CH 
header might be the way to go.

> But with a reduced User-Agent and the Platform-Version CH header
> missing, it's no longer possible. What can be tried is:
> 
> * Replying with the Critical-CH header. The client might then re-request
>   an ad... or not, which will skew things quite a bit.
> * Redirect the client in order to request the header. You expose
>   yourself to potential infinite redirection bugs and use more
>   resources because of the extra http request.

Yep, Critical-CH is, basically, a simpler alternative to 
error-prone redirects with Accept-CH.  It doesn't save a backend 
request though, in case the first response is not really used due 
to re-request with critical hints provided.

Another alternative might be to use Accept-CH, and do not show 
versions-specific ads to clients without platform version 
provided.  That is, such ads will be shown only to clients which 
did more than one request.  Might be good enough for a corner 
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).
> 
> I *really* wanted to avoid having to dig that patch up and potentially
> have to switch TLS library just to make this work! :-)
> 
> I also wanted to avoid having to implement a redirection in nginx, but
> I think I will have to also try something like this out in case it does
> end up working reliably:
> 
> * If our parameter indicating we already redirected is missing,
> * And the UA-CH Mobile header is present,
> * And the UA-CH Platform-Version header is absent,
> * Then redirect to the same URL but appending our parameter indicating
>   we already redirected.
> 
> This way it could potentially still achieve triggering a single request
> to the backend nginx is using, that would include the Platform-Version
> if the client agreed to provide it.

Yep, looks correct and safe enough, in case the goal is to save 
backend requests.

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