Do you have an example for when you would need to gracefully close the read
If you're downloading a 10GB video and the user cancels the download, you can
simply tear down the TCP connection by sending a RST.
The benefit of having a graceful read close would be for the server to know
that the client application was done, but in the 10GB video example,
I don't see what the server application would do with that information. Do you
have an example where the server would treat a graceful read close
differently from a non-graceful close? In TLS 1.2 and prior, the client would
send a close_notify, the server would reply with a close_notify
in the middle of the 10GB of application data. That actually doesn't provide
any gracefulness to the server application - the point of close_notify
is to indicate that the data you're sending hasn't been truncated, and in this
example it does get truncated.
> On Mar 7, 2018, at 09:51, Eric Rescorla <e...@rtfm.com> wrote:
> 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
> <mailto: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 peer.
> 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@ietf.org <mailto:TLS@ietf.org>
> TLS mailing list
TLS mailing list