Re: tls 1.3: sending multiple tickets

> On 24 Jul 2024, at 07:44, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>
> On 18/06/2024 16:11, Daniel Gustafsson wrote:
>>> On 17 Jun 2024, at 19:38, Andres Freund <andres@anarazel.de> wrote:
>>> Seems we ought to use SSL_CTX_set_num_tickets() to prevent issuing the useless
>>> tickets?
>> Agreed, in 1.1.1 and above as the API was only introduced then.  LibreSSL added
>> the API in 3.5.4 but only for compatibility since it doesn't support TLS
>> tickets at all.
>
> Wow, that's a bizarre API. The OpenSSL docs are not clear on what the possible values for SSL_CTX_set_num_tickets()
are.It talks about 0, and mentions that 2 is the default, but what does it mean to set it to 1, or 5, for example? 

It means that 1 or 5 tickets can be sent to the user, OpenSSL accepts an
arbitrary number of tickets (tickets can be issued at other points during the
connection than the handshake AFAICT).

> Anyway, it's pretty clear that SSL_CTX_set_num_tickets(0) can be used to disable tickets, so that's fine.
>
>>> It seems like a buglet in openssl that it forces each session tickets to be
>>> sent in its own packet (it does an explicit BIO_flush(), so even if we
>>> buffered between openssl and OS, as I think we should, we'd still send it
>>> separately), but I don't really understand most of this stuff.
>> I don't see anything in the RFCs so not sure.
>> The attached applies this, and I think this is backpatching material since we
>> arguably fail to do what we say in the code.  AFAIK we don't have a hard rule
>> against backpatching changes to autoconf/meson?
>
> Looks good to me. Backpatching autoconf/meson changes is fine, we've done it before.

Thanks for review, I've applied this backpatched all the way.

--
Daniel Gustafsson