Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22
Xue-Lei Fan
xuelei.fan at oracle.com
Tue Aug 14 00:14:48 UTC 2018
OK, I will check it. Thanks!
Xuelei
On 8/13/2018 3:15 PM, Bradford Wetmore wrote:
> 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
>>>>>>
More information about the security-dev
mailing list