On Thu, Jul 12, 2018 at 2:30 PM Xuelei Fan <xuelei....@oracle.com> wrote: > On 7/12/2018 10:47 AM, Simone Bordet wrote: > > On Thu, Jul 12, 2018 at 4:34 PM Xuelei Fan <xuelei....@oracle.com> wrote: [...] > >> In TLS 1.3, half-close policy is used. The server may not response with > >> the close_notify for client close_notify request. See the "Closure > >> Alerts" section for more details: > >> https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-6.1 > > > > In that section I read: > > "Each party MUST send a "close_notify" alert before closing its write > > side of the connection, unless it has already sent some error alert." > > > > Given that, I expect that for close_notify, at step #2, the client > > goes into NEED_UNWRAP, as the server MUST send a close_notify too. [...] > Per the TLS 1.3 specification, the local can request to close its > writing side, but it cannot to request to close the peer writing side. > It means it is not defined about how to close the read side. It could > lead to issues in practice. I had a question in the IETF TLS email > list. But unfortunately, I did not get a ideal solution: > https://www.ietf.org/mail-archive/web/tls/current/msg25581.html > > In order to countermeasure the issues, JDK will try to close the > underlying socket if either side sends the close_notify message.
Please forgive my interjection - does this not explicitly violate the half-close policy? The socket should not be closed until close_notify is both received (which means that read-shutdown is allowed) and sent (after which write-shutdown may be performed), should it not? > > At this point, my gut feeling is that having a single codebase > > handling TLS 1.2 and TLS 1.3 would be difficult. Is this feeling due to the half-closed situation? Because it's my firm belief that an TLS 1.2 implementation which treats half-closed in the manner specified by TLS 1.3 cannot be shown (from the perspective of an outside observer) to be in violation of the specification, and furthermore, _not_ doing so may represent a theoretical existent security risk. Put another way, imagine that my endpoint receives data and then sends data. Now imagine that the receive side immediately receives close_notify after its data is processed but before the send (response) begins. This obviously will terminate the connection before the data is output. Now imagine that the close_notify is completely contained in a single TCP packet, and that packet is (for whatever reason) delayed on the network until my send is complete. The OpenJDK TLS stack closes the socket at the right time (from my perspective), after both receive and send completed correctly. This delay has caused a material behavior change of my application, which is not a desirable effect. Two different behaviors, with the only input difference being one of timing. Imagine again now that the TLS 1.2 stack would not immediately send a close_notify, but instead would follow the half-close model as specified in TLS 1.3. As far as the *peer* is aware, my endpoint is conformant, because the peer cannot possibly differentiate between the TLS stack deferring shutdown to the application versus the close_notify message being delayed on the network. And, a bad actor can no longer affect the behavior of the application by delaying packets. These reasons were, without a doubt, considerations when the rules were changed for TLS 1.3. Also another important consideration was probably the observation that OpenSSL *already* appears to behave in this manner. OpenJDK's behavior has always IMO been clearly incorrect in this regard, despite the wording of the specification, and seeing this belief borne out by the changes in the TLS 1.3 spec is somewhat vindicating in this regard. But more importantly, I think this represents a chance to fix this long-standing bad behavior of the JDK. -- - DML
