2

I have an IOT device that communicates with DTLS 1.2 protocol. We've already integrated WolfSSL into our project and it's working fine. What I want to achieve is to set only a specific cipher suite to my WolfSSL client so that I will make sure it's using the correct encryption method.

const char *CIPHER_LIST = "PSK-AES128-CCM-8";
WOLFSSL_CTX *ctx = wolfSSL_CTX_new(wolfDTLSv1_2_client_method());
wolfSSL_CTX_set_cipher_list(ctx, CIPHER_LIST);

WOLFSSL *ssl = wolfSSL_new(ctx)
wolfSSL_set_cipher_list(ssl, CIPHER_LIST);

When I print the cipher list;

for (int i = 0; i< 50; i++) {
    // print cipher list based on priority
    NSLog(@"->%s", wolfSSL_get_cipher_list(i));
}

The result will be

DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-PSK-AES256-GCM-SHA384
DHE-PSK-AES128-GCM-SHA256
PSK-AES256-GCM-SHA384
PSK-AES128-GCM-SHA256
DHE-PSK-AES256-CBC-SHA384
DHE-PSK-AES128-CBC-SHA256
PSK-AES256-CBC-SHA384
PSK-AES128-CBC-SHA256
PSK-AES128-CBC-SHA
PSK-AES256-CBC-SHA
DHE-PSK-AES128-CCM
DHE-PSK-AES256-CCM
PSK-AES128-CCM
PSK-AES256-CCM
PSK-AES128-CCM-8
PSK-AES256-CCM-8
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
EDH-RSA-DES-CBC3-SHA

If I call wolfSSL_get_cipher(ssl) I got result "NONE".

The library was working fine until our IOT device's firmware was updated, then we started to get no responses from it. After I backtracked the response failures I realised that it's an SSL handshake problem and I decided to set a cipher list. I'm wondering, is there anything that I'm missing or doing wrong?

Moreover, we have also an Android application that communicates with the same device using "PSK-AES128-CCM-8" encryption method. That's why I want to set my list only this specific method.

Additionally, this is the user_settings.h for WolfSSL;

/* Configuration */
#define IPHONE  /* Needed for Xcode */
#define DEBUG_WOLFSSL

#define HAVE_HASHDRBG
#define HAVE_AESGCM
#define HAVE_AESCCM

#define WOLFSSL_SHA512
#define WOLFSSL_SHA384
#define WOLFSSL_STATIC_PSK
#define WOLFSSL_DTLS

#define NO_WOLFSSL_SERVER

#ifdef HAVE_FIPS
#define NO_MD4
#define NO_HC128
#define NO_RABBIT
#define NO_DSA
#define NO_PWDBASED
#else
#define USE_FAST_MATH
#endif
efdalustaoglu
  • 168
  • 11
  • You are doing it correctly. If you can capture a wireshark trace of the connection you should see the Client Hello packet containing on a single cipher suite. – Kaleb May 09 '19 at 16:43
  • I tried to clarify below about the API's you are using and why they aren't quite doing what you thought they should, one just lists all available for you to see what's configured and the other is for post-handshake. There isn't an option to check (at this time) after calling wolfSSL_CTX_set_cipher_list but I've made a note of it as a "nice to have feature". If we have some free time we'll look into adding an API for that. – Kaleb May 09 '19 at 17:04

1 Answers1

1

@efdalustaoglu,

I am sorry to hear that a device Firmware update has resulted in this failure. Let me see if I can address the unknown or unexpected items satisfactorily and then suggest an approach that will help in resolving this more quickly:

1)

When I print the cipher list;

for (int i = 0; i< 50; i++) {
    // print cipher list based on priority
    NSLog(@"->%s", wolfSSL_get_cipher_list(i));
}

...

The function wolfSSL_get_cipher_list gets a list of all available ciphers, it does not return only the one(s) that are specifically set, this is why you see the entire list printed out.

2)

If I call wolfSSL_get_cipher(ssl) I got result "NONE".

This will return the cipher suite that was selected during the handshake. If you call this after a successful handshake (IE: ret = wolfSSL_connect(ssl); where ret is WOLFSSL_SUCCESS) you will see which cipher suite was negotiated during the handshake.

3) Lastly you are not doing anything wrong from what I can see, in fact this is a good first step towards getting a reproducible setup that fails in an expected way. (IE limiting to only one cipher suite).


Steps that can help quickly resolve:

1) Debug:

Can you share the error codes (if any) that you are seeing? I see you have already added DEBUG_WOLFSSL to your settings, you can call wolfSSL_Debugging_ON(); in your application to produce a debug log now. Can you share that for review?

2) Wireshark:

Capturing a failed connection can often provide very helpful clues as to the cause of the failure. Seeing at which point in the handshake it fails is also highly advantageous in diagnosing the cause.

Moreover, we have also an Android application that communicates with the same device using "PSK-AES128-CCM-8" encryption method. That's why I want to set my list only this specific method.

That is excellent! If you can capture a successful connection from the android device and compare that capture to the failed connection we can compare what the differences are in the Client Hello and Server Response packets.

3) As a last resort if you can not quickly narrow this down you can always reach out to our wolfSSL support team through the official support channel by sending an email to [support (at) wolfssl (dot) com] or by visiting our zendesk portal at [wolfssl (dot) zendesk (dot) com]. Our team is always happy to help in any way we can.

Kaleb
  • 591
  • 4
  • 17