- mbed-tls - lists.trustedfirmware.org

Re: [mbed-tls] Link error when calling "altcp_tls_create_config_client"

by songwei.fu＠web.de

6 years

1
0
0 0

Re: [mbed-tls] Link error when calling "altcp_tls_create_config_client"

by Janos Follath

Hi Songwei, Welcome to the list and thank you for your interest in Mbed TLS! I found a similar issue on stack overflow: https://stackoverflow.com/questions/28895703/sbrk-function-not-found-when-p… Is this the same issue as yours? Regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of songwei fu via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: "songwei.fu(a)web.de" <songwei.fu(a)web.de> Date: Wednesday, 17 June 2020 at 10:49 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Link error when calling "altcp_tls_create_config_client" Hi guys, I am new to the list and also to mbedTLS. Now I am trying to port mbedTLS to chibiOS. And when I called altcp_tls_create_config_client(cert, sizeof(cert)), I got a link error like following: c:/chibistudio/tools/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m\libg.a(lib_a-sbrkr.o): In function `_sbrk_r': sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk' And these are my settings: #define MBEDTLS_PLATFORM_C #define MBEDTLS_PLATFORM_MEMORY #define MBEDTLS_PLATFORM_CALLOC_MACRO chHeapAlloc #define MBEDTLS_PLATFORM_FREE_MACRO chHeapFree where chHeapAlloc and chHeapFree are the memory allocation functions from chibios. (1) Did I miss some settings? or i did something wrong? (2) I did not find much information about the porting from chibios side. Does anybody know where I can look for reference projects/docs? Any suggestion will be appreciated. Thanks. Songwei

6 years

1
0
0 0

Link error when calling "altcp_tls_create_config_client"

by songwei.fu＠web.de

6 years

1
0
0 0

mbedtls_ssh_handshake error -0X50 when connecting to AWS

by Srinivasa Rao Ragolu

Hi All, I am working on Renesas RZA2M embedded board with Linux. It has limited memory of 6MB flash(R-Only) I am using mbedtls version 2.16.5 for aws iot sdk for embedded c according to https://docs.aws.amazon.com/iot/latest/developerguide/iot-embedded-c-sdk.ht… When I run sample application, it is taking 15 secs for "Seeding random generator number..." and throwing below error $ ./subscribe_publish_sample AWS IoT SDK Version 3.0.1- DEBUG: main L#159 rootCA /root/../certs/AmazonRootCA1.pem DEBUG: main L#160 clientCRT /root/../certs/774a17950a-certificate.pem.crt DEBUG: main L#161 clientKey /root/../certs/774a17950a-private.pem.key Connecting... DEBUG: iot_tls_connect L#130 . Seeding the random number generator... DEBUG: iot_tls_connect L#138 . Loading the CA root certificate ... DEBUG: iot_tls_connect L#144 ok (0 skipped) DEBUG: iot_tls_connect L#146 . Loading the client cert. and key... DEBUG: iot_tls_connect L#159 ok DEBUG: iot_tls_connect L#161 . Connecting to a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com/443... DEBUG: iot_tls_connect L#180 ok DEBUG: iot_tls_connect L#182 . Setting up the SSL/TLS structure... DEBUG: iot_tls_connect L#223 SSL state connect : 0 DEBUG: iot_tls_connect L#226 ok DEBUG: iot_tls_connect L#228 SSL state connect : 0 DEBUG: iot_tls_connect L#229 . Performing the SSL/TLS handshake... ERROR: iot_tls_connect L#232 failed ! mbedtls_ssl_handshake returned -0x50 ERROR: main L#190 Error(-4) connecting to a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com:443 For detailed debug log using ssl_client2, go through https://pastebin.com/mNXhB0xj<https://github.com/ARMmbed/mbedtls/issues/url> https://pastebin.com/mNXhB0xj my client device specifications $ cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 1 (v7l) BogoMIPS : 1056.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x4 CPU part : 0xc09 CPU revision : 1 Hardware : Generic R7S9210 (Flattened Device Tree) Revision : 0000 Serial : 0000000000000000 $ free total used free shared buffers cached Mem: 7544 4484 3060 40 0 304 -/+ buffers/cache: 4180 3364 Swap: 0 0 0 I am not getting any help to resolve this issue and spending days and days. I am suspecting the issue might be timing related (or) cpu clock related (or) memory footprint related (or) something else I need this forum help badly to resolve the issue. Please ping me if you need any other data. Thanks in advance, Srinivas. Regards, Srinivas. [cid:1eddf249-06f8-4cbd-a3e2-9c22437fd27f]

6 years, 1 month

1
0
0 0

BLE and Mbed TLS

by Fatima, Fariya

Hi, I wanted to use TLS over BLE application. When I googled, I figured out that MbedTLS can work on BLE. If someone can share a sample application where-in MbedTLS APIs are used as part of a BT/BLE application, it will be of great help. Regards, Fariya

6 years, 1 month

1
0
0 0

ASIO and mbed TLS

by Frank Bergmann

Hi, we have an application which uses ASIO. And now we want to add mbed TLS to provide a TLS layer. ASIO can be used with OpenSSL and wolfSSL. But how to do this with mbed TLS? Any hints on that? See also this question at SO: https://stackoverflow.com/questions/61875404/asio-c-with-mbed-tls-library best regards, Frank

6 years, 1 month

1
0
0 0

DTLS handshake never ends successfully

by Xavier Del Campo Romero

I want to connect an ESP32 to a DTLS server using mbedtls' dtls_server demo. The code I used for the client is very similar to the dtls_client example, but is unable to finish the handshake process for some reason. According to Wireshark, the client is not responding to the "Server hello done" frame, causing a timeout that makes the server to send the certificate again and again until it gives up the connection. The dtls_client demo works correctly on the computer, but not on the ESP32. Has anyone tested DTLS on the ESP32? I have attached the following files for further reference: - dtls_esp32.pcapng: Wireshark file with the DTLS packets between client and server. - mbedtls.tar.bz2: compressed (> 7k lines) plain text log as reported by the board. On line 7131, where the last message from the server is received, it looks like the client never receives the whole message, so it never reaches the "Server hello done" state. Could anyone please confirm this? - dtls.c: client source code. Slightly modified from the dtls_client example. Thank you very much for your help. Xavi

6 years, 1 month

1
0
0 0

Re: [mbed-tls] Feedback sought on a new PSA Crypto driver interface

by Quach, Brian

Hi, I was reviewing the proposal and had a few questions on usage of the new params. 1) When using plaintext keys, is the "attributes" param unused and should/could it be set to NULL? 2) If using key store (i.e. opaque), is the key ID the only attribute field which needs to be set? My assumption is attributes would be populated from the key store using the key ID? 3) If using key store, are the "key_buffer" and "key_buffer_size" params typically unused (i.e. can be set to null and zero respectively)? I do the proposal says the buffer content is up to the driver. Are there any usage cases in mind? 4) For drivers that support both opaque and transparent operation, which param would be used to determine the mode? (I had assumed key ID = 0 would be transparent, and non-zero is opaque) I'm unclear how persistent_state for opaque driver's is used. Could you elaborate on how it's used by the driver and core and why it isn't needed for transparent drivers? Key management with opaque drivers Transparent drivers may provide the following key management functions: Should this be "Opaque"? Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

6 years, 1 month

1
0
0 0

Re: [mbed-tls] mbedtls_x509write_crt_set_subject_name, mbedtls_x509_dn_gets fail to handle UTF8 multibyte properly

by Martin Man

> On 11 Jun 2020, at 12:09, Gilles Peskine via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> wrote: > > On 11/06/2020 11:24, Martin Man via mbed-tls wrote: >> >> I think this is a bug and the dn_gets should simply leave the UTF-8 >> multibyte untouched when parsing it out from a field tagged with ASN.1 >> tag 12 (utf-8). > > We are not going to do Unicode normalization in Mbed TLS: that would be > far too complex for a library that runs on systems with ~1e5 bytes > available for code. So Unicode strings would only be processed correctly > if the application passes normalized strings and CAs only generate > certificates with normalized strings. But that would be an improvement > on converting non-ASCII characters to '?'. Definitely agree that normalization is not needed. I think this problem could be split into two parts: 1) When a const char* is passed into mbedtls_x509write_crt_set_subject_name, the mbedtls will currently encode it into ASN tag 12 UTF8. Not sure what validation is done. But it could perhaps do at least a basic validation of what the C string passed in is to avoid generating a cert with crippled DN. Alternatively you can simply trust the developer to pass in correct UTF8 and document this. This is a API design decision of what input is allowed to be passed into the method and what validation is done on this. 2) When the mbedtls_x509_dn_gets extracts a C string from the ASN.1 tagged as 12, it could validate that it is indeed valid UTF-8, or just leave it as is and push it out. Again, this is about what we expect the library to do. I’m not an expert on whether this can in any way be used to trick MBEDLTS to do bad things when sending in a malformed certificate, say a one where DN is encoded as UTF-8 but contains illegal UTF-8 in the payload. thanks for listening, Martin

6 years, 1 month

1
0
0 0

Re: [mbed-tls] mbedtls_x509write_crt_set_subject_name, mbedtls_x509_dn_gets fail to handle UTF8 multibyte properly

by Gilles Peskine

On 11/06/2020 11:24, Martin Man via mbed-tls wrote: > The code in mbedtls_x509_dn_gets fails to properly handle the UTF-8 > multibyte sequence 0xe2 0x80 0x99 and turns it into 0xe2 0x80 0x3f. > > There is a fix floating around development branch mentioned > here https://github.com/ARMmbed/mbedtls/pull/3326/files which > essentially replaces all control chars with question marks. > > I think this is a bug and the dn_gets should simply leave the UTF-8 > multibyte untouched when parsing it out from a field tagged with ASN.1 > tag 12 (utf-8). That code is from an earlier era (mid 2000s, I think) when most systems used an 8-bit encoding, but non-8-bit-clean systems were still common. A '\x80' in text might be transformed to '\x00' with disastrous consequences. But over a decade later, I don't think non-8-bit-clean systems are a concern anymore. Leaving all non-ASCII characters alone sounds reasonable to me. We are not going to do Unicode normalization in Mbed TLS: that would be far too complex for a library that runs on systems with ~1e5 bytes available for code. So Unicode strings would only be processed correctly if the application passes normalized strings and CAs only generate certificates with normalized strings. But that would be an improvement on converting non-ASCII characters to '?'. -- Gilles Peskine Mbed TLS developer

6 years, 1 month

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls