Code Review Request, JDK-8209333 Socket reset issue for TLS 1.3 socket close

[Jamil Nimeh]

Hi Xuelei, just a couple questions:

  * SSLSocketImpl
      o 611: Are you sure conContext.inputRecord should go into a
        try-with-resources?  As far as I can tell, the inheritence chain
        is SSLSocketInputRecord->InputRecord and that directly or by
        extension implements the SSLRecord, Record and Closeable
        interfaces.  I thought that you needed to implement
        AutoCloseable in order to get that automatic closure benefit
        from leaving the try block.  Am I missing something?
  * SSLContextTemplate
      o 505: Is there any benefit to initializing the SSLContext using a
        PKIXParameters object with the date fixed to sometime in between
        2018 and 2028 (the soonest expiration date of all the certs in
        the test).  This way you'd never have to worry about things
        expiring.  I know we don't do this in most of our tests, dunno
        why it just occurred to me now.

The rest looks OK to me.

--Jamil

On 12/17/2018 9:52 AM, Xue-Lei Fan wrote:
> ping ...
>
> On 12/10/2018 1:14 PM, Xue-Lei Fan wrote:
>> Hi,
>>
>> Please review the TLS 1.3 half-close issue in JDK.
>>
>>      http://cr.openjdk.java.net/~xuelei/8209333/webrev.00/
>>
>> While trying to duplex close a TLS connection upon the half-close 
>> policy, there might be pending receiving data in the closing side, 
>> and result in a TCP RST during closing.  The TCP RST may then cause 
>> the peer reading failure.  For example:
>> 1. client and server establish a TLS 1.3 connection.
>> 2. server sending the post-handshake NewSessionTicket message.
>> 3. client send the application data, and then close the connection.
>> 4. as the client does not call to read the post-handshake message, 
>> the connection close will cause a TCP RST.
>> 5. server trying to read the client application data, but the socket 
>> may be impacted by the TCP RST, and the reading can fail.
>>
>> It would not be an issue any more if the client could read the 
>> post-handshake message, explicit or implicit.
>>
>> I would like applications consider to use half-close policy, and 
>> moving away from the duplex-close policy.
>>
>> The basic idea of the fix is trying to use up buffered network input 
>> before close the socket.  As is an implicit behavior to consume the 
>> post-handshake message, and mitigate the impact of it.
>>
>> This fix is not a perfect one.  It is just a workaround for 
>> duplex-close.  I'm open to hear more ideas.
>>
>> Thanks,
>> Xuelei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20181217/a391ef98/attachment.htm>