- mbed-tls - lists.trustedfirmware.org

NV_SEED read working and write not working

by Subramanian Gopi Krishnan

Hi, I am working on a embedded platform, that does not has any entropy source except system ticks. To improve the randomness, I am trying to utilize NV_SEED operations. Configuration file I have enabled: #define MBEDTLS_ENTROPY_NV_SEED #define MBEDTLS_PLATFORM_NV_SEED_ALT After initializing and before seeding random number generator, I assign functions of nv seed read and write to platform seeding function as below. if( r = mbedtls_platform_set_nv_seed(FN_NV_SEED_RD, FN_NV_SEED_WR) ) { return( r ); } if( r = mbedtls_ctr_drbg_seed( &CtrDrbg, mbedtls_entropy_func, &Entropy, (const unsigned char *) u8SeedingString, (size_t)Length ) ) { return ( r ); } Later functions to generate random and free context. While running, I could see only the FN_NV_SEED_RD function is getting called. And, FN_NV_SEED_WR function is not getting called. Could anyone suggest how to trace the issue. I do not have debugger on for my platform. I could debug only with print statements. Thanks, Gopi Krishnan

4 years

1
1
0 0

Signing without explicit private key

by stefano664

Hi all, I'm using mbedTLS libraries with an OPTIGA cryptochip. At the moment, when I call the sign function: err = mbedtls_pk_sign(&priv_key, MBEDTLS_MD_SHA384, hash, 0, sign, &olen, mbedtls_ctr_drbg_random, &ctr_drbg); I need to pass it a valid private key else if it isn't used, because alternative sign routine use the one into cryptochip. It is possible to avoid passing this key? Best regards, Stefano Mologni

4 years

1
0
0 0

Please help regarding [ERR ][TLSx]: mbedtls_ssl_handshake() failed: -0x7780 (-30592): SSL

by victor Wolff

Hello I am relatively new to mbedTLS, but I'm trying to develop an MQTT client running on an STM32 board connected to an ESP8266 MCU/WiFi module. The client should publish messages to a local broker/server where I am using Mosquitto for that purpose. I want to test different Cipher suites but when I limiting the Server to only accept one particle Cipher suite I receive an error from the server point of view "1622667145: OpenSSL Error[0]: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher" Which I find is strange because when I read through the debug list presented below it says "[DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c02c". I "think" I have enabled the "MBEDTLS_SHA256_C" in the config file (mbed_lib.json) for the TLSsocket, and the cipher suites I have tested so far to limit it for is: DHE-RSA-AES128-SHA |AES128-SHA | DHE-RSA-AES128-SHA256. Could you please look at the debug list presented below to see if anything looks suspicious, or if you have any ideas? because I am truly lost and I am shooting in the dark trying to find the answer online... Thank you sincerely in advance Best regards Victor --------Debug list -------- AT< WIFI CONNECTED AT< WIFI GOT IP AT< AT= OK AT> AT+CIFSR AT< AT< AT+CIFSR AT< +CIFSR:APIP,"192.168.4.1" AT< +CIFSR:APMAC,"da:bf:c0:0d:c5:d8" AT= +CIFSR:STAIP,"192.168.10.103" AT< AT< +CIFSR:STAMAC,"d8:bf:c0:0d:c5:d8" AT< AT= OK Network interface opened successfully. Connecting to host 192.168.10.165:8883 ... Hello [INFO][TLSx]: Connecting to 192.168.10.165:8883 AT> AT+CIPSTART=0,"TCP","192.168.10.165",8883 AT< AT< AT+CIPSTART=0,"TCP","192.168.10.165",8883 AT< 0,CONNECT AT< AT= OK [INFO][TLSx]: Connected. [INFO][TLSx]: Starting the TLS handshake... [DBG ][TLSx]: ssl_tls.c:6335: |2| => handshake [DBG ][TLSx]: ssl_cli.c:3279: |2| client state: 0 [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output [DBG ][TLSx]: ssl_tls.c:2428: |2| <= flush output [DBG ][TLSx]: ssl_cli.c:3279: |2| client state: 1 [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output [DBG ][TLSx]: ssl_tls.c:2428: |2| <= flush output [DBG ][TLSx]: ssl_cli.c:0717: |2| => write client hello [DBG ][TLSx]: ssl_cli.c:0754: |3| client hello, max version: [3:3] [DBG ][TLSx]: ssl_cli.c:0693: |3| client hello, current time: 14712 [DBG ][TLSx]: ssl_cli.c:0764: |3| dumping 'client hello, random bytes' (32 bytes) [DBG ][TLSx]: ssl_cli.c:0764: |3| 0000: 00 00 39 78 00 7d 4e 7a c5 43 7f d9 5b 0c cd 3f ..9x.}Nz.C..[..? [DBG ][TLSx]: ssl_cli.c:0764: |3| 0010: 01 a0 2f 60 8e a5 c1 54 1c 0e 58 6a a3 da c0 7a ../`...T..Xj...z [DBG ][TLSx]: ssl_cli.c:0817: |3| client hello, session id len.: 0 [DBG ][TLSx]: ssl_cli.c:0818: |3| dumping 'client hello, session id' (0 bytes) [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c02c [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c030 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0ad [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c024 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c028 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0af [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c02b [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c02f [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0ac [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c023 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c027 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0ae [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c038 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c037 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: 00a9 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0a5 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: 00af [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0a9 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: 00a8 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0a4 [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: 00ae [DBG ][TLSx]: ssl_cli.c:0884: |3| client hello, add ciphersuite: c0a8 [DBG ][TLSx]: ssl_cli.c:0918: |3| client hello, got 23 ciphersuites [DBG ][TLSx]: ssl_cli.c:0949: |3| client hello, compress len.: 1 [DBG ][TLSx]: ssl_cli.c:0950: |3| client hello, compress alg.: 0 [DBG ][TLSx]: ssl_cli.c:0071: |3| client hello, adding server name extension: 192.168.10 .165 [DBG ][TLSx]: ssl_cli.c:0178: |3| client hello, adding signature_algorithms extension [DBG ][TLSx]: ssl_cli.c:0263: |3| client hello, adding supported_elliptic_curves extensi on [DBG ][TLSx]: ssl_cli.c:0326: |3| client hello, adding supported_point_formats extension [DBG ][TLSx]: ssl_cli.c:0507: |3| client hello, adding encrypt_then_mac extension [DBG ][TLSx]: ssl_cli.c:0541: |3| client hello, adding extended_master_secret extension [DBG ][TLSx]: ssl_cli.c:0575: |3| client hello, adding session ticket extension [DBG ][TLSx]: ssl_cli.c:1022: |3| client hello, total extension length: 73 [DBG ][TLSx]: ssl_tls.c:2701: |2| => write record [DBG ][TLSx]: ssl_tls.c:2835: |3| output record: msgtype = 22, version = [3:1], msglen = 164 [DBG ][TLSx]: ssl_tls.c:2840: |4| dumping 'output record sent to network' (169 bytes) [DBG ][TLSx]: ssl_tls.c:2840: |4| 0000: 16 03 01 00 a4 01 00 00 a0 03 03 00 00 39 78 00 .............9x. [DBG ][TLSx]: ssl_tls.c:2840: |4| 0010: 7d 4e 7a c5 43 7f d9 5b 0c cd 3f 01 a0 2f 60 8e }Nz.C..[..?../`. [DBG ][TLSx]: ssl_tls.c:2840: |4| 0020: a5 c1 54 1c 0e 58 6a a3 da c0 7a 00 00 2e c0 2c ..T..Xj...z...., [DBG ][TLSx]: ssl_tls.c:2840: |4| 0030: c0 30 c0 ad c0 24 c0 28 c0 af c0 2b c0 2f c0 ac .0...$.(...+./.. [DBG ][TLSx]: ssl_tls.c:2840: |4| 0040: c0 23 c0 27 c0 ae c0 38 c0 37 00 a9 c0 a5 00 af .#.'...8.7...... [DBG ][TLSx]: ssl_tls.c:2840: |4| 0050: c0 a9 00 a8 c0 a4 00 ae c0 a8 00 ff 01 00 00 49 ...............I [DBG ][TLSx]: ssl_tls.c:2840: |4| 0060: 00 00 00 13 00 11 00 00 0e 31 39 32 2e 31 36 38 .........192.168 [DBG ][TLSx]: ssl_tls.c:2840: |4| 0070: 2e 31 30 2e 31 36 35 00 0d 00 12 00 10 06 03 06 .10.165......... [DBG ][TLSx]: ssl_tls.c:2840: |4| 0080: 01 05 03 05 01 04 03 04 01 03 03 03 01 00 0a 00 ................ [DBG ][TLSx]: ssl_tls.c:2840: |4| 0090: 06 00 04 00 18 00 17 00 0b 00 02 01 00 00 16 00 ................ [DBG ][TLSx]: ssl_tls.c:2840: |4| 00a0: 00 00 17 00 00 00 23 00 00 ......#.. [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output [DBG ][TLSx]: ssl_tls.c:2434: |2| message length: 169, out_left: 169 AT> AT+CIPSEND=0,169 AT< AT< AT+CIPSEND=0,169 AT< AT< OK AT= > [DBG ][TLSx]: ssl_tls.c:2441: |2| ssl->f_send() returned 169 (-0xffffff57) [DBG ][TLSx]: ssl_tls.c:2460: |2| <= flush output [DBG ][TLSx]: ssl_tls.c:2850: |2| <= write record [DBG ][TLSx]: ssl_cli.c:1049: |2| <= write client hello [DBG ][TLSx]: ssl_cli.c:3279: |2| client state: 2 [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output [DBG ][TLSx]: ssl_tls.c:2428: |2| <= flush output [DBG ][TLSx]: ssl_cli.c:1410: |2| => parse server hello [DBG ][TLSx]: ssl_tls.c:3728: |2| => read record [DBG ][TLSx]: ssl_tls.c:2208: |2| => fetch input [DBG ][TLSx]: ssl_tls.c:2365: |2| in_left: 0, nb_want: 5 AT< AT< Recv 169 bytes AT< AT< SEND OK AT< AT! +IPD AT= ,0,7: AT< 0,CLOSED [DBG ][TLSx]: ssl_tls.c:2389: |2| in_left: 0, nb_want: 5 [DBG ][TLSx]: ssl_tls.c:6345: |2| <= handshake [DBG ][TLSx]: ssl_tls.c:6335: |2| => handshake [DBG ][TLSx]: ssl_cli.c:3279: |2| client state: 2 [DBG ][TLSx]: ssl_tls.c:2416: |2| => flush output [DBG ][TLSx]: ssl_tls.c:2428: |2| <= flush output [DBG ][TLSx]: ssl_cli.c:1410: |2| => parse server hello [DBG ][TLSx]: ssl_tls.c:3728: |2| => read record [DBG ][TLSx]: ssl_tls.c:2208: |2| => fetch input [DBG ][TLSx]: ssl_tls.c:2365: |2| in_left: 0, nb_want: 5 [DBG ][TLSx]: ssl_tls.c:2389: |2| in_left: 0, nb_want: 5 [DBG ][TLSx]: ssl_tls.c:2391: |2| ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) [DBG ][TLSx]: ssl_tls.c:2403: |2| <= fetch input [DBG ][TLSx]: ssl_tls.c:3479: |4| dumping 'input record header' (5 bytes) [DBG ][TLSx]: ssl_tls.c:3479: |4| 0000: 15 03 03 00 02 ..... [DBG ][TLSx]: ssl_tls.c:3485: |3| input record: msgtype = 21, version = [3:3], msglen = 2 [DBG ][TLSx]: ssl_tls.c:2208: |2| => fetch input [DBG ][TLSx]: ssl_tls.c:2365: |2| in_left: 5, nb_want: 7 [DBG ][TLSx]: ssl_tls.c:2389: |2| in_left: 5, nb_want: 7 [DBG ][TLSx]: ssl_tls.c:2391: |2| ssl->f_recv(_timeout)() returned 2 (-0xfffffffe) [DBG ][TLSx]: ssl_tls.c:2403: |2| <= fetch input [DBG ][TLSx]: ssl_tls.c:3656: |4| dumping 'input record from network' (7 bytes) [DBG ][TLSx]: ssl_tls.c:3656: |4| 0000: 15 03 03 00 02 02 28 ......( [DBG ][TLSx]: ssl_tls.c:3960: |2| got an alert message, type: [2:40] [DBG ][TLSx]: ssl_tls.c:3968: |1| is a fatal alert message (msg 40) [DBG ][TLSx]: ssl_tls.c:3744: |1| mbedtls_ssl_handle_message_type() returned -30592 (-0x 7780) [DBG ][TLSx]: ssl_cli.c:1416: |1| mbedtls_ssl_read_record() returned -30592 (-0x7780) [DBG ][TLSx]: ssl_tls.c:6345: |2| <= handshake [ERR ][TLSx]: mbedtls_ssl_handshake() failed: -0x7780 (-30592): SSL AT> AT+CIPCLOSE=0 AT< AT+CIPCLOSE=0 AT< UNLINK AT< AT< ERROR AT> AT+CIPCLOSE=0 AT< AT+CIPCLOSE=0 AT< UNLINK AT< AT< ERROR ERROR: rc from TCP connect is -30592 [DBG ][TLSx]: ssl_tls.c:7055: |2| => free [DBG ][TLSx]: ssl_tls.c:7120: |2| <= free AT> AT+CWQAP AT< AT+CWQAP AT< AT= OK

4 years

1
0
0 0

Parsing PKCS12 file

by Sunil Jain

Hello, We have requirements of parsing PKCS12 file in our project to import the certificate. I have seen the code and am not able to find the related API which can be used to parse the PKCS12 file. Do you have some sample example code which does this work? Thanks for your help. -- Regards, Sunil Jain

4 years

1
0
0 0

FTP Data connection handshake is failing

by Sunil Jain

Hello, We are porting MbedTLS 2.16 for FTP server. There are 2 connection in FTP communication, Control and data. For control communication we are ok with handshake but data communication handshake is having issue. We have observed with FTP Client (FileZilla) our earlier implementation of FTP server with Mocana secure library, we used to send certificate and server key exchange in control communication handshake only, for Data communication handshake ServerHello and change cipher spec was sent. But in case of MbedTLS, we are sending certificate and server key exchange in data communication handshake also. FTP Client (FileZilla) is rejecting the handshake after receiving the server certificate server key exchange and from the FTP server as I believe it is expecting session resumption and FTP Server is waiting for client key exchange in handshake. In attached wireshark trace, packet number 1570 is having issue. When we tested this server with another FTP client (WinSCP), its working fine as this client is not expecting session resumption. As I go through the code documentation of MbedTLS, I found that we cannot set the session resumption at server side, only client side we can do this setting. How can we make FTP server ready with session resumption? Please support us. Thanks and Regards, Sunil

4 years

1
0
0 0

ECDSA signature verification failure

by Nassim Eddequiouaq

Hi, I'm running into a signature verification issue with ECDSA. I've generated test values with python and have a working signature verification: --------- Python --------- In [66]: sig_bytes.hex() Out[66]: '30440220704fb7e4e51dc0f2f9bb0a3645d433bdd7ea23dff5e0e231449261f043c645db02203e648d4924c56b14004d984bcacf954e47ae6109db15597695664d06c0b782c2' In [67]: statement Out[67]: b'1:VALID_SESSION:2:xxxx' In [68]: key = load_pem_public_key(b'-----BEGIN PUBLIC KEY-----\nMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWaBFEuO91YcVK6mJqDtjCvRT8cE7\nfjKNmOxU/wYzSPVHyyZ0IhxY9 ...: UFwZKWO1iEWkeReHK/SNRk2rtvX4qX44g==\n-----END PUBLIC KEY-----\n') In [69]: key.verify(sig_bytes, statement, primitives.asymmetric.ec.ECDSA(primitives.hashes.SHA256())) Success ---------------------------- And have the following code on the mbedTLS C side which fails on mbedtls_ecdsa_read_signature(): --------- MbedTLS --------- uint8_t sha256_digest_buff[SHA256_DIGEST_BYTES] = { 0 }; uint8_t* message = (uint8_t*)"1:VALID_SESSION:2:xxxx"; uint8_t* public_key_pem = (uint8_t*)"-----BEGIN PUBLIC KEY-----\nMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEc8uijCCOayvXQz5+2fjVjAbNraYf\nReDKcN8p5ttPedCXxr8A9rGcmA89pFcmpuDRvZgx+qiRC/pNcs0kqy1VVQ==\n-----END PUBLIC KEY-----\n"; uint8_t signature[70] = {0x30, 0x44, 0x02, 0x20, 0x70, 0x4f, 0xb7, 0xe4, 0xe5, 0x1d, 0xc0, 0xf2, 0xf9, 0xbb, 0x0a, 0x36, 0x45, 0xd4, 0x33, 0xbd, 0xd7, 0xea, 0x23, 0xdf, 0xf5, 0xe0, 0xe2, 0x31, 0x44, 0x92, 0x61, 0xf0, 0x43, 0xc6, 0x45, 0xdb, 0x02, 0x20, 0x3e, 0x64, 0x8d, 0x49, 0x24, 0xc5, 0x6b, 0x14, 0x00, 0x4d, 0x98, 0x4b, 0xca, 0xcf, 0x95, 0x4e, 0x47, 0xae, 0x61, 0x09, 0xdb, 0x15, 0x59, 0x76, 0x95, 0x66, 0x4d, 0x06, 0xc0, 0xb7, 0x82, 0xc2}; [...] int mbedtls_status = MBEDTLS_ERR_ERROR_CORRUPTION_DETECTED; mbedtls_pk_context pubkey_ctx; mbedtls_ecdsa_context ecdsa_ctx; mbedtls_ecp_curve_info *curve_info = NULL; /* Create public key context */ mbedtls_pk_init(&pubkey_ctx); /* Create ecdsa context */ mbedtls_ecdsa_init(&ecdsa_ctx); /* Parse public key */ if ((mbedtls_status = mbedtls_pk_parse_public_key(&pubkey_ctx, pubkey_pem, pubkey_pem_len)) != 0) { ERRORF("Failure failure parsing PEM-encoded ecdsa-p256r1 public key, mbedTLS status: %d", mbedtls_status); ret = E_INVAL_PUBKEY; goto cleanup; } /* Hash the message with sha256 */ if ((mbedtls_status = mbedtls_sha256_ret(message, message_len, sha256_digest_buff, 0 /* Not 224 bits hashing */ )) != 0) { ERRORF("Failure sha256-hashing message before ecdsa-p256r1 signature verification, mbedTLS status: %d", mbedtls_status); ret = E_FAILED_HASH; goto cleanup; } /* Set the public key as the ecdsa signature verification key */ if ((mbedtls_status = mbedtls_ecp_copy(&ecdsa_ctx.Q, &mbedtls_pk_ec(pubkey_ctx)->Q)) != 0 ) { ERRORF("Failure copying ecdsa-p256r1 public key to ecdsa context, mbedTLS status: %d", mbedtls_status); ret = E_UNKNOWN; goto cleanup; } if ((mbedtls_status = mbedtls_ecp_group_copy(&ecdsa_ctx.grp, &mbedtls_pk_ec(pubkey_ctx)->grp)) != 0 ) { ERRORF("Failure copying ecdsa-p256r1 public key group to ecdsa context, mbedTLS status: %d", mbedtls_status); ret = E_UNKNOWN; goto cleanup; } /* Verify ecdsa-p256r1 signature verification */ if ((mbedtls_status = mbedtls_ecdsa_read_signature(&ecdsa_ctx, sha256_digest_buff, sizeof(sha256_digest_buff), signature, signature_len)) != 0) { ERRORF("Failure verifying ecdsa-p256r1 signature against message, mbedTLS status: %d", mbedtls_status); ret = E_INVALID_SIG; goto cleanup; } /* Success */ ret = E_SUCCESS; ---------------------------- Also, `mbedtls_ecp_curve_info_from_grp_id( ecdsa_ctx.grp.id )->name` yields the right curve prior to the signature verification. I must be missing something in the process. Would love to get some input, thanks a lot! -- Nassim Eddequiouaq

4 years

1
0
0 0

Re: [mbed-tls] Request for Support [Issue : Webserver handshake failing with self-signed certificate]

by Selin Chris

Hi Gilles, Thanks for the quick reply. I migrated to version 2.16, and I have seen the same issue is still there. Moreover, we have reseeded the RNG, still issue is there. I created a client and it's working fine, it's able to handshake and send data to the server. Only problem is server communication where control is going in infinite loop while creating server key exchange. As you asked for the call stack of the loop, I am attaching the call stack with this mail. Please support us. Thank you. Regards, Selin. On Fri, May 21, 2021 at 5:30 PM <mbed-tls-request(a)lists.trustedfirmware.org> wrote: > Send mbed-tls mailing list submissions to > mbed-tls(a)lists.trustedfirmware.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > or, via email, send a message with subject or body 'help' to > mbed-tls-request(a)lists.trustedfirmware.org > > You can reach the person managing the list at > mbed-tls-owner(a)lists.trustedfirmware.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mbed-tls digest..." > > > Today's Topics: > > 1. Re: Request for Support [Issue : Webserver handshake failing > with self-signed certificate] (Gilles Peskine) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 20 May 2021 15:13:54 +0200 > From: Gilles Peskine <gilles.peskine(a)arm.com> > To: mbed-tls(a)lists.trustedfirmware.org > Subject: Re: [mbed-tls] Request for Support [Issue : Webserver > handshake failing with self-signed certificate] > Message-ID: <93c3cd71-bdc1-c3ec-4bbc-89ff995a8444(a)arm.com> > Content-Type: text/plain; charset=utf-8 > > Hi Selin, > > A possible problem could be a misconfigured random generator. However > this is purely speculation. Can you get a stack trace? Finding the root > cause requires finding where mbedtls_mpi_cmp_mpi is called. > > Please note that Mbed TLS 2.16.3 has known bugs and vulnerabilities. You > should upgrade to the latest bug-fixing version of the 2.16 branch, > 2.16.10. > > -- > Gilles Peskine > Mbed TLS developer > > On 20/05/2021 13:06, Selin Chris via mbed-tls wrote: > > > > Hi, > > > > Thank you for adding me to the mbed-tls mailing list. > > > > We have created a self-signed certificate with ECC key of > > MBEDTLS_ECP_DP_SECP256R1 type, since it is a self-signed certificate > > after we send the certificate to chrome from our web server it shows > > not trusted and goes to the page where we need to manually proceed > > with the acceptance of the certificate to allow further communication. > > After this we again have to perform handshake for which we need to > > prepare the server key exchange, while preparing the server key > > exchange we notice that it is infinitely calling the > > mbedtls_mpi_cmp_mpi() function in bignum.c and the execution is not > > able to proceed hereafter. Sometimes we also see that when executing > > ssl_prepare_server_key_exchange() function in ssl_srv.c we find > > ciphersuite_info pointer as null and the program goes into data panic > > due to that. We have checked our stacks and not seen any sign of > > corruption. > > > > The mbedtls version that we are using is mbedtls-2.16.3. > > Please find the attached wireshark trace during this scenario. The IP > > 192.168.2.67 corresponds to our webserver and 192.168.2.100 the pc > > with the browser. > > > > Please let us know the root-cause of the issue and the actions to be > > taken to fix this - can you please expedite as this is a blocking > > issue in our project. > > > > Thanks for the support. > > > > Regards, > > Selin. > > > > > > > > > > ------------------------------ > > Subject: Digest Footer > > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > > > ------------------------------ > > End of mbed-tls Digest, Vol 15, Issue 8 > *************************************** >

