<div dir="ltr"><div>[...] The other party MUST respond with a close_notify alert of its own and close down the connection immediately, <b>discarding any pending writes</b>.</div><div><br></div><div>I've read this before, but I've also checked the sources of SSL_write and they seem contradictory:<br></div><div><br></div><div>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 <b>discard any pending writes</b> then it surely seems a bug to allow SSL_write for a connection where SSL_RECEIVED_SHUTDOWN is set?</div><div><br></div><div>....</div><div><br></div><div>> If your question is whether you can still read any data that may have<br>
been in flight when you send your close_notify, I believe the answer<br>
is no.  Further data received from the peer is discarded after a<br>
close_notify is sent.<br></div><div><br></div><div>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.</div><div><br></div><div>Regarding the SSL_RECEIVED_SHUTDOWN - do you think this is a minor bug?<br></div></div><br><div class="gmail_quote"><div dir="ltr">Den ons 1 aug. 2018 kl 21:16 skrev Viktor Dukhovni <<a href="mailto:openssl-users@dukhovni.org">openssl-users@dukhovni.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Aug 1, 2018, at 2:27 AM, Alex H <<a href="mailto:alexhultman@gmail.com" target="_blank">alexhultman@gmail.com</a>> wrote:<br>
> <br>
> Is it possible to receive data after calling SSL_shutdown? Reading the specs and docs leaves this rather blurry.<br>
<br>
TLS *does not* support half-closed connections (RFC5246):<br>
<br>
   close_notify<br>
      This message notifies the recipient that the sender will not send<br>
      any more messages on this connection.  Note that as of TLS 1.1,<br>
      failure to properly close a connection no longer requires that a<br>
      session not be resumed.  This is a change from TLS 1.0 to conform<br>
      with widespread implementation practice.<br>
<br>
   Either party may initiate a close by sending a close_notify alert.<br>
   Any data received after a closure alert is ignored.<br>
<br>
   Unless some other fatal alert has been transmitted, each party is<br>
   required to send a close_notify alert before closing the write side<br>
   of the connection.  The other party MUST respond with a close_notify<br>
   alert of its own and close down the connection immediately,<br>
   discarding any pending writes.  It is not required for the initiator<br>
   of the close to wait for the responding close_notify alert before<br>
   closing the read side of the connection.<br>
<br>
   If the application protocol using TLS provides that any data may be<br>
   carried over the underlying transport after the TLS connection is<br>
   closed, the TLS implementation must receive the responding<br>
   close_notify alert before indicating to the application layer that<br>
   the TLS connection has ended.  If the application protocol will not<br>
   transfer any additional data, but will only close the underlying<br>
   transport connection, then the implementation MAY choose to close the<br>
   transport without waiting for the responding close_notify.  No part<br>
   of this standard should be taken to dictate the manner in which a<br>
   usage profile for TLS manages its data transport, including when<br>
   connections are opened or closed.<br>
<br>
   Note: It is assumed that closing a connection reliably delivers<br>
   pending data before destroying the transport.<br>
<br>
If your question is whether you can still read any data that may have<br>
been in flight when you send your close_notify, I believe the answer<br>
is no.  Further data received from the peer is discarded after a<br>
close_notify is sent.<br>
<br>
-- <br>
        Viktor.<br>
<br>
-- <br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
</blockquote></div>