SSLEngine weird behavior in 11+21?

[David Lloyd]

On Thu, Jul 12, 2018 at 2:30 PM Xuelei Fan <xuelei.fan at 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.fan at 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