Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22

[Bradford Wetmore]

No, I haven't had the time to determine when OK vs BU.

Brad


On 8/13/2018 2:32 PM, Xue-Lei Fan wrote:
> On 8/13/2018 2:12 PM, Bradford Wetmore wrote:
>> An update.
>>
>> 1.  OK vs. BUFFER_UNDERFLOW may still be an issue.  It's not a big 
>> one, but potentially confusing as to when you will get either.
>>
> Did you figure out when OK is returned, and when BUFFER_UNDERFLOW is 
> returned?  I think we have an improvement that if the buffer is not used 
> currently, the BUFFER_UNDERFLOW may not be returned.  So OK may be used 
> in some circumstances.
> 
> Xuelei
> 
>> 2.  I thought I saw this in the non-TLSv1.3 contexts also, but I think 
>> I must have been reverted my test case back to "TLS", which uses the 
>> TLS1.3 1/2 close.  I can't get it to duplicate in TLSv1.2/1.1/1 today. 
>> Never mind.
>>
>> Brad
>>
>>
>>
>> On 8/10/2018 6:14 PM, Bradford Wetmore wrote:
>>>
>>>
>>> On 8/9/2018 5:57 PM, Xuelei Fan wrote:
>>>> Thank you, Tim!   Please feel free to submit bugs and comments.
>>>
>>> I went through a standard SSLEngineTemplate handshake/data/close with 
>>> a fine-tooth comb (debugger), and found two bugs based on your -04 
>>> patch.
>>>
>>> 1.  Things may have changed since the original SSLEngine 
>>> implementation, but unwrap() was supposed to return a 
>>> BUFFER_UNDERFLOW if there is not enough (or any) inbound data to make 
>>> a packet.  I'm seeing a mix of OK and BUFFER_UNDERFLOW.  I haven't 
>>> determined the pattern, but you should be able to run my test 
>>> (attached) and see pretty quickly.
>>>
>>> 2.   I haven't not had the cycles to follow the earlier discussion, 
>>> so this may be a duplicate of something already discussed, but I got 
>>> myself into an endless loop because the closes weren't happening as 
>>> expected.
>>>
>>> In the attached file, after the handshaking and data exchange, close 
>>> just one of the SSLEngines outbound side.  I'll use client for this 
>>> example, but same error with server side:
>>>
>>> // clientEngine.closeOutbound();
>>> clientEngine.getHandshakeStatus() == NEED_WRAP
>>> client.isInboundDone(): false
>>> client.isOutboundDone(): false
>>>
>>> // client.wrap() sends the Close Notify (CN).
>>> client wrap: CLOSED/NEED_UNWRAP, 0/24 bytes
>>> clientEngine.getHandshakeStatus() == NEED_UNWRAP
>>> client.isInboundDone(): false
>>> client.isOutboundDone(): true
>>>
>>> // server.unwrap() parses the CN, and closes the inbound side.
>>> server unwrap: CLOSED/NEED_WRAP, 24/0 bytes
>>> clientEngine.getHandshakeStatus() == NEED_WRAP
>>> server.isInboundDone(): true
>>> server.isOutboundDone(): false
>>>
>>> So far so good.
>>>
>>> // server.wrap() needs to send the corresponding close_notify.
>>> server wrap: OK/NEED_WRAP, 0/0 bytes
>>> clientEngine.getHandshakeStatus() == NEED_WRAP
>>> server.isInboundDone(): true
>>> server.isOutboundDone(): false
>>>
>>> Whoops, it didn't happen.  No outbound data was generated.  State is 
>>> still in NEED_WRAP.  I just let the app run, it never closes because 
>>> no CN is generated on the server side.
>>>
>>> Run the attached file for full details.
>>>
>>> Thanks,
>>>
>>> Brad
>>>
>>>> Xuelei
>>>>
>>>> On 8/9/2018 4:23 PM, Tim Brooks wrote:
>>>>> Hi Xuelei,
>>>>>
>>>>> My test passed using that patch. I’ll continue to explore over the 
>>>>> next few days. But that patch resolves the main issues that I had 
>>>>> encountered.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> - Tim
>>>>>
>>>>>> On Aug 7, 2018, at 8:54 AM, Xuelei Fan <xuelei.fan at oracle.com 
>>>>>> <mailto:xuelei.fan at oracle.com>> wrote:
>>>>>>
>>>>>> Xuelei
>>>>>