[openssl-users] Shutdown details

Philip Prindeville philipp_subx at redfish-solutions.com
Sat Aug 11 00:23:45 UTC 2018


Hi.

This is something that I’m also interested, as a contributor to Libevent, which provides SSL-socket support.

I’ve opened an OpenSSL issue:

https://github.com/openssl/openssl/issues/6911 <https://github.com/openssl/openssl/issues/6911>

to collect the details on how a graceful shutdown can be implemented in Libevent.

Thanks,

-Philip


> On Aug 1, 2018, at 1:46 PM, Alex H <alexhultman at gmail.com> wrote:
> 
> [...] The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes.
> 
> I've read this before, but I've also checked the sources of SSL_write and they seem contradictory:
> 
> SSL_write does not return with error when SSL_RECEIVED_SHUTDOWN is set, but does so when SSL_SENT_SHUTDOWN is set. Why is this? A minor bug? If the RFC states the end who receives a close_notify should discard any pending writes then it surely seems a bug to allow SSL_write for a connection where SSL_RECEIVED_SHUTDOWN is set?
> 
> ....
> 
> > If your question is whether you can still read any data that may have
> been in flight when you send your close_notify, I believe the answer
> is no.  Further data received from the peer is discarded after a
> close_notify is sent.
> 
> I also believe so, especially since SSL_shutdown docs seem to hint that once SSL_shutdown is called, it should be called again until fully done (serving SSL_WANT_READ/WRITE as needed). In other words, SSL_shutdown becomes the only function called until the SSL connection is fully closed, no more SSL_read is called and thus it cannot report any received data. SSL_shutdown does not return with any data.
> 
> Regarding the SSL_RECEIVED_SHUTDOWN - do you think this is a minor bug?
> 
> Den ons 1 aug. 2018 kl 21:16 skrev Viktor Dukhovni <openssl-users at dukhovni.org <mailto:openssl-users at dukhovni.org>>:
> 
> 
> > On Aug 1, 2018, at 2:27 AM, Alex H <alexhultman at gmail.com <mailto:alexhultman at gmail.com>> wrote:
> > 
> > Is it possible to receive data after calling SSL_shutdown? Reading the specs and docs leaves this rather blurry.
> 
> TLS *does not* support half-closed connections (RFC5246):
> 
>    close_notify
>       This message notifies the recipient that the sender will not send
>       any more messages on this connection.  Note that as of TLS 1.1,
>       failure to properly close a connection no longer requires that a
>       session not be resumed.  This is a change from TLS 1.0 to conform
>       with widespread implementation practice.
> 
>    Either party may initiate a close by sending a close_notify alert.
>    Any data received after a closure alert is ignored.
> 
>    Unless some other fatal alert has been transmitted, each party is
>    required to send a close_notify alert before closing the write side
>    of the connection.  The other party MUST respond with a close_notify
>    alert of its own and close down the connection immediately,
>    discarding any pending writes.  It is not required for the initiator
>    of the close to wait for the responding close_notify alert before
>    closing the read side of the connection.
> 
>    If the application protocol using TLS provides that any data may be
>    carried over the underlying transport after the TLS connection is
>    closed, the TLS implementation must receive the responding
>    close_notify alert before indicating to the application layer that
>    the TLS connection has ended.  If the application protocol will not
>    transfer any additional data, but will only close the underlying
>    transport connection, then the implementation MAY choose to close the
>    transport without waiting for the responding close_notify.  No part
>    of this standard should be taken to dictate the manner in which a
>    usage profile for TLS manages its data transport, including when
>    connections are opened or closed.
> 
>    Note: It is assumed that closing a connection reliably delivers
>    pending data before destroying the transport.
> 
> If your question is whether you can still read any data that may have
> been in flight when you send your close_notify, I believe the answer
> is no.  Further data received from the peer is discarded after a
> close_notify is sent.
> 
> -- 
>         Viktor.
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users <https://mta.openssl.org/mailman/listinfo/openssl-users>
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180810/3f6c55db/attachment.html>


More information about the openssl-users mailing list