On 15/02/2019 20:32, Viktor Dukhovni wrote: >> On Feb 15, 2019, at 12:11 PM, Sam Roberts <vieuxtech@xxxxxxxxx> 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
