JDK-8167680 : DTLS implementation bugs
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-10-13
  • Updated: 2021-03-15
  • Resolved: 2016-10-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b143Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
1. The sequence number is increased by 2 for GCM cipher suites.
Both GCM crypto operation and DTLS record use the sequence number.  The current implementation may increase the sequence number for each of the two operations.  It is not the expected behavior.

2. The implementation does not response to handshake retransmissions.
In the current implementation, receiving of retransmitted handshake messages does not kick off a retransmission of the previous delivered flight.  Retransmission happens on timeout.  Timeout is expensive.  Supporting response to peer retransmitted handshake messages would speed up the handshaking.

3. the final CCC and finished message cannot be retransmitted.
It is an implementation bug.  Every handshake message should be able to get retransmitted.

4. the first application data may be discarded if the last flight get lost. 
Applications may send application data immediately after the handshake completed.  However, the peer may have not receive the handshake complete message, and therefor discard the application data.  As may impact application logic.

For example

    Client                 Server
               ....          
       -- ClientKeyExchange -->
       -- ChangeCipherSpec  -->
       -- Finished          -->


       X <-- ChangeCipherSpec --
       X <-- Finished         --

       <-- Application Data  --

       -----    ...        --->
       -- ClientKeyExchange -->
       -- ChangeCipherSpec  -->
       -- Finished          -->

       <-- ChangeCipherSpec --
       <-- Finished         --


4-1. (omit the previous handshake messages) server sends ChangeCipherSpec and Finished messages.
4-2. server handshake complete
4-3. server send application
4-4. client does not receive the ChangeCipherSpec or Finished messages.
4-5. client receives the application data.  Client cannot handle the encrypted message, and may discard it.  Client re-transmit the previous flight.
4-6. server retransmit the last flight.
4-7. client receives the last flight.

In this update, the last flight will be transmit twice.  As may mitigate the impact of the issue.

5. resuming handshaking need no cookie exchange. 
It is an implementation bug.  Cookie exchange is performed for handshaking resuming now.  It is not the expected behavior.

6. need more debug log for DTLS handshake message fragmentation and reassembly.