mbedTLS + NUCLEO-F401RE + SIM800

Well the whole ssl_tls.c source is different. For your reference, ssl_tls.c from github is 9292 sloc, while STM32CubeMX generates 8395 sloc.

Hello,

Regarding debug, the issue I faced had something to do with printing the base name, either a character in the full path or the path size had the micro hang, so I changed this:

static void my_debug( void *ctx, int level,
                      const char *file, int line,
                      const char *str ){
    const char *p, *basename;
    /* Extract basename from file */
    for( p = basename = file; *p != '\0'; p++ )
        if( *p == '/' || *p == '\\' )
            basename = p + 1;
    mbedtls_fprintf( (FILE *) ctx, "%s:%04d: |%d| %s",
                     basename, line, level, str );
    fflush(  (FILE *) ctx  );
}

to this:

static void my_debug( void *ctx, int level,
                      const char *file, int line,
                      const char *str )
{
    (void)ctx;
    const char *p;
    char bufz[512];
    sprintf(bufz, " |%d| %s\r", level, str);
    HAL_UART_Transmit(&huart2, bufz, strlen(bufz), 10);
}

where HAL_UART_Transmit is my platform-specific print and it works OK.
Now on the actual functionality I am working on parsing the server certificate, after Server Hello
On my windows host:

(null):4047: |4| 0000:  16 03 03 0a 1b                                   .....
(null):4056: |3| input record: msgtype = 22, version = [3:3], msglen = 2587
(null):2536: |2| => fetch input
(null):2697: |2| in_left: 5, nb_want: 2592
(null):2721: |2| in_left: 5, nb_want: 2592
(null):2722: |2| ssl->f_recv(_timeout)() returned 2587 (-0xfffff5e5)
(null):2742: |2| <= fetch input
(null):4233: |4| dumping 'input record from network' (2592 bytes)
.
.
.
(null):3626: |3| handshake message: msglen = 2587, type = 11, hslen = 2587
(null):4385: |2| <= read record
(null):5606: |3| peer certificate #1:
(null):5606: |3| cert. version     : 3
(null):5606: |3| serial number     : 04:35:05:93:F4:8E:A4:A3:D6:0A:8A:18:0A:71:05:E9:4D:6C
(null):5606: |3| issuer name       : C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
(null):5606: |3| subject name      : CN=xyz.xyz
(null):5606: |3| issued  on        : 2020-03-20 07:16:31
(null):5606: |3| expires on        : 2020-06-18 07:16:31
(null):5606: |3| signed using      : RSA with SHA-256
(null):5606: |3| RSA key size      : 2048 bits

while on the micro, I am facing the issue that the modem cannot read > ~1500 bytes from the socket at once. Will this#define MBEDTLS_SSL_MAX_CONTENT_LEN help?

Hi @euphoriadamage
If you have low MTU, I would recomend you follow this article.
However, it is more focused on a DTLS connection.

Since you have low bandwisth, I strongly recommend you use ECDSA based ciphersuites ( and ECDHE key exchange), as the ECC keys are shorter with similar security strength.
RSA signed certificates are usually strong, and they are usually the bottleneck, in size, of the handshake messages. In addition, they are usually larger than 1500 Bytes.
Since the certificate message is larger than 1500, the fragmentation might not work as expected.
Regards

Thank you for the support.
I am out in blue waters here (setting up a server and so on), and I would really use some advice.

I have my server set up, which supports, among others,

ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1

From what I understand, it would be a good scenario to go for ECDHE-ECDSA-AES256-GCM-SHA384

On the client side with mbedTLS now, is it possible to provide an example configuration that supports that specific ciphersuite? Or a route to strip a config and only provide the essentials for that, or any similar ECDSA-ECDHE cipher? The brute-force method would be for me to check check_config.h and where it mentions ECDSA or ECDHE and enable all these definitions but …

Thanks again and I hope things are OK with that panic situation we are all in rn.
Regards

Hi,
Since you have these ciphersuites supported, then yes, you could this should be good.
However, you should also use only ECDSA certificates, in order for them to be used.
in addition, you should disable all the RSA based ciphersuites. If you don’t need RSa at all, just disable MBEDTLS_RSA_C in your configuration. If you do need this algorithm, then disable MBEDTLS_KEY_EXCHANGE_RSA_ENABLED, MBEDTLS_KEY_EXCHANGE_DHE_RSA_ENABLED, MBEDTLS_KEY_EXCHANGE_ECDHE_RSA_ENABLED and MBEDTLS_KEY_EXCHANGE_ECDH_RSA_ENABLED.
these should disallow using RSA in your keyexchange and as your authentication protocol.
Regards