4 years

1
0
0 0

Server and client fails with “Verification of the message MAC failed” after Successful Handshake

by Vaibhav Sathye

Hi I am writing a server client with Libuv as tcp stack and mbedtls as ssl. I am able to do a successful handshake between server and client but after that when I try to write/read application data it fails with “Verification of the message MAC failed”. After inspecting debug logs, I found the server and client have the same Pre-master master secret and IV and still it is failing. Currently both client and server are on the same machine . I am attaching server and client logs. Any help is appreciated. server.log <https://drive.google.com/file/d/1oaMMV2_YVDL8GLn6GH3PIQSIH5BDbGeU/view?usp=…> client.log <https://drive.google.com/file/d/1Z9P1ssglqRpBUmXF9TuRQd6KJKvyw6RJ/view?usp=…> Thanks Vaibhav

4 years

1
0
0 0

Re: [mbed-tls] Request for Support [Issue : Webserver handshake failing with self-signed certificate]

by Gilles Peskine

Hi Selin, A possible problem could be a misconfigured random generator. However this is purely speculation. Can you get a stack trace? Finding the root cause requires finding where mbedtls_mpi_cmp_mpi is called. Please note that Mbed TLS 2.16.3 has known bugs and vulnerabilities. You should upgrade to the latest bug-fixing version of the 2.16 branch, 2.16.10. -- Gilles Peskine Mbed TLS developer On 20/05/2021 13:06, Selin Chris via mbed-tls wrote: > > Hi, > > Thank you for adding me to the mbed-tls mailing list. > > We have created a self-signed certificate with ECC key of > MBEDTLS_ECP_DP_SECP256R1 type, since it is a self-signed certificate > after we send the certificate to chrome from our web server it shows > not trusted and goes to the page where we need to manually proceed > with the acceptance of the certificate to allow further communication. > After this we again have to perform handshake for which we need to > prepare the server key exchange, while preparing the server key > exchange we notice that it is infinitely calling the > mbedtls_mpi_cmp_mpi() function in bignum.c and the execution is not > able to proceed hereafter. Sometimes we also see that when executing > ssl_prepare_server_key_exchange() function in ssl_srv.c we find > ciphersuite_info pointer as null and the program goes into data panic > due to that. We have checked our stacks and not seen any sign of > corruption. > > The mbedtls version that we are using is mbedtls-2.16.3. > Please find the attached wireshark trace during this scenario. The IP > 192.168.2.67 corresponds to our webserver and 192.168.2.100 the pc > with the browser. > > Please let us know the root-cause of the issue and the actions to be > taken to fix this - can you please expedite as this is a blocking > issue in our project. > > Thanks for the support. > > Regards, > Selin. > > >

4 years

1
0
0 0

Request for Support [Issue : Webserver handshake failing with self-signed certificate]

by Selin Chris

Hi, Thank you for adding me to the mbed-tls mailing list. We have created a self-signed certificate with ECC key of MBEDTLS_ECP_DP_SECP256R1 type, since it is a self-signed certificate after we send the certificate to chrome from our web server it shows not trusted and goes to the page where we need to manually proceed with the acceptance of the certificate to allow further communication. After this we again have to perform handshake for which we need to prepare the server key exchange, while preparing the server key exchange we notice that it is infinitely calling the mbedtls_mpi_cmp_mpi() function in bignum.c and the execution is not able to proceed hereafter. Sometimes we also see that when executing ssl_prepare_server_key_exchange() function in ssl_srv.c we find ciphersuite_info pointer as null and the program goes into data panic due to that. We have checked our stacks and not seen any sign of corruption. The mbedtls version that we are using is mbedtls-2.16.3. Please find the attached wireshark trace during this scenario. The IP 192.168.2.67 corresponds to our webserver and 192.168.2.100 the pc with the browser. Please let us know the root-cause of the issue and the actions to be taken to fix this - can you please expedite as this is a blocking issue in our project. Thanks for the support. Regards, Selin.

4 years

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls