DTLS EXCEPTION "Handshake timed out" vs "DTLS Handshake has failed"

[Ifilehk]

Back again :-)

Facing 2 situations where the exception should be the same for both, but is not:

• Situation 1 Identity is wrong, PSK is correct results is DtlsHandshakeException: DTLS Handshake has failed what is fine
• Situation 2 Identity is correct, PSK is wrong results is DtlsTimeoutException after 0:00:10.000000: Handshake timed out what is not OK. Should be exception as in 1

Actually the exception should be DtlsHandshakeException: Wrong identity and PSK

Easy to fix ?

[JKRhb]

Welcome back ;)

Hmm, what happens in situation 2 though if you don't pass a timeout argument to the client?

[Ifilehk]

If the pair Identity / PSK is wrong, client should stop trying if he is nice, or brute force if he is bad :-(

I don't now the details of the handshake but in situation 1 the server seems to reply. In the second one the server does not and a client timeout occurs. Right ?

[JKRhb]

I don't now the details of the handshake but in situation 1 the server seems to reply. In the second one the server does not and a client timeout occurs. Right ?

Yeah, I think that is the case here :/ I need to double-check that as well, but I think the server does not respond in that situation for security reasons. Do you see any server response when using Wireshark, for example?

[JKRhb]

See here: https://github.com/openssl/openssl/issues/18738 This seems to be the intended behavior and using a timeout seems to be the only way to deal with that :/

[JKRhb]

However, I guess we could let DtlsTimeoutException inherit from DtlsHandshakeException so that you can catch both cases at the same time? This would probably also make sense since the handshake is the only situation where a timeout can occur.

[Ifilehk]

Never dug so deep :-) but trying ...

[Ifilehk]

Actually I am comparing dtls2 client with the behavior of openssl s_client and it is consistent:

Situation 1: Identity wrong, PSK correct

CONNECTED(00000003)
Can't use SSL_get_servername
404712F1467F0000:error:0A00045B:SSL routines:dtls1_read_bytes:reason(1115):../ssl/record/rec_layer_d1.c:613:SSL alert number 115
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 231 bytes and written 549 bytes
Verification: OK
---
New, TLSv1.2, Cipher is PSK-AES128-CCM8
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : DTLSv1.2
    Cipher    : PSK-AES128-CCM8
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: A565261E4F62774F005B234CE7DB022756B44661B6CF89A4F398B164EBF32BAAC41AFD7518237E050067E8C6260F1855
    PSK identity: X2KT
    PSK identity hint: This is the identity hint!
    SRP username: None
    Start Time: 1689165562
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---
and returns to console prompt

Situation 2: Identity correct, PSK wrong

CONNECTED(00000003)
Can't use SSL_get_servername
and does not return to console prompt

So just in this case a timeout is thrown otherwise the client will be stuck there.

I think it is OK, because when a client is revocated on my server both Identity and PSK are dropped. So the Situation 2 should only happen when someone would abuse the server with the right Identity and a wrong PSK. And for security reasons a long timeout make sense too.

At the end a DtlsTimeoutException or DtlsHandshakeException means the same for me:. The pair Identity / PSK is not correct and client should be redirected to signup page.

Or did I miss something ?

[Ifilehk]

OK so far so good, but coming back with a new point here.

Actually what disturbs me is the fact that a DtlsTimeoutException after 0:00:10.000000: Handshake timed out is thrown client side when the server is not connected an as far as I can see a TimeoutException is not implemented in dtls2.

Going back to the openssl behavior in this case. If server is disconnected (offline):

CONNECTED(00000003)
write:errno=111
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 129 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : DTLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1689173023
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---
and back to command prompt

I think I got my missing point now. Is it possible to implement ConnectionRefusedException catching this write:error=111 ?

[JKRhb]

I think I got my missing point now. Is it possible to implement ConnectionRefusedException catching this write:error=111 ?

Sure, that sounds good. Could you post the openssl command you used to generate the output, though? That would make it a bit easier to replicate, I guess.

[Ifilehk]

Actually, here it should be also SocketException Connection refused to copy the behavior of openssl s_client -dtls that returns err:111

The command to run is: openssl s_client -dtls -psk _identity "identity" -psk "presharedkey" - cipher "..." -connect <server-ip>:<port>

against a server that is down. This makes also sense. It is a socket problem, not a dtls.

On Jul 16, 2023, 13:28, at 13:28, Jan Romann @.***> wrote:

I think I got my missing point now. Is it possible to implement ConnectionRefusedException catching this write:error=111 ?

Sure, that sounds good. Could you post the openssl command you used to generate the output, though? That would make it a bit easier to replicate, I guess.

-- Reply to this email directly or view it on GitHub: https://github.com/JKRhb/dtls2/issues/87#issuecomment-1637071820 You are receiving this because you authored the thread.

Message ID: @.***>

[Ifilehk]

Any news at this front ?

[JKRhb]

Hi @Ifilehk, sorry for not getting back to you earlier :/ I will try to continue working on this issue and the others later this week, if you should find a potential fix in the code in the meantime, feel free to open a Pull Request by the way :)