[openssl-users] Shutdown details

[Alex H]

[...] 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>:

>
>
> > On Aug 1, 2018, at 2:27 AM, Alex H <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180801/201e6c5b/attachment.html>