[openssl-users] Shutdown details

Matt Caswell matt at openssl.org
Mon Aug 13 12:08:12 UTC 2018

On 12/08/18 20:59, Viktor Dukhovni wrote:
>> On Aug 12, 2018, at 2:49 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
>> TLS 1.3 makes it explicit that after you've send a close_notify,
>> the peer is still allowed to send data, so you can still read
>> data. It only closes the connection in one direction.
> Which is a change from previously required behaviour:
>    https://tools.ietf.org/html/rfc8446#section-6.1
>    Each party MUST send a "close_notify" alert before closing its write
>    side of the connection, unless it has already sent some error alert.
>    This does not have any effect on its read side of the connection.
>    Note that this is a change from versions of TLS prior to TLS 1.3 in
>    which implementations were required to react to a "close_notify" by
>    discarding pending writes and sending an immediate "close_notify"
>    alert of their own.  That previous requirement could cause truncation
>    in the read side.  Both parties need not wait to receive a
>    "close_notify" alert before closing their read side of the
>    connection, though doing so would introduce the possibility of
>    truncation.
>> As far as I know, OpenSSL has always supported this, even when the
>> RFC said that the other side needs to send the close_notify back
>> on receiving it.
> We might want to double-check that, I would have expected RFC-compliance
> here...  Matt Caswell should know the definitive answer...

We didn't make any changes to enable that for TLSv1.3. The library
already supported it - although perhaps the documentation wasn't so
clear (which should hopefully be fixed now).


More information about the openssl-users mailing list