Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8228370

DTLS handshaking fails when receives messages flight.

    Details

      Description

      A DESCRIPTION OF THE PROBLEM :
      Background

      DTLS_Client is written in Java with jdk11 build 11+28 and using the classes of javax.net.ssl package.
      DTLS_Server is written in C language using Openssl library 1.0.2q and it implements only DTLS v1.0 protocol [RFC4347]

      In attach there is the handshake session between DTLS_Client and DTLS_Server (see picture JDK_11_DTLS_Client_handshake.png)



      Description
      When DTLS_Client, during the handshake, receives from DTLS_Server the message flight #4 (see raw 4 in the picture JDK_11_DTLS_Client_handshake),
      it doesn't send the message flight #5:
      Certificate
      ClientKeyExchange
      CertificateVerify
      ChangeCipherSpec
      Finished
        
      After 1 sec (see raw 5 in the picture) the DTLS_Server, as described in the RFC, retransmits the
      messages of flight #4 separately/one by one (see raws 5-8 in the picture) the messages, in this case
      the DTLS_Client sends the messages of flight #5 separately/one by one (see raws 9-13 in the picture JDK_11_DTLS_Client_handshake) to DTLS server.

      My question is:
      when DTLS_Server receives the packet with the message flight #4 from socket,
      is it correct to pass the complete packet (flight #4 with all messages inside) to the
      SSLEngine for the unwrap (engine.unwrap(iNet,iApp) method) ?
      Or should it be splitted in 4 packets before passing them to the SSLEngine
      for the unwrap (engine.unwrap(iNet,iApp) method) ?
      So, is the handling of the fligth messages demanded to the application or is there any setting to
      instruct the SSLEngine to handle them ?
       
        
      We have also performed another test replacing the DTLS_Client, above mentioned, with Openssl test
      client (openssl s_client) (see picture DTLS_server_tested_with_openssl_s_client.png)
      and in this case the handshake is succesfully completed.



      FREQUENCY : always


        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              webbuggrp Webbug Group
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: