Hi Xuelei, 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.
Thanks, David > 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 > side? > 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. > > Thanks, > 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. >> >> -Ekr >> >> >> On Wed, Mar 7, 2018 at 9:40 AM, Xuelei Fan <xuelei....@vimous.com >> <mailto:xuelei....@vimous.com>> wrote: >> Hi, >> >> 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. >> >> Thanks, >> Xuelei Fan >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org <mailto:TLS@ietf.org> >> https://www.ietf.org/mailman/listinfo/tls >> <https://www.ietf.org/mailman/listinfo/tls> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org <mailto:TLS@ietf.org> >> https://www.ietf.org/mailman/listinfo/tls >> <https://www.ietf.org/mailman/listinfo/tls> > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
