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 <alexhult...@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-us...@dukhovni.org <mailto:openssl-us...@dukhovni.org>>: > > > > On Aug 1, 2018, at 2:27 AM, Alex H <alexhult...@gmail.com > > <mailto:alexhult...@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
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
