SSLEngine weird behavior in 11+21?

[Xuelei Fan]

Hi Simone,

Thank for reporting this issue.

To speed up the evaluation, would you mind send us the debug log (using 
system property "javax.net.debug=all")?

Thanks,
Xuelei

On 7/11/2018 3:06 PM, Simone Bordet wrote:
> Hi,
> 
> I can see this (weird) behavior in SSLEngine for TLS 1.3 in JDK 11+21.
> It's a simple new connection (no resumption) that performs a TLS 1.3 handshake.
> The bytes numbers are those that I get, they may be different for
> others depending on certificate size, etc.
> 
> 1. Client wraps 394 bytes then goes into NEED_UNWRAP.
> 2. Server unwraps 394 bytes then goes into NEED_TASK and then into NEED_WRAP.
> 3. Server wraps (in 3 wraps) 160, 6 and 907 bytes then goes into NEED_UNWRAP.
> 4. Client unwraps 160 bytes then goes into NEED_TASK and then into NEED_WRAP (?)
> 5. Client wraps 6 bytes, then goes into NEED_UNWRAP.
> 6. Client unwraps (in 2 unwraps) 6 and 907 bytes, then goes into
> NEED_TASK and then into NEED_WRAP.
> 7. Client wraps 58 bytes and goes into FINISHED (?)
> 8. Server unwraps (in 2 unwraps) 6 and 58 bytes then goes into NEED_WRAP.
> 9. Server wraps 72 bytes then goes into FINISHED.
> 10. Client MUST unwrap those 72 bytes going again into FINISHED (which
> already happened at 7).
> 
> There are 2 things that I find weird:
> 
> A) That at 4, the client goes into NEED_WRAP, even if it has not
> finished to unwrap what the server sent. Apparently, it only goes into
> NEED_WRAP to generate a CHANGE_CIPHER_SPEC (I am guessing from the
> number of bytes generated), but then goes back into NEED_UNWRAP to
> finish reading what the server sent. This is also not optimal as it
> forces applications to do something with those 6 bytes: either put
> them aside (additional data structures that may not be needed) or -
> worse - write them to the server causing an additional write (after
> all the effort TLS 1.3 put in to have a 1 RTT handshake).
> I think that step 4 should go into NEED_UNWRAP, and that step 5 and
> step 6 should be switched, so that the client would unwrap the 160, 6
> and 907 sent by the server, and only after wrapping the 6 and the 58.
> To be clear, the current behavior is (u==unwrap, w=wrap): u160, w6,
> u6, u907, w58.
> I think it should be: u160, u6, u907, w6, w58.
> 
> Is there any reason that the 6 bytes needs to be generated in-between
> the processing of the frames sent by the server?
> 
> B)That at 7 the client goes into FINISHED, but it is not finished
> really: in fact it needs to perform step 10, but there is no
> indication from the SSLEngine that it must do so.
> Currently, step 7 says the client is finished and there is no clue
> that it must unwrap those last 72 bytes.
> I think step 7 should go into NEED_UNWRAP instead, and only at 10 go
> into FINISHED.
> 
> Thanks!
>