[openssl-users] when should client stop calling SSL_read to get TLS1.3 session tickets after the close_notify?
matt at openssl.org
Fri Feb 15 23:25:35 UTC 2019
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.
More information about the openssl-users