SSLEngine weird behavior in 11+21?

Simone Bordet simone.bordet at gmail.com
Tue Jul 31 14:20:10 UTC 2018


Hi,

On Tue, Jul 31, 2018 at 3:43 PM Xuelei Fan <xuelei.fan at oracle.com> wrote:
> > 1. client.closeOutbound() then goes into NEED_WRAP.
> > 2. Client wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING.
> It might be a problem for application to make a right decision if using
> CLOSED status and NOT_HANDSHAKING handshake status together.
>
> As the write side is close, the client now only be able to receiving
> data from peer.  I think NEED_UNWRAP may be more appropriate for
> application development.

I think the key point here is that SSLEngine tells the application
what needs to be done.
Because you implemented half-close, NEED_UNWRAP is not _strictly_ needed here.
By staying in NOT_HANDSHAKING the normal flow will happen: data to
read from the server, pass to unwrap(), it may be data or
close_notify.
Let's imagine it is data; after unwrapping data, do you stay in
NEED_UNWRAP until the close_notify arrives?

I'm fine with either NOT_HANSHAKING or NEED_UNWRAP, but I prefer
NOT_HANDSHAKING.

> However, the CLOSED status may be confusing as the client may still want
> to read something later.
>
> I may prefer to use OK/NEED_UNWRAP.  What do you think?

I prefer CLOSED/NOT_HANDSHAKING, but OK/NEED_UNWRAP works too.

> > 3. Server unwraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING.
> Same reason as above, I may prefer to use OK/NEED_WRAP.

Here I strongly disagree.
It is fundamental for the application to know that it received the
close_notify from the client, because the application needs to call
closeOutbound(), eventually.
The CLOSED result is the only thing that tells the application to call
closeOutbound().
I think this is also good for backwards compatibility: with TLS 1.2 I
bet most application were relying on the CLOSED state.

I prefer CLOSED/NOT_HANDSHAKING; CLOSED/NEED_WRAP is ok too.

> > 4. server.closeOutbound() then goes into NEED_WRAP.
> > 5. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING.
> > 6. Client unwraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING.
> >
> Agreed.
>
> If no objections, I will make the update:
>
> 1. client.closeOutbound() then goes into NEED_WRAP.
> 2. Client wraps 24 bytes, result is OK, then goes into NEED_UNWRAP.
> 3. Server unwraps 24 bytes, result is OK, then goes into NEED_WRAP.

Nope: CLOSED, then NEED_WRAP, see above.

> 4. server.closeOutbound() then goes into NEED_WRAP.
> 5. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING.
> 6. Client unwraps 24 bytes, result is CLOSED, then goes into
> NOT_HANDSHAKING.

Let's make another case with data, and what I prefer:

1. client.closeOutbound() then goes into NEED_WRAP.
2. Client wraps 24 bytes, result is OK, then goes into NOT_HANDSHAKING.
3. Server unwraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING.
4. Server wraps data bytes, result is OK, stays in NOT_HANDSHAKING.
5. Client unwraps data bytes result is OK, stays in NOT_HANDSHAKING.
6. server.closeOutbound() then goes into NEED_WRAP.
7. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING.
8. Client unwraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING.

I'm fine for 2 and 5 to be NEED_UNWRAP; I'm fine for 3 and 4 to be NEED_WRAP.

Thanks!

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz


More information about the security-dev mailing list