- mbed-tls - lists.trustedfirmware.org

by Shebu Varghese Kuriakose

Hi David, Archive can be found here https://lists.trustedfirmware.org/pipermail/mbed-tls/ https://lists.trustedfirmware.org/pipermail/psa-crypto/ Regards, Shebu -----Original Message----- From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of David Higton via mbed-tls Sent: Friday, June 25, 2021 2:51 PM To: mbed-tls(a)lists.trustedfirmware.org Subject: [mbed-tls] List archive? Hi everybody, I've just joined the list. The first thing I did was to try to find an archive of list postings, but I haven't found one. Is there one, and, if so, where do I find it? The information may have been staring me in the face; if that's the case, I apologise. David -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

4 years

1
1
0 0

List archive?

by David Higton

Hi everybody, I've just joined the list. The first thing I did was to try to find an archive of list postings, but I haven't found one. Is there one, and, if so, where do I find it? The information may have been staring me in the face; if that's the case, I apologise. David

4 years

1
0
0 0

Re: [mbed-tls] Is TCP integrated in mbed-TLS?

by Janos Follath

Hi Anasasija, Mbed TLS is entirely agnostic of the communication channel or protocol. You can configure it to use any underlying layer, like TCP, UDP or even just a local buffer. That said, we have a module that makes it more convenient to use Mbed TLS with TCP (or UDP) on common platforms: https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/net_soc… You can see an example for using the module in several sample applications, for example: https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_client… and https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_server… Kind regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of 1637062--- via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Date: Friday, 25 June 2021 at 09:27 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Is TCP integrated in mbed-TLS? Hello, I am a Student and for my bachelor thesis I am working on a tool that is able to detect whether a server is vulnerable regarding Bleichenbacher's attack or not, testing multiple side channels. For this I am looking for a TLS implementation that has the TCP protocol integrated and generates the TCP messages. I was wondering if mbed-tls has the TCP integrated in the implementation or not. If so, I could make use of this information, too. Thanks and kind regards, Anastasija -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

4 years

1
0
0 0

Re: [mbed-tls] mbed-tls Digest, Vol 16, Issue 12

by Janos Follath

Hi Lijin, It still can be the endianness of the keys. If the key is reversed, there won’t be any discernible pattern or relationship between the derived secrets. Regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of T V LIJIN (EXT) via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Date: Friday, 25 June 2021 at 09:15 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] mbed-tls Digest, Vol 16, Issue 12 Hello, We couldn't see word swap in the output from both the end. Issue doesn't look related to the endianness. Could you please confirm that the code used for ECDHE key exchange is proper? SHARED_SECRET (Computed on Client): 11 36 F7 DB 2B 14 BB 86 1C A0 FC DF 6D 4D 17 70 BE 4F D8 58 C2 11 67 10 42 D7 47 EB 14 4B 10 5E SHARED_SECRET(Computed on Sever): c6 96 d9 f0 ec 37 be 9e 1a 60 a4 5f 88 f2 13 d3 bb 98 15 3f 3b d9 81 37 c6 10 12 85 e5 8b 49 16 Thanks, LIJIN T V ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of mbed-tls-request(a)lists.trustedfirmware.org <mbed-tls-request(a)lists.trustedfirmware.org> Sent: Friday, June 25, 2021 4:52 AM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: mbed-tls Digest, Vol 16, Issue 12 This message is from an external sender. Be cautious, especially with links and attachments. Send mbed-tls mailing list submissions to mbed-tls(a)lists.trustedfirmware.org To subscribe or unsubscribe via the World Wide Web, visit https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… 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. ECDHE Shared Secret is computed differently (T V LIJIN (EXT)) 2. Re: ECDHE Shared Secret is computed differently (Brian D.) 3. How does the bignum.c works? (Shariful Alam) ---------------------------------------------------------------------- Message: 1 Date: Thu, 24 Jun 2021 13:35:03 +0000 From: "T V LIJIN (EXT)" <lijin.tv(a)kone.com> To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] ECDHE Shared Secret is computed differently Message-ID: <AS8PR07MB8006A77D2451AD93FAFDA3D8FE079(a)AS8PR07MB8006.eurprd07.prod.outlook.com> Content-Type: text/plain; charset="iso-8859-1" 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

4 years

1
0
0 0

Is TCP integrated in mbed-TLS?

by 1637062＠uni-wuppertal.de

Hello, I am a Student and for my bachelor thesis I am working on a tool that is able to detect whether a server is vulnerable regarding Bleichenbacher's attack or not, testing multiple side channels. For this I am looking for a TLS implementation that has the TCP protocol integrated and generates the TCP messages. I was wondering if mbed-tls has the TCP integrated in the implementation or not. If so, I could make use of this information, too. Thanks and kind regards, Anastasija

4 years

1
0
0 0

Re: [mbed-tls] mbed-tls Digest, Vol 16, Issue 12

by T V LIJIN (EXT)

Hello, We couldn't see word swap in the output from both the end. Issue doesn't look related to the endianness. Could you please confirm that the code used for ECDHE key exchange is proper? SHARED_SECRET (Computed on Client): 11 36 F7 DB 2B 14 BB 86 1C A0 FC DF 6D 4D 17 70 BE 4F D8 58 C2 11 67 10 42 D7 47 EB 14 4B 10 5E SHARED_SECRET(Computed on Sever): c6 96 d9 f0 ec 37 be 9e 1a 60 a4 5f 88 f2 13 d3 bb 98 15 3f 3b d9 81 37 c6 10 12 85 e5 8b 49 16 Thanks, LIJIN T V ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of mbed-tls-request(a)lists.trustedfirmware.org <mbed-tls-request(a)lists.trustedfirmware.org> Sent: Friday, June 25, 2021 4:52 AM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: mbed-tls Digest, Vol 16, Issue 12 This message is from an external sender. Be cautious, especially with links and attachments. Send mbed-tls mailing list submissions to mbed-tls(a)lists.trustedfirmware.org To subscribe or unsubscribe via the World Wide Web, visit https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… 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. ECDHE Shared Secret is computed differently (T V LIJIN (EXT)) 2. Re: ECDHE Shared Secret is computed differently (Brian D.) 3. How does the bignum.c works? (Shariful Alam) ---------------------------------------------------------------------- Message: 1 Date: Thu, 24 Jun 2021 13:35:03 +0000 From: "T V LIJIN (EXT)" <lijin.tv(a)kone.com> To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] ECDHE Shared Secret is computed differently Message-ID: <AS8PR07MB8006A77D2451AD93FAFDA3D8FE079(a)AS8PR07MB8006.eurprd07.prod.outlook.com> Content-Type: text/plain; charset="iso-8859-1" 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

4 years

1
0
0 0

How does the bignum.c works?

by Shariful Alam

Hello, Can someone please briefly explain how does the bignum.c library works in terms of RSA? I understand that this is too broad a question to ask. but If someone can briefly explain the basic working mechanism it will be a great help. Thanks, Shariful

4 years

1
0
0 0

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 >

4 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

4 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 > >

4 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls