Well, this is like TCP in that respect. You send close_notify and then you
either stop reading off of or close the TCP socket.
On Wed, Mar 7, 2018 at 9:40 AM, Xuelei Fan <xuelei....@vimous.com> wrote:
> Per TLS 1.3 draft (Section 6.1, Closure Alerts), the close_notify alert is
> used to notify the recipient that the sender will not send any more
> messages on this connection. And this does not have any effect on its read
> side of the connection. I think it means that after sending the
> close_notify alert, it still can keep reading data from the peer; and after
> receiving the close_notify alert, it still can keep sending data to the
> The question comes to me is about how to close the read side of the
> connection. If closing the read side silently, there are potential issues
> if the application protocol using TLS provides that any data may be carried
> over the underlying transport after the TLS connection is closed. If
> sending a close_notify alert, the peer may just treat is as close the its
> read side and may keep write in its write side. It does not actually close
> the read side cleanly. If keep waiting for the close_notify from the peer,
> the local may have to wait until the peer happy to close its write side.
> It does not sound friendly to the local side. From example, if I download
> a 10GB video via TLS 1.3 over VPN, looks like there is no way to indicate
> the server that I want to cancle in the middle of the downloading in TLS
> layer. I may miss something. I did not find a solution about how to close
> the read side of TLS 1.3 connections yet. Please help if you have an idea!
> It's not a problem in TLS 1.2 and prior versions, as the peer MUST respond
> with a close_notify of its own after receiving a close_notify alert.
> Xuelei Fan
> TLS mailing list
TLS mailing list