Menu ▾ ▴

#13 Renegotiate CLIENT_HELLO is sent encrypted, when a previous session was successful established.

1.0
accepted
Olaf Bergmann
None
2015-05-26
2015-03-12
Achim Kraus
No

Use case:
- The client has established a DTLS session successfully.
- The server loses the DTLS session (e.g. reboot)
The client tries to „dtls_renegotiate“, but though having a peer with (previous) security parameters, the message is encrypted.
The server doesn’t have e session and therefore interprets the encrypted message as plain message, which may result in undefined behavior.

Discussion

  • Olaf Bergmann

    Olaf Bergmann - 2015-03-24
    • status: open --> accepted
    • assigned_to: Olaf Bergmann
     

  • Sachin

    Sachin - 2015-05-19

    In this scenario, 'Server' will be expecting a 'Client_Hello' packet and should send a 'DTLS_ALERT_HANDSHAKE_FAILURE' indicating that it received an 'unexpected packet'. Client will 'however' try to 'decrypt' this alert which is actually in clear-text and will therefore report as decrypt_fail error. But, it seems client will NOT disconnect the peer (due to RFC 6347 - 4.1.2.7) and this may be causing problems.

    Is that right?

    Sachin

     

  • Achim Kraus

    Achim Kraus - 2015-05-19

    I just saw an exception on the server processing the encrypted hello_client (scandium, but it's fixed now there).

     

  • Olaf Bergmann

    Olaf Bergmann - 2015-05-19

    Sachin, you are right. According to Section 4.2.7 of RFC 6347, the client should disconnect if it keeps getting Alert Messages from the server for the (encrypted) re-negotiate attempt and start with a brand new handshake.

     

  • Sachin

    Sachin - 2015-05-23

    Achim -- Can you point us to the location where this issue is Fixed?

     

  • Achim Kraus

    Achim Kraus - 2015-05-26

    Sorry, I don’t know the location in Scandium, where it was fixed. I just tested the compatibility and stability of a tinyDTLS client connecting to a Scandium server. At the time reporting the issue, I saw exceptions in Scandium. When I retested the issue a few days ago with an updated master branch (commit 11a2095) in Scandium, the exceptions are gone (even if the renegotiate still fails).
    Currently I simply reset the peer to stable reconnect, therefore I’m not affected by renegotiate because I don’t use it any longer. Therefore I also don’t know, if your description of the scenario above is right. I didn't analize the "renegotiate" in that depth.