SSL Handshake Failure while connecting to bootstrap

[qasim-ublox]

Hi, I got a problem while my device tries to connect to the bootstrap. I am using my device as LWM2M client and X509 security. In the server Logs, at the end of FINISHED the DTLS connector discards the handshake. I am attaching the server logs and wireshark packets. Please have a look and tell me if you can suggest any solution.

2019-10-08 12:11:10,378 DEBUG Handshaker - Processing FINISHED (20) message from peer [/10.17.4.170:53770], seqn: [5] 2019-10-08 12:11:10,379 DEBUG DTLSSession - Setting maximum fragment length for peer [/10.17.4.170:53770] to 1395 bytes 2019-10-08 12:11:10,381 DEBUG DTLSConnector - Sending flight of 2 message(s) to peer [/10.17.4.170:53770] using 1 datagram(s) of max. 1500 bytes 2019-10-08 12:11:10,382 DEBUG Connection$ConnectionSessionListener - Session with [/10.17.4.170:53770] has been established 2019-10-08 12:11:10,383 DEBUG Handshaker - Processed FINISHED (20) message from peer [/10.17.4.170:53770] 2019-10-08 12:11:10,384 DEBUG DTLSSession - Updated receive window with sequence number [0]: new upper boundary [0], new bit vector [1] 2019-10-08 12:11:10,386 DEBUG DTLSConnector - Discarding Handshake (22) record received from peer [/10.17.4.170:53770] without an active session for epoch 0 2019-10-08 12:11:10,387 DEBUG DTLSConnector - Discarding Handshake (22) record received from peer [/10.17.4.170:53770] without an active session for epoch 0 2019-10-08 12:11:10,389 DEBUG DTLSConnector - Discarding Handshake (22) record received from peer [/10.17.4.170:53770] without an active session for epoch 0 2019-10-08 12:11:10,391 DEBUG DTLSConnector - Discarding Change Cipher Spec (20) record received from peer [/10.17.4.170:53770] without an active session for epoch 0 2019-10-08 12:11:10,393 DEBUG Record - Parsing HANDSHAKE message plaintext with parameter [KeyExgAl=EC_DIFFIE_HELLMAN, cert.type=X_509] 2019-10-08 12:11:10,394 DEBUG DTLSConnector - Received Handshake (22) record from peer [/10.17.4.170:53770] 2019-10-08 12:11:10,395 INFO Handshaker - Discarding Handshake (22) message received from peer [/10.17.4.170:53770] before last flight was sent:

server_log.txt if you need to see detailed logs.. wiresharkPackets_Detailed.txt

[sbernard31]

Which version of Leshan are you using ? You are using Leshan at server side, right ? which implementation is used at client side ? Could you provide the wireshark capture instead of .txt ?

Regarding the capture screenshot & logs, I see :

1. the double SERVER_HELLO, ..., SERVER HELLO DONE which seems to be normal as client does not answer quickly enougth.
2. Client sends 2 CERTIFICATE, ..., ENCRYPTED HANDSHAKE MESSAGE, this is not really optimal as client should not send it twice but this should not be an issue. (see for mbed : https://github.com/ARMmbed/mbedtls/issues/2825)
3. Then after the handshake which seems successful at least at server side (regarding the log), the client send an encrypted hanshake message. I can not understand why, server seems to discard it as there is not ongoing handshake so this makes sense to me.
4. Regarding capture sever sends an alert, but I can not see that in the log (I do not understand why ?) ...

This could help to know what is this ENCRYPTED HANDSHAKE MESSAGE and what is this ENCRYPTED ALERT.
Do you have log at client side which contains this information ? or you can configure wireshark to decrypt traffic (I never do that witch something else than PSK, here you probably need to get (pre)-master key which will not be so easy).

[qasim-ublox]

Could you provide the wireshark capture instead of .txt ?

WiresharkLogs.zip

[bqam-ublox]

• We are using the bootstrap and LwM2M server demo available on github.
• At client side we are using the mbed-pelion client in this example and modifying it to work with Leshan server.
• Please have a look at the client log - attached client_logs.txt
• We have deployed the bss demo server and lwm2m demo server locally on our network but the client log is same even if we connect with the leshan sandbox server

[sbernard31]

Reading at the Scandium code (leshan side)

private void processHandshakeRecord(final Record record, final Connection connection) {
    LOGGER.debug("Received {} record from peer [{}]", record.getType(), record.getPeerAddress());
    try {
        if (record.isNewClientHello()) {
            throw new IllegalArgumentException("new CLIENT_HELLO must be processed by processClientHello!");
        }
        HandshakeMessage handshakeMessage = (HandshakeMessage) record.getFragment();
        switch (handshakeMessage.getMessageType()) {
        case CLIENT_HELLO:
            // We do not support re-negotiation as recommended in :
            // https://tools.ietf.org/html/rfc7925#section-17
            if (record.getEpoch() > 0) {
                DTLSSession session = connection.getEstablishedSession();
                send(new AlertMessage(AlertLevel.WARNING, AlertDescription.NO_RENEGOTIATION, record.getPeerAddress()),
                        session);
            }

and looking at device (mbed) log :

[DBG ][mClt]: M2MConnectionSecurityPimpl::connect
[DBG ][mClt]: M2MConnectionSecurityPimpl::start_handshake
[DBG ][PAL ]: SSL EXPIRED OR FUTURE - retry
[DBG ][PAL ]: SSL START RENEGOTIATE

I would guess that client tries to renegotiate just after succeed the handshake ... which sounds not good. (it's just a guess, to be sure we need to know what is this ENCRYPTED HANDSHAKE MESSAGE and ENCRYPTED ALERT, but there is no log we could activate to see that in scandium).

[sbernard31]

I just integrated the last version of californium (2.0.0-M18) in master and now there is a log about renegociation.

So you should see if your device tries to renegotiate which is not recommended and so not supported by Leshan/Scandium.

[sbernard31]

Could we close this issue ?

[qasim-ublox]

Closing

[nkaramolegos]

So @qasim-ublox do you find what is the problem? I have the same problem using contiki-ng and leshan-server-demo