SSLEngine weird behavior in 11+21?

[Xuelei Fan]

I filed a bug for this improvement.
    https://bugs.openjdk.java.net/browse/JDK-8209840

We may fix it in a near release.

Thanks,
Xuelei

On 8/22/2018 3:29 AM, Simone Bordet wrote:
> Hi,
> 
>>> On 7/12/2018 1:17 PM, Simone Bordet wrote:
>>> Currently:
>>> - Server wraps 160, 6 and 907 in 3 wraps.
>>> - Server *sends* the 1073 bytes in 1 TCP write
>>> - Client unwraps 160, then goes into NEED_WRAP
>>> - Client wraps 6, then goes again into NEED_UNWRAP to finish with the
>>> 6 and 907 received by the server.
>>>
>>> What I'm suggesting:
>>> - Server wraps 160, 6 and 907 in 3 wraps.
>>> - Server *sends* the 1073 (160+6+907) bytes in 1 TCP write
>>> - Client unwraps 160, stays in NEED_UNWRAP, unwraps the 6, unwraps the
>>> 907, then goes into NEED_WRAP
>>> - Client wraps 6 and 58
>>> - Client *sends* the 64 (6+58) bytes in 1 TCP write.
>>>
>>> The 6 bytes of the dummy change_cipher_spec are *sent* just after
>>> receiving the ServerHello in both cases, they are just *generated* at
>>> different times.
>>>
>>> By having all the unwraps() consecutive and all the wraps()
>>> consecutive you can enable a number of optimizations I described
>>> earlier.
>>>
>>> Imagine a client that would perform a TCP *send* every time the state
>>> moves away from NEED_WRAP.
>>> Currently it would:
>>> 1. TCP send for ClientHello
>>> 2. Reads 1073 from server
>>> 3. Unwrap 160, then NEED_WRAP
>>> 4. Generate 6, then NEED_UNWRAP
>>> 5. TCP send the 6 bytes
>>> 6. Unwrap 6 and 907, then NEED_WRAP
>>> 7. Generate 58 then FINISHED
>>> 8 TCP send the 58 bytes.
>>>
>>> You can see that the client issues 3 TCP sends.
>>>
>>> With what I am suggesting, the client would only issue 2 TCP sends,
>>> which seems more in line with the efforts in TLS 1.3 to be more
>>> efficient.
>>>
>>> It would just be a matter of *generating* those 6 bytes a bit later,
>>> *after* having fully unwrapped the ServerHello.
>>>
>> On Fri, Jul 13, 2018 at 3:45 PM Xuelei Fan <xuelei.fan at oracle.com> wrote:
>> It's a good idea!
> 
> I just built:
> 
> $ hg id -i
> 76072a077ee1
> 
> and I can still see the (very) inefficient behavior above.
> Are there plans to fix it?
> 
> Thanks!
>