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

[Matt Caswell]

On 15/02/2019 20:32, Viktor Dukhovni wrote:
>> On Feb 15, 2019, at 12:11 PM, Sam Roberts <vieuxtech at gmail.com> wrote:
>>
>> In particular, I'm getting a close_notify alert, followed by two
>> NewSessionTickets from the server.
>>
>> The does SSL_read()/SSL_get_error(), it is returning
>> SSL_ERROR_ZERO_RETURN, so I stop calling SSL_read().
>>
>> However, that means that the NewSessionTickets aren't seen, so I don't
>> get the callbacks from SSL_CTX_sess_set_new_cb().
>>
>> Should we be  calling SSL_read() until some other return value occurs?
>>
>> Note that no data is written by the server, and SSL_shutdown() is
>> called from inside the server's SSL_CB_HANDSHAKE_DONE info callback.
>> The node test suite is rife with this pracitce, where a connection is
>> established to prove its possible, but then just ended without data
>> transfer. For TLS1.2 we get the session callbacks, but TLS1.3 we do
> 
> The code that's calling SSL_shutdown from the middle of the callback
> is too clever by half.  It well and truly *deserves* to break.
> 
> Which is not to say that everything that's deserved should necessarily
> happen, sometimes reality is more forgiving than just.  Perhaps that
> should also the case here, but maybe not.
> 
> 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.
> 
> Not sure whether the complexity of doing this is warranted.  Perhaps
> the all too clever code should get its just deserts after all.
> 

Oh - right. I missed this detail. Calling SSL_shutdown() from inside a callback
is definitely a bad idea. Don't do that.

Matt