I ended up just treating those details as "unknown" and making my interface more low-level than I first aimed for.
I wanted to make the shutdown procedure more automated with a simpler API that wrapped things at a higher level but ended up with pretty much BSD-sockets, but SSL. It is pretty easy to implement when you allow a little bit of uncertainty - it's not required to know 100% of how the internals work to implement shutdown. Den lör 11 aug. 2018 kl 02:41 skrev Philip Prindeville < philipp_s...@redfish-solutions.com>: > 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 > > 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>: > >> >> >> > On Aug 1, 2018, at 2:27 AM, Alex H <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 >> > -- > 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 >
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
