Can you elaborate on what proxy protocol you're using that can reuse the TCP
connection for follow on connections, and what semantics it has?
As far as I know, SOCKS and HTTP CONNECT don't support this.
Additionally, the close_notify alerts are sent encrypted so the proxy wouldn't
be able to tell that applications are done with TLS.
> On Mar 7, 2018, at 11:24, Xuelei Fan <xuelei....@vimous.com> wrote:
> Hi David,
> This issue happens when the TLS connection is established/layered on an
> existing TCP connection. For example:
> 1. A client connects to a proxy
> 2. The client establishes a TLS 1.3 connection to a server via the proxy.
> 3. The server delivers 2+ records to the client.
> 4. The client receives the 1st record, and intends to close the TLS connection
> As the existing TCP connection may be used for follow on connections, it
> might not be a solution to close the TCP connection directly. And the client
> would better cleanup the data delivered by the server. Otherwise, the data
> may be used by the next follow on connection and may cause unknown issues.
> Then the question comes to me: how does the client close the TLS connection?
> Closing the TCP connection may be not desired as it does not really have a
> TCP connection to the server. It would be nice to close the TLS connection
> but keeping the TCP connection alive.
> Looks like there is no way to close the read side of a TLS connection in TLS
> layer per the current TLS 1.3 specification. The close_notify is used to
> indicate the closure of client write side, but not the server write side. If
> the client sends the close_notify for read side closure, after receiving the
> close_notify the server side will not receive data, but may still send data.
> Even if the server side stop sending data, the client side does not actually
> know how may data has been delivered by the server, and how to clean up the
> TLS channel.
> For such cases in TLS 1.2, the client can send a close_notify alert and then
> wait for the server close_notify alert, and all of the intermediate data is
> discarded. There are still some problems, but in theory the client can
> cleanup the TCP channel.
> In the TLS 1.3 specification, it says:
> 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 a "close_notify" alert
> before indicating end-of-data to the application-layer.
> For client read side in above case, it means that the server side MUST
> deliver a close_notify. But it does not say if a client initiates the TLS
> closure, how could the client indicates the server for a close_notify alert.
> Thanks for the suggestion of TCP RST option. I will evaluate if TCP options
> can help.
> Thanks & Regards,
> Xuelei Fan
> On Wed, Mar 7, 2018 at 10:19 AM, David Schinazi <dschin...@apple.com
> <mailto:dschin...@apple.com>> wrote:
> Hi Xuelei,
> 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.
> David Schinazi
>> On Mar 7, 2018, at 09:51, Eric Rescorla <e...@rtfm.com
>> <mailto: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@ietf.org <mailto:TLS@ietf.org>
TLS mailing list