[openssl-users] when should client stop calling SSL_read to get TLS1.3 session tickets after the close_notify?

Matt Caswell matt at openssl.org
Sun Feb 17 13:26:39 UTC 2019

On 16/02/2019 05:04, Sam Roberts wrote:
> On Fri, Feb 15, 2019 at 3:35 PM Matt Caswell <matt at openssl.org> wrote:
>> On 15/02/2019 20:32, Viktor Dukhovni wrote:
>>>> On Feb 15, 2019, at 12:11 PM, Sam Roberts <vieuxtech at gmail.com> wrote:
>>> OpenSSL could delay the actual shutdown until we're about to return
>>> from the SSL_accept() that invoked the callback.  That is SSL_shutdown()
>>> called from callbacks could be deferred until a more favourable time.
> In this case, it's an SSL_read() that invoked the callback, though
> probably not relevant.
> And actually, no deferal would be necessary, I looks to me that the
> info callback for handshake done is coming too early. Particularly,
> the writing of the NewSessionTickets into the BIO should occur before
> the info callback. I'll check later, but I'm pretty sure with TLS1.2
> the session tickets are written and then the HANDSHAKE_DONE info
> callback occurs, so the timing here is incompatible with TLS1.2.

In TLSv1.2 New session tickets are written as part of the handshake. In TLSv1.3
session tickets are sent after the handshake has completed. It sounds to me like
the info callback is doing the right thing.

> Though the deferal mechanism might be there already. It looks like
> doing an SSL_write(); SSL_shutdown() in the info callback works fine,
> on the client side new ticket callbacks are fired by the SSL_read()
> before the SSL_read() sees the close_notify and returns 0. I haven't
> looked at the packet/API trace for this, because the tests all pass
> for this case, but I do see that in the javascript called from the
> HANDSHAKE_DONE callback, that calling .end("x") (write + shutdown)
> causes the client to get tickets, but .end() causes it to miss them
> because they are after close_notify.
>> Oh - right. I missed this detail. Calling SSL_shutdown() from inside a callback
>> is definitely a bad idea. Don't do that.
> The info callback, or ANY callbacks? What about the new ticket
> callback, for example? Is it expected that no SSL_ calls are made in
> ANY callbacks?

I wouldn't go that far. Callbacks occur during the processing of an IO
operation. Callbacks are generally expected to be small and quick. I wouldn't
call anything that might invoke a new IO operation from within a callback, so
SSL_read, SSL_write, SSL_do_handshake, SSL_shutdown etc.


More information about the openssl-users mailing list