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
