Re: when should client stop calling SSL_read to get TLS1.3 session tickets after the close_notify?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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.

-- 
	Viktor.




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux