DTLS Full Handshake failure #964
Comments
If we look at client side :C1) C2) C3) Then try to establish a new DTLS connection. C4) without success because receiving a FATAL ALERT C5) server initiate an handshake and this generate an NPE : About C1) If we look at server side :S1) Try to send a request to a client but it has no connection ... About S1) I can not explain why connection is lost. So many missing puzzle piece to understand what happened. |
Those client log customized authorizer in server builder.setAuthorizer(new Authorizer() {
@Override
public Registration isAuthorized(UplinkRequest<?> uplinkRequest, Registration registration,
Identity identity) {
if (identity.isSecure() && identity.isX509()) {
LOG.info("Accepted registration from endpoint {} at {}", registration.getEndpoint(), identity.getPeerAddress().toString());
return registration;
} else {
LOG.info("Declined registration from endpoint {} at {}", registration.getEndpoint(), identity.getPeerAddress().toString());
return null;
}
}
});
Not much information from the INFO log can explain C4). I developed another tiny program to poll for the device shadow data from HTTP API endpoints exposed in leshan-server-demo periodically. Would this trigger a HandshakeException if the connection is lost? BTW, will enable DEBUG log in server to capture more useful information.
There should be no network disconnection at that moment. Can the client log above prove this?
|
|
If you are behind a NAT this could explain C1) About C5 this is a bug, I will fix it in |
|
@sbernard31 Attached please find the log files for your investigation. Is it likely the fix for C5 in server side can make client and server reconnect again without server restart? 🙇 |
|
This logs at server side could explain C4) But I can not understand how its possible. Now a wireshark capture could help to understand.
This is OK for a demo, but for production this NOT SAFE AT ALL because if you get credential of 1 device using x509, you can usurp identity all others devices which also use x509.
It could but not sure. In all case we need to fix/understand the C4 issue too. |
|
I pushed a fix for C5 in 1.x : 36f5756 |
@francopo did you modify cipher suite to use ? |
|
'''
No. Keep using recommended cipher suites. |
Regarding to the reconnection problem, client was scheduled to update registration but it received 'fatal alert/HANDSHAKE_FAILURE' from server. Server aborted the DTLS handshake because client proposed unsupported cipher suites only. It's a bit weird here. |
I agree that's why I would like to see a wireshark capture. To be able to check the DTLS handshake. I tried to reproduce this on my side without success all if OK for me. @boaks did you already face something like this ? |
|
That issue is somehow confusing, I'm not sure, if I understand it. The first comment contains a "client.log" which has a The last comment:
The current Californium master (3.0.0-SNAPSHOT) contains already:
It's not only the cipher suite, it's also the other parameters. As @sbernard31 already wrote, wireshark captuers helps here a lot. (See Logs and IP-Capturing ) |
That seems to be caused by returning |
@boaks this is already fixed. see #964 (comment)
I'm not sure to get your point, is it related to the fixed issue above ☝️ ?
#964 (comment) is a description of my understanding. Currently, we try to understand the issue before the role exchange. Issue related to |
|
I didn't read the whole thread too carefully ... I just jumped to the first and the last. Which detail caused the handshake in the last example fails, is for me unclear and requires either a ip-capture or extended logging messages. |
|
I did some test on my side and I not able to reproduce :/ |
|
No, I wasn't faced by such issues. It depends heavily on the exact dtls-configuration, so I'm not sure, what caused it. For the future, I add a detailed logging for the client and server hello in that case (for Californium 3.0). |
@sbernard31, 36f575 can fix the NPE. 👏 Please download issue-964-20210131.zip, which contains client (unmodified version) TRACE log and wireshark capture for these 2 handshake events.
Please check if the information inside can help. |
|
I checked the wireshark captures, and I can see a difference in the client_hello's. What makes me (just) wonder, are the used x509 certificates. They look strange to me. My "wild guess", your x509 do not only looks strange, it may make the lwm2m-server also behave strange. But, that's just a wild guess, |
|
If you want, you may also add your own logging lines in to see more details about the negotiation. |
|
Not strictly related to this issue: |
|
DefaultCipherSuiteSelector.checkCertificateSupport stacks on I prepare a fix. @sbernard31 |
|
See Californium, PR 1528, Move certificate supported check to local field. If possible, please cherry-pick it and test it, if it fixes this issue. |
It sounds good. I will also probably release a 1.3.1 with it and the Leshan fixed above. |
@boaks , it works. No more |
|
Great! Thank you also for reporting that nasty bug! |
sbernard31
added
bug
|
@francopo thx you for taking time to reporting this and help us to fix it. 🙏 ! |
|
The NPE fix and integration of californium 2.6.1 (which fix the bug above) are now available in |
I'm testing client/server DTLS communication with leshan-server-demo and leshan-client-demo v1.3.0 (californium 2.6.0). Leshan client fails to keep connecting with Leshan server after a period of time due to an error of DTLS Full Handshake initiated by client : FAILED (Received 'fatal alert/HANDSHAKE_FAILURE'). Leshan server restart is required to allow the client to connect again. Please advise on how to solve this issue.
client log
server log
The text was updated successfully, but these errors were encountered: