Re: Shutdown details

[Philip Prindeville <philipp_subx@xxxxxxxxxxxxxxxxxxxxx>]

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 <alexhultman@xxxxxxxxx> 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@xxxxxxxxxxxx>:

> On Aug 1, 2018, at 2:27 AM, Alex H <alexhultman@xxxxxxxxx> 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