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