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

[Sam Roberts]

Resending, I just got banned for "bounces", though why gmail would be
bouncing I don't know.

On Thu, Feb 14, 2019 at 2:51 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
 not.

 This is the trace, edited to reduce SSL_trace verbosity:

 server TLSWrap::SSLInfoCallback(where SSL_CB_HANDSHAKE_DONE, alert U)
 established? 0
     state 0x21 TWST: SSLv3/TLS write session ticket TLSv1.3
 server TLSWrap::DoShutdown() established? 1 ssl? 1
 Sent Record
   Inner Content Type = Alert (21)
   Level=warning(1), description=close notify(0)
 Sent Record
     NewSessionTicket, Length=245
 Sent Record
     NewSessionTicket, Length=245


 client TLSWrap::OnStreamRead(nread 566)
 Received Record
     Level=warning(1), description=close notify(0)

     SSL_read() => 0
     SSL_get_shutdown() => SSL_RECEIVED_SHUTDOWN
     SSL_get_error() => SSL_ERROR_ZERO_RETURN

 At this point, we consider the connection closed... not sure what else to do.

 Thanks,
 Sam