Hi, On Tue, Jul 31, 2018 at 3:43 PM Xuelei Fan <xuelei....@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
