On 7/12/2018 7:33 AM, Xuelei Fan wrote:
In addition to what reported above, I would like to report also the
weird behavior during the close handshake (i.e. when one side decides
to close the connection).

1. client.closeOutbound() then goes into NEED_WRAP.
2. Client wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING (?)
3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP.
4. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING.
5. Client unwraps 0 bytes (?)

I think at step 2 the client should go into NEED_UNWRAP to read (at
step 5) the server response to the close_notify.
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

It is a little bit complicated when moving from the duplex-close to half-close policy.  In order to mitigate the compatibility impact, in JDK implementation, if the local send the close_notify, we choose to close the underlying socket as well if needed.  But, if the peer send the close_notify, the unwrap() should be able to consume the bytes.  It looks like a implementation bug to me.
The issue is tracked in JBS:
   https://bugs.openjdk.java.net/browse/JDK-8207177

Xuelei

Reply via email to