[openssl-users] Shutdown details

[Alex H]

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_subx at 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 <alexhultman at 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-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
>>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180811/31a9d0a2/attachment-0001.html>