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]

 



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) established? 1 ssl? 1 parsing?
0 eof? 0
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
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



[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