June 2021 - mbed-tls - lists.trustedfirmware.org

Re: [mbed-tls] ECDHE Shared Secret is computed differently

by Brian D.

Hi Linjin, I am not part of the mbed-tls staff but I developed a lot with mbed library and I had your same problem. Try to check the byte order, I had issues when computing the shared secret because I had the little endian from the other side but mbed uses big endian. Try to do a quick test and this could resolve your problem, let me know! Bye, Brian 24 giu 2021, 15:35 da mbed-tls(a)lists.trustedfirmware.org: > Hello , > We are trying to perform an ECDHE key exchange between two devices running on different platforms.[one on Linux and another on RTOS] > Both the devices use the same code to compute the ECDHE shared secret. The peer public parameters are exchanged in the base64 format and passed to the functions correctly , but the final shared secret computed seems to be different on both ends. > We have tested the same source code on Visual studio and found working. > I have attached the source files > > Could you please comment on why the computed shared secret are different on both the ends? > > Thanks, > LIJIN T V >

5 years

1
0
0 0

ECDHE Shared Secret is computed differently

by T V LIJIN (EXT)

Hello , We are trying to perform an ECDHE key exchange between two devices running on different platforms.[one on Linux and another on RTOS] Both the devices use the same code to compute the ECDHE shared secret. The peer public parameters are exchanged in the base64 format and passed to the functions correctly , but the final shared secret computed seems to be different on both ends. We have tested the same source code on Visual studio and found working. I have attached the source files Could you please comment on why the computed shared secret are different on both the ends? Thanks, LIJIN T V

5 years

1
0
0 0

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

by Gilles Peskine

Hi Victor, Looking through the ciphersuites your client sends, I think you've only enabled ECDHE ciphersuites, not DHE ciphersuites, which makes perfect sense, especially on an embedded device, since DH(E) is a lot slower than ECDH(E) for the same security level. So on the server you need to enable ECDHE ciphersuites. Best regards, -- Gilles Peskine Mbed TLS developer On 09/06/2021 23:03, victor Wolff via mbed-tls wrote: > > 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 > >

5 years

1
0
0 0

Re: [mbed-tls] export keys in pkcs8. plain or encrypted

by Gilles Peskine

Hi Andrey, Thank you for your interest in Mbed TLS! In general we welcome contributions to the project. Unfortunately, our limiting factor is bandwidth for review. In 2021 the Mbed TLS team has grown, so we have more time for reviews, but we are still struggling to catch up with the large backlog. There is already an old attempt to add unencrypted PKCS#8 writing support (https://github.com/ARMmbed/mbedtls/issues/1695 <https://github.com/ARMmbed/mbedtls/issues/1695>). There is a long pending request for encrypted PKCS#8 writing support (https://github.com/ARMmbed/mbedtls/issues/1372 <https://github.com/ARMmbed/mbedtls/issues/1372>) but I'm not aware of any prior implementation. We would be glad to have your contribution, but I must be honest and say it might take us several months to get around to it. Best regards, -- Gilles Peskine Mbed TLS developer On 09/06/2021 22:46, Андрей Макаров via mbed-tls wrote: > Recently I used mbedtls library in my working project. In accordance > with the needs of the project, I added some functions to mbedtls for > saving and loading keys in plain and encrypted pem and der forms. > The changes are still raw and should be brought up to pull request > requirements - there are no tests, since the functions tested as part > of a working project which uses mbedtls. I can, over time, finalize > the changes to a pull request, but it will take some time and effort > that you don't want to waste unnecessarily — this will have to be done > at my home time. > If there is an interest for this work, then I will try to do it, but > if few people need it or do not coincide with the general direction of > development of the project, then I would not bother. > To be done: 1) added mbedtls_pk_write_key_pkcs8_der() write > non-encrypted pkcs8 der key 2) added mbedtls_pk_write_key_pkcs8_pem() > write non-encrypted pkcs8 pem key 3) added > mbedtls_pk_write_key_encrypted_pem() write legacy encryped pem file > with DEK-Info header 4) added > mbedtls_pk_write_key_pkcs8_encrypted_der() write to encrypted pkcs8 > der key; pkcs5 pbes1, pkcs12 and pbes2 schemes are supported 5) added > mbedtls_pk_write_key_pkcs8_encrypted_pem() same as above but pem key > 6) changed mbedtls_pem_read_buffer() which reads legacy encrypted pem > formats (with DEK-Info header) now it uses mbedtls_cipher_… functions > which allow to use any supported cipher rather than four enforced (was > limited to des-cbc, des-ede3-cbc, ars-128-cbc and aes-256-cbc) 7) > changed pk_parse_key_pkcs8_encrypted_der() 7.1) added pkcs5 pbes1 > support MD5-DES-CB CpbeWithMD5AndDES-CBC) and SHA1-DES-CBC > (pbeWithSHA1AndDES-CBC) 7.2) changed pkcs12 pbe (use same cipher for > all SHA1-DES2-EDE-CBC (pbeWithSHAAnd2-KeyTripleDES-CBC), > SHA1-DES3-EDE-CBC (pbeWithSHAAnd3-KeyTripleDES-CBC) and SHA1-RC4-128 > (pbeWithSHA1And128BitRC4); (the special > mbedtls_pkcs12_pbe_sha1_rc4_128() is not used now and may be removed) > 7.3) changed pkcs5 pbes2 support: added AES-128-CBC and AES-256-CBC > ciphers Some «preview» is available at fork > https://github.com/loafer-mka/mbedtls > <https://github.com/loafer-mka/mbedtls>, branch ‘dev_clean’ Of course, > many changes relate to obsolete formats, and may be undesirable … also > I do not touch PSK at all. > Please, give me some feedback — try to finish this with tests, pull > request, etc or not. ----------- Regards, Andrey >

5 years

1
0
0 0

Re: [mbed-tls] mbedtls_ssl_set_bio hangs

by Ron Eggler

Just finishing off this thread: The issue appeared due to an invalid pointer access else where in the application that coincided with the mbedtls_ssl_set_bio function. Working on resolution now. Thanks for all the help, pointers & hints from the list! On 2021-06-08 2:27 p.m., Ron Eggler via mbed-tls wrote: > > Yes, there's some kind of "memory magic" going on here: > > The task got terminated due to "Load from invalid memory" > > and I see: > > |Instruction at 0x6310604d is trying to load data at 0x4, which is an > invalid memory area. You are probably dereferencing a NULL pointer.| > > |and i got some trace back addresses that point to:| > > * > > mbedtls_aes_crypt_ecb > > * > > mbedtls_ctr_drbg_random_with_add > > * > > mbedtls_ssl_handshake_step > > * > > mbedtls_ssl_handshake > > > || > > On 2021-06-08 11:43 a.m., Gilles Peskine via mbed-tls wrote: >> Hi Ron, >> >> This behavior can't be explained by the library code and the code you >> posted alone. There has to be something wrong elsewhere. >> >> Check that you aren't exceeding a limitation such as the stack size or >> the size of executable and data sections. If it can be an issue on your >> platform, check that load addresses are correct and sections don't >> overlap. Make sure there's no overlap with any device memory mapping either. >> >> Make sure that the whole binary is compiled with consistent settings. >> The layout of mbedtls_ssl_context can be influenced by the Mbed TLS >> configuration, so make sure that there's a single copy of >> mbedtls/config.h and both Mbed TLS itself and your application were >> built against that copy. The layout of mbedtls_ssl_context can also be >> influenced by compiler settings on some platforms (e.g. structure >> packing options), so make sure those are consistent across your build. >> >> That's all I can think of for now. It may help to add a lot of printf >> debugging with %p on various addresses, and compare these addresses with >> what you know about memory mappings on that platform. Good luck! >> >

5 years

1
0
0 0

export keys in pkcs8. plain or encrypted

by Андрей Макаров

Recently I used mbedtls library in my working project. In accordance with the needs of the project, I added some functions to mbedtls for saving and loading keys in plain and encrypted pem and der forms. The changes are still raw and should be brought up to pull request requirements - there are no tests, since the functions tested as part of a working project which uses mbedtls. I can, over time, finalize the changes to a pull request, but it will take some time and effort that you don't want to waste unnecessarily — this will have to be done at my home time. If there is an interest for this work, then I will try to do it, but if few people need it or do not coincide with the general direction of development of the project, then I would not bother. To be done: 1) added mbedtls_pk_write_key_pkcs8_der() write non-encrypted pkcs8 der key 2) added mbedtls_pk_write_key_pkcs8_pem() write non-encrypted pkcs8 pem key 3) added mbedtls_pk_write_key_encrypted_pem() write legacy encryped pem file with DEK-Info header 4) added mbedtls_pk_write_key_pkcs8_encrypted_der() write to encrypted pkcs8 der key; pkcs5 pbes1, pkcs12 and pbes2 schemes are supported 5) added mbedtls_pk_write_key_pkcs8_encrypted_pem() same as above but pem key 6) changed mbedtls_pem_read_buffer() which reads legacy encrypted pem formats (with DEK-Info header) now it uses mbedtls_cipher_… functions which allow to use any supported cipher rather than four enforced (was limited to des-cbc, des-ede3-cbc, ars-128-cbc and aes-256-cbc) 7) changed pk_parse_key_pkcs8_encrypted_der() 7.1) added pkcs5 pbes1 support MD5-DES-CB CpbeWithMD5AndDES-CBC) and SHA1-DES-CBC (pbeWithSHA1AndDES-CBC) 7.2) changed pkcs12 pbe (use same cipher for all SHA1-DES2-EDE-CBC (pbeWithSHAAnd2-KeyTripleDES-CBC), SHA1-DES3-EDE-CBC (pbeWithSHAAnd3-KeyTripleDES-CBC) and SHA1-RC4-128 (pbeWithSHA1And128BitRC4); (the special mbedtls_pkcs12_pbe_sha1_rc4_128() is not used now and may be removed) 7.3) changed pkcs5 pbes2 support: added AES-128-CBC and AES-256-CBC ciphers Some «preview» is available at fork https://github.com/loafer-mka/mbedtls, branch ‘dev_clean’ Of course, many changes relate to obsolete formats, and may be undesirable … also I do not touch PSK at all. Please, give me some feedback — try to finish this with tests, pull request, etc or not. ----------- Regards, Andrey

5 years

1
0
0 0

session resumption and renegotiation queries

by hardik dave

Dear All, I am having multiple queries regarding session resumption and renegotiation. I understand that normally session resumption is used at every new connection and session renegotiation is used on live connection. Our domain standards recommends to use session resumption to change session key ( or keyblock key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random); ) at regular intervals without closing connection and session renegotiation to change master key at regular interval using session renegotiation. This is due to the fact that the connection will be long lasting. Query 1: I understand that mbedtls currently does not support session resumption on live connection. Is there any plan to include it in the near future? ( may be similar to openssl SSL_renegotiate_abbreviated api) Query 3: If the application wants to know if session renegotiation has happened as part of mbedtls_tls_read and mbedtls_tls_write, is there any callback/API for that? --> I am only thinking of using session->start comparison in application to know if session is renegotiated. Is there any better method? Query 4: Our requirement is to understand and log security event in case failure due to certificate verification fail (revoked/expired etc..) currently we use mbedtls_ssl_get_verify_result api for same There is a case when certificate becomes expired/revoked while doing session renegotiation, mbedtls_ssl_get_verify_result api returns value 0 in above case I am thinking in case of session renegotiation, a valid session will always be available (it will not be NULL in the method below) and session renegotiation failure information will be available with session_negotiate pointer instead of session pointer in the below function. uint32_t mbedtls_ssl_get_verify_result( const mbedtls_ssl_context *ssl ) { if( ssl->session != NULL ) return( ssl->session->verify_result ); if( ssl->session_negotiate != NULL ) return( ssl->session_negotiate->verify_result ); return( 0xFFFFFFFF ); } Am I using the right API to get certificate verify_result? should mbedtls_ssl_get_verify_result api checks give priority to session_negotiate then session? I think when there is a failure, the result will always be with session_negotiate, when success session_negotiate becomes NULL and session_negotiate pointers will be assigned to session pointers. uint32_t mbedtls_ssl_get_verify_result( const mbedtls_ssl_context *ssl ) { if( ssl->session_negotiate != NULL ) return( ssl->session_negotiate->verify_result ); if( ssl->session != NULL ) return( ssl->session->verify_result ); return( 0xFFFFFFFF ); } Kind request to guide me Thanks in advance Regards Hardik Dave

5 years

1
0
0 0

Re: [mbed-tls] mbedtls_ssl_set_bio hangs

by Ron Eggler

Yes, there's some kind of "memory magic" going on here: The task got terminated due to "Load from invalid memory" and I see: |Instruction at 0x6310604d is trying to load data at 0x4, which is an invalid memory area. You are probably dereferencing a NULL pointer.| |and i got some trace back addresses that point to:| * mbedtls_aes_crypt_ecb * mbedtls_ctr_drbg_random_with_add * mbedtls_ssl_handshake_step * mbedtls_ssl_handshake || On 2021-06-08 11:43 a.m., Gilles Peskine via mbed-tls wrote: > Hi Ron, > > This behavior can't be explained by the library code and the code you > posted alone. There has to be something wrong elsewhere. > > Check that you aren't exceeding a limitation such as the stack size or > the size of executable and data sections. If it can be an issue on your > platform, check that load addresses are correct and sections don't > overlap. Make sure there's no overlap with any device memory mapping either. > > Make sure that the whole binary is compiled with consistent settings. > The layout of mbedtls_ssl_context can be influenced by the Mbed TLS > configuration, so make sure that there's a single copy of > mbedtls/config.h and both Mbed TLS itself and your application were > built against that copy. The layout of mbedtls_ssl_context can also be > influenced by compiler settings on some platforms (e.g. structure > packing options), so make sure those are consistent across your build. > > That's all I can think of for now. It may help to add a lot of printf > debugging with %p on various addresses, and compare these addresses with > what you know about memory mappings on that platform. Good luck! >

5 years

1
0
0 0

Re: [mbed-tls] mbedtls_ssl_set_bio hangs

by Gilles Peskine

Hi Ron, This behavior can't be explained by the library code and the code you posted alone. There has to be something wrong elsewhere. Check that you aren't exceeding a limitation such as the stack size or the size of executable and data sections. If it can be an issue on your platform, check that load addresses are correct and sections don't overlap. Make sure there's no overlap with any device memory mapping either. Make sure that the whole binary is compiled with consistent settings. The layout of mbedtls_ssl_context can be influenced by the Mbed TLS configuration, so make sure that there's a single copy of mbedtls/config.h and both Mbed TLS itself and your application were built against that copy. The layout of mbedtls_ssl_context can also be influenced by compiler settings on some platforms (e.g. structure packing options), so make sure those are consistent across your build. That's all I can think of for now. It may help to add a lot of printf debugging with %p on various addresses, and compare these addresses with what you know about memory mappings on that platform. Good luck! -- Gilles Peskine Mbed TLS developer On 08/06/2021 19:16, Ron Eggler via mbed-tls wrote: > > On 2021-06-08 7:40 a.m., Ron Eggler via mbed-tls wrote: >> On 2021-06-08 12:28 a.m., Gilles Peskine via mbed-tls wrote: >>> Hi Ron, >>> >>> The code you've shown so far only consists of setup functions that >>> populate fields in the configuration structure, then in the context >>> structure. Communication has not started yet. mbedtls_ssl_set_bio in >>> particular is a very simple setter function. >>> >>> Where does the code actually hang? Have some messages already been >>> exchanged on the network at that point? Can you get a stack trace? >>> >>> Best regards, >>> >> Hi Gilles, >> >> Thank you for the response! >> >> I've inserted print statements after each of the setup functions and >> can see that it never gets past mbedtls_ssl_set_bio. The messages >> that have been exchanged, include the complete bring up and login of >> the control channel, on the data channel, I call >> mbedtls_x509_crt_init >> mbedtls_pk_init >> mbedtls_entropy_init >> mbedtls_ctr_drbg_init >> mbedtls_ssl_init >> mbedtls_ssl_config_init >> followed by the certificate and key file got parsing, seeding of the >> RNG and that's where the previously mentioned procedure with >> mbedtls_ssl_config_defaults() starts. >> I unfortunately do not have a debugger available on that platform and >> hence getting a stack trace won't be so straight forward. Do you have >> any pointers as to what could be the issue potentially? >> >> Thank you, >> >> Ron > > Okay, I've made some further findings: > > I changed the mbedtls_ssl_set_bio funmction so that I inserted a print > statement on entry and after every set line, like so: > > void mbedtls_ssl_set_bio( mbedtls_ssl_context *ssl, > void *p_bio, > mbedtls_ssl_send_t *f_send, > mbedtls_ssl_recv_t *f_recv, > mbedtls_ssl_recv_timeout_t *f_recv_timeout ) > { > iprintf("mbedtls_ssl_set_bio::entry\n"); > ssl->p_bio = p_bio; > iprintf("mbedtls_ssl_set_bio::p_bio set\n"); > ssl->f_send = f_send; > iprintf("mbedtls_ssl_set_bio::f_send set\n"); > ssl->f_recv = f_recv; > iprintf("mbedtls_ssl_set_bio::f_recv set\n"); > ssl->f_recv_timeout = f_recv_timeout; > iprintf("mbedtls_ssl_set_bio::f_recv_timeout set\n"); > } > > and turns out, that I only see the very first print on > "mbedtls_ssl_set_bio::entry\n" and nothing there after, which leads me > to the believe that my *ssl is invalid which is odd as that variable > is also used for ret = mbedtls_ssl_setup( &ssl_d, &conf_d ); and it is > initialized at the beginning of the function with mbedtls_ssl_init( > &ssl_d ); > >

5 years

1
0
0 0

Re: [mbed-tls] mbedtls_ssl_set_bio hangs

by Ron Eggler

On 2021-06-08 7:40 a.m., Ron Eggler via mbed-tls wrote: > On 2021-06-08 12:28 a.m., Gilles Peskine via mbed-tls wrote: >> Hi Ron, >> >> The code you've shown so far only consists of setup functions that >> populate fields in the configuration structure, then in the context >> structure. Communication has not started yet. mbedtls_ssl_set_bio in >> particular is a very simple setter function. >> >> Where does the code actually hang? Have some messages already been >> exchanged on the network at that point? Can you get a stack trace? >> >> Best regards, >> > Hi Gilles, > > Thank you for the response! > > I've inserted print statements after each of the setup functions and > can see that it never gets past mbedtls_ssl_set_bio. The messages that > have been exchanged, include the complete bring up and login of the > control channel, on the data channel, I call > mbedtls_x509_crt_init > mbedtls_pk_init > mbedtls_entropy_init > mbedtls_ctr_drbg_init > mbedtls_ssl_init > mbedtls_ssl_config_init > followed by the certificate and key file got parsing, seeding of the > RNG and that's where the previously mentioned procedure with > mbedtls_ssl_config_defaults() starts. > I unfortunately do not have a debugger available on that platform and > hence getting a stack trace won't be so straight forward. Do you have > any pointers as to what could be the issue potentially? > > Thank you, > > Ron Okay, I've made some further findings: I changed the mbedtls_ssl_set_bio funmction so that I inserted a print statement on entry and after every set line, like so: void mbedtls_ssl_set_bio( mbedtls_ssl_context *ssl, void *p_bio, mbedtls_ssl_send_t *f_send, mbedtls_ssl_recv_t *f_recv, mbedtls_ssl_recv_timeout_t *f_recv_timeout ) { iprintf("mbedtls_ssl_set_bio::entry\n"); ssl->p_bio = p_bio; iprintf("mbedtls_ssl_set_bio::p_bio set\n"); ssl->f_send = f_send; iprintf("mbedtls_ssl_set_bio::f_send set\n"); ssl->f_recv = f_recv; iprintf("mbedtls_ssl_set_bio::f_recv set\n"); ssl->f_recv_timeout = f_recv_timeout; iprintf("mbedtls_ssl_set_bio::f_recv_timeout set\n"); } and turns out, that I only see the very first print on "mbedtls_ssl_set_bio::entry\n" and nothing there after, which leads me to the believe that my *ssl is invalid which is odd as that variable is also used for ret = mbedtls_ssl_setup( &ssl_d, &conf_d ); and it is initialized at the beginning of the function with mbedtls_ssl_init( &ssl_d );

5 years

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls June 2021