On 12/08/18 20:59, Viktor Dukhovni wrote: > > >> On Aug 12, 2018, at 2:49 PM, Kurt Roeckx <kurt@xxxxxxxxx> 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). Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
