- mbed-tls - lists.trustedfirmware.org

by Gilles Peskine

Hello, Mbed TLS supports building and running unit tests in one of two modes: “hosted” or “on target”. The on-target mode relies on Greentea, the Mbed OS test framework. The on-target mode is unmaintained (there's no CI for it and the Mbed TLS maintainers hardly ever even try to build it these days) and we're considering retiring it in Mbed TLS 2.28. If you do use Mbed TLS's on-target unit testing, either by building target_test.function or by plugging your own file instead of target_test.function or host_test.function, please let us know and weigh in on https://github.com/ARMmbed/mbedtls/issues/4912 <https://github.com/ARMmbed/mbedtls/issues/4912> . Best regards, -- Gilles Peskine Mbed TLS developer

4 years

1
1
0 0

How can I read plain-text private key into rsa_context?

by Shariful Alam

Hello, I'm using an older version of mbedtls (polarssl-1.3.9). I have a plain text private key generated from OpenSSL like the following. I'm trying to load this private key into the *rsa_context *using the following code (sorry, for the following code, I just don't know what to copy), Private key with padding (I have added padding manualy to make it divisible by 16 ) ================================================== // Total private key size is 4013 # define KEY_BUFFER_SIZE 4017 unsigned char private_decrypt[KEY_BUFFER_SIZE]; *printf("private key with padding --> \n %s \n", private_decrypt); --> shows the following* private key with padding --> RSA Private-Key: (2048 bit, 2 primes) modulus: 00:cc:40:c3:c6:e7:29:ae:f5:94:d8:3b:3f:a4:33: c2:6d:29:86:63:db:b7:8c:d4:07:f7:b3:db:96:83: f7:55:dd:6a:7b:04:49:53:3d:52:30:5f:af:0b:c2: b1:f0:48:a4:66:0a:b7:aa:29:b1:d0:91:4f:9c:1c: cf:df:5c:10:04:85:f9:bd:7b:93:ed:a6:77:80:12: 34:64:19:1a:18:b5:4e:94:7c:39:ce:99:38:50:e9: 82:71:f6:0f:3e:b8:af:11:3c:f4:05:69:72:8e:96: f6:81:ac:46:29:eb:88:88:c5:54:2f:89:1b:b9:32: da:76:23:a2:00:76:a5:8e:50:d3:ba:39:35:f9:4d: 95:63:ff:6a:3c:c8:a8:53:aa:78:d8:81:c8:bd:af: cf:6c:de:33:aa:c9:d4:80:2c:1f:ef:92:90:8a:c4: 88:e6:9a:e5:ad:2d:08:60:89:1a:77:fc:bf:68:64: 6f:c0:a7:fa:33:6d:ff:d2:e6:a4:7f:ad:87:be:0c: cb:9d:18:44:57:fe:db:86:7f:0b:c5:f7:9a:29:4b: 61:62:48:91:01:f7:e7:5e:64:4d:20:ec:ac:3c:07: 59:d6:19:f5:8c:01:9f:d5:6e:16:a8:8e:f9:2d:f6: f8:73:25:0a:b5:d8:62:2a:f8:ba:d5:dc:ff:6e:77: 0d:35 publicExponent: 65537 (0x10001) privateExponent: 4a:17:50:2d:2d:9b:5c:40:ef:3e:44:b7:c0:3b:9a: 52:78:d6:ac:10:7e:93:92:32:55:b3:23:7b:84:e1: 4a:7f:67:e9:b9:d3:53:63:92:15:c4:0f:be:47:60: be:95:cb:34:cc:bc:74:f8:6c:ed:08:59:05:7b:1a: 18:9e:cf:9c:a4:70:c4:40:38:97:e3:63:c3:cc:56: be:dc:b0:2f:b8:4d:09:e5:ca:1e:5c:4c:26:65:9e: 10:f2:bd:f2:f5:91:63:c2:65:8e:35:02:fe:20:5a: c9:0d:11:e2:90:f2:d5:12:27:88:9a:c6:b8:b6:6e: b2:9e:18:5c:ec:ac:ff:63:42:94:b3:b5:ff:69:75: f5:e9:41:77:8b:ee:1d:fa:47:78:9a:9c:1f:84:8b: 85:f9:29:a5:27:e4:1f:04:34:4e:ce:c2:28:18:38: 72:63:5c:44:88:4f:e2:ec:bc:c4:3e:af:d8:bb:a9: 0f:c9:30:0f:bf:bc:1d:8a:fc:d9:cf:27:f5:16:38: 34:07:3d:bf:a5:45:70:df:c5:8f:ee:79:3e:69:6e: e4:0c:74:76:f7:8a:2c:11:34:53:60:27:c3:73:55: 62:d5:06:cb:35:a4:3d:d6:79:3f:50:d4:81:7c:0f: 03:c5:15:b2:4a:eb:84:f1:16:07:ec:16:02:e4:5c: 1d prime1: 00:e5:40:6a:4c:8d:d3:8d:8d:e6:df:e7:1d:c4:8f: 4d:b4:b7:71:51:b7:c4:8a:19:fe:fd:3e:4b:a9:0b: d0:22:64:e0:76:f4:8b:88:d6:30:4b:f6:41:ae:20: c5:cc:79:ec:05:d0:6b:0e:64:16:c5:b5:e3:74:b6: a8:ac:39:74:1d:8a:09:b8:68:64:a4:c1:74:fa:f6: cd:1b:24:d6:86:1e:40:51:dc:09:78:76:8b:16:3e: f1:ea:a9:9b:25:69:4a:c4:3e:ba:63:62:6c:06:40: 83:8d:af:69:89:bd:ad:07:f4:97:39:7c:25:59:80: 07:59:4e:74:a0:4b:2a:05:67 prime2: 00:e4:15:a8:6a:e6:30:95:d6:36:44:a7:57:ac:99: d5:4d:d9:58:59:05:49:89:b8:42:cb:0e:e8:9d:12: fc:a4:76:e7:07:11:08:97:05:7d:0a:34:21:23:03: c9:4b:97:5c:6f:fc:7e:28:8a:c5:b1:44:12:61:03: 60:5e:f9:d2:51:cf:53:0f:7a:2f:a5:96:5a:f5:33: f7:6f:6e:92:14:cc:54:b1:48:ad:da:f7:37:c7:ca: 6f:a2:6a:00:de:73:6c:67:59:78:af:e9:ce:fb:02: 95:f8:0d:82:38:02:79:e5:a4:3b:61:16:b7:70:b1: 70:c8:9a:e8:81:c7:cb:fb:03 exponent1: 57:04:78:54:ce:90:ba:6e:5e:70:26:9d:d9:fa:3b: 18:99:78:dd:f7:cf:16:4c:7f:c9:48:58:17:b6:70: 2e:5d:f4:05:b3:15:33:bf:79:5d:9b:ff:9a:44:be: 4f:bb:07:a7:bd:50:a5:89:c0:4b:13:9b:5e:b5:e6: 98:58:c6:86:5f:db:08:b0:37:63:82:3b:10:f7:95: 2a:f4:74:a9:3b:da:56:38:1b:30:2a:6e:e8:e6:c3: 94:bb:04:34:d3:1e:9a:16:e5:50:cc:0f:0c:e0:78: 0e:d3:c2:4f:92:3b:97:85:73:d1:52:1a:2b:3a:b9: 8f:60:84:4c:43:bb:93:89 exponent2: 00:d7:ea:08:bc:e9:9c:24:bb:dc:33:b1:96:b5:b6: 0a:ce:df:69:5b:1c:3e:39:39:4d:41:9c:a3:67:ce: 89:8b:c7:63:7c:b5:0b:44:ab:d5:6a:cb:5e:73:1f: 2a:77:7c:99:ed:09:41:04:70:1a:25:6d:23:58:e3: 31:5f:b7:6e:fa:33:21:96:0d:3c:fd:ac:0f:fe:ff: 6a:c4:fa:0f:1f:d1:2e:7b:85:29:cf:97:28:1e:e1: ec:3b:fb:cd:46:c8:4d:5e:a8:bc:2f:0b:4e:fd:1f: bd:88:4c:81:71:34:26:e0:d5:4f:c0:e1:18:56:7e: 23:1e:44:46:c6:54:b5:2c:b1 coefficient: 2e:45:e5:0a:bc:66:bc:6e:9d:0d:ce:02:d6:30:62: 44:f6:38:d0:a7:2a:25:c4:42:76:cc:59:38:af:35: cb:6e:a7:5e:3c:71:97:6a:7b:c4:69:25:2e:c4:07: 20:2c:86:5c:a1:e8:6e:d8:e6:b7:9a:21:28:1e:8a: b1:4b:c5:ab:4e:35:e0:83:b5:30:56:53:d7:50:2f: 69:a2:6c:7b:00:d8:15:17:bb:79:72:33:30:11:47: 06:c5:58:16:63:e3:f5:ac:71:3d:ce:64:67:0e:6a: e0:cd:c2:e6:ad:30:f9:3e:7e:52:01:cf:fc:fc:66: 10:44:1a:4b:1b:08:7a:8d 000 <----- padding ============================================ Remove padding and get the actual private key using the the following code, ============================================================================= size_t lenght=strlen(private_decrypt); // length =4016 int N= lenght-4013; // 4013 is the original length of the private key, N is the length of padding private_decrypt[lenght-N]='\0'; // So, now *private_decrypt *contains the actual key ============================================================================= Then I use the following code to split each key and load into rsa_context, ===================================================================== char *strings[]={ "modulus:", "publicExponent:", "privateExponent:", "prime1:", "prime2:", "exponent1:", "exponent2:", "coefficient:"}; char* in = &private_decrypt; char *token; const char s[2] = " "; char *token_2; int k=0, size; do { if(k<8){ token = strstr(in,strings[k]); size= strlen(token); if (token){ *token = '\0'; } switch (k) { case 1: strcat(in,"\0"); printf("k=%d:\n %s\n",k,in); mpi_read_string(&rsaContext->N, 16, in); break; case 2: token_2 = strtok_r(in, s, &in); strcat(token_2,"\0"); printf("k=%d:\n %s\n",k,token_2); mpi_read_string(&rsaContext->E, 16, token_2); break; case 3: break; case 4: break; case 5: break; case 6: break; case 7: break; } //printf("k=%d \n%s\n",k,in); in = token+strlen(strings[k]); k=k+1; } else{ token= "NULL"; break; } }while(token!=NULL); // Check Public key if(rsa_check_pubkey(rsaContext)!=0){ printf("Reading public key error\n"); exit(0); } ===================================================================== Upon doing all this, when check the if the public key is load correctly or not, I'm getting *"Reading public key error". *Any help, what I'm doing wrong? Regards, Shariful Alam

4 years

1
0
0 0

How can I get plaintext rsa private key from .pem format?

by Shariful Alam

Hello, I found that, /programs/pkeyrsa_genkey.c creates a plaintext rsa private key. Is there any way I can generate the keys in the same format from a .pem format? Regards, Shariful Alam

4 years

1
0
0 0

-0x7880 "error" after successful failed download

by Ron Eggler

Hi, I'm getting the following errors printed: tls : error : [2021/06/21 21:43:12.360] [id = 10]: ../../src/../externals/mbedtls/mbedtls/library/ssl_tls.c(4369): mbedtls_ssl_handle_message_type() returned -30848 (-0x7880) tls : error : [2021/06/21 21:43:12.360] [id = 11]: ../../src/../externals/mbedtls/mbedtls/library/ssl_tls.c(8335): mbedtls_ssl_read_record() returned -30848 (-0x7880) after a file is successfully downloaded. It looks like MBEDTLS_ERR_SSL_PEER_CLOSE_NOTIFY gets interpreted and printed as error. How can I fix this? Is this a configuration thing or do I edit the ssl_tls.c source code? Thank you, Ron mbedtls 2.16.0

4 years

1
0
0 0

Re: [mbed-tls] FTPS: Bad Record Mac on login

by Ron Eggler

On 2021-08-16 11:11 a.m., Ron Eggler via mbed-tls wrote: > Hi, > > I am working on a client where I need to login to a FTPS server > (vsftpd). I establish the connection, exchange Hellos, certificate & > key exchange and all seems succesful and are happening fine. > > I am able to send "PBSZ 0" to the server which gets acknowledged with > "200 PBSZ set to 0." (as seen in Wireshark). > > Then, when it comes to sending "PROT P", I cannot see it encoded in > Wireshark. it just says "Application Data" and the next frame reads > "Alert (Level: Fatal, Description: Bad Record Mac)". I have > investigated my code (mostly for differences between "PBSZ 0" and > "PROT P" but came up empty) and have searched the web but have failed > to find the resolution to my problem, as of yet. It seems obvious that > the problem must be in my code but I seem to be unable to put my > finger on it! I thought I should check if someone here may have any > other hints that will help me resolve the problem. > > I have temporarily set "mbedtls_ssl_conf_authmode( &ctxt.conf, > MBEDTLS_SSL_VERIFY_NONE);" to make sure that the CA is not the causing > any issues. > I have been able to resolve this. It was caused by usage of different context structure pointers.

4 years

1
0
0 0

FTPS: Bad Record Mac on login

by Ron Eggler

Hi, I am working on a client where I need to login to a FTPS server (vsftpd). I establish the connection, exchange Hellos, certificate & key exchange and all seems succesful and are happening fine. I am able to send "PBSZ 0" to the server which gets acknowledged with "200 PBSZ set to 0." (as seen in Wireshark). Then, when it comes to sending "PROT P", I cannot see it encoded in Wireshark. it just says "Application Data" and the next frame reads "Alert (Level: Fatal, Description: Bad Record Mac)". I have investigated my code (mostly for differences between "PBSZ 0" and "PROT P" but came up empty) and have searched the web but have failed to find the resolution to my problem, as of yet. It seems obvious that the problem must be in my code but I seem to be unable to put my finger on it! I thought I should check if someone here may have any other hints that will help me resolve the problem. I have temporarily set "mbedtls_ssl_conf_authmode( &ctxt.conf, MBEDTLS_SSL_VERIFY_NONE);" to make sure that the CA is not the causing any issues. Thank you!

4 years, 1 month

1
0
0 0

record and no record delemma

by Dave Plater

Hi, I wonder if anyone can tell me what I'm doing wrong. I use a modified client1.c for getting payment objects from an aws address, curl says that the connection uses "SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256" if it's any use. I can retrieve any single payment object which has a content length of about 443 but when I try to get the entire record of payments of which I only need the first or latest payment to check that I'm in sync, I get "Last error was: -28928 - SSL - Bad input parameters to function". This started at a certain point in the payment object accumulation don't quite know when, the current record of all payments is 22526 and it grows with every transaction. The GET request for the all the payment objects ends in "/payments/" and for a single object /payments/ has the objects id appended to it. There must be a way to receive a truncated record of all payments. Here is my latest config.h: #ifndef MBEDTLS_CONFIG_H #define MBEDTLS_CONFIG_H /* System support */ //#define MBEDTLS_HAVE_ASM #define MBEDTLS_HAVE_TIME #define MBEDTLS_NO_PLATFORM_ENTROPY #define MBEDTLS_NO_DEFAULT_ENTROPY_SOURCES #define MBEDTLS_TEST_NULL_ENTROPY #define MBEDTLS_ERROR_C #define MBEDTLS_PLATFORM_C //#define MBEDTLS_PLATFORM_EXIT_ALT //#define MBEDTLS_PLATFORM_TIME_ALT //#define MBEDTLS_PLATFORM_FPRINTF_ALT //#define MBEDTLS_PLATFORM_PRINTF_ALT //#define MBEDTLS_PLATFORM_SNPRINTF_ALT //#define MBEDTLS_PLATFORM_VSNPRINTF_ALT //#define MBEDTLS_PLATFORM_NV_SEED_ALT //#define MBEDTLS_PLATFORM_SETUP_TEARDOWN_ALT /* mbed TLS feature support */ #define MBEDTLS_CIPHER_MODE_CBC #define MBEDTLS_PKCS1_V15 #define MBEDTLS_KEY_EXCHANGE_RSA_ENABLED #define MBEDTLS_SSL_PROTO_TLS1_2 #define MBEDTLS_SSL_CLI_C #define MBEDTLS_SSL_TLS_C #define MBEDTLS_ENTROPY_C #define MBEDTLS_NO_DEFAULT_ENTROPY_SOURCES //experiment #define MBEDTLS_KEY_EXCHANGE_RSA_ENABLED #define MBEDTLS_KEY_EXCHANGE_ECDHE_RSA_ENABLED #define MBEDTLS_ECDH_C #define MBEDTLS_ECP_C #define MBEDTLS_ECP_DP_SECP192R1_ENABLED #define MBEDTLS_RSA_C #define MBEDTLS_OID_C #define MBEDTLS_PKCS1_V15 #define MBEDTLS_X509_CRT_PARSE_C #define MBEDTLS_CIPHER_C #define MBEDTLS_MD_C #define MBEDTLS_BIGNUM_C #define MBEDTLS_SHA256_C #define MBEDTLS_PK_PARSE_C #define MBEDTLS_PK_C #define MBEDTLS_ASN1_PARSE_C /* mbed TLS modules */ #define MBEDTLS_AES_C /* #define MBEDTLS_ASN1_WRITE_C #define MBEDTLS_BIGNUM_C #define MBEDTLS_CIPHER_C #define MBEDTLS_CTR_DRBG_C #define MBEDTLS_DES_C #define MBEDTLS_MD_C #define MBEDTLS_MD5_C //#define MBEDTLS_RSA_C #define MBEDTLS_SHA1_C #define MBEDTLS_SHA256_C */ #define MBEDTLS_X509_USE_C /* For test certificates */ #define MBEDTLS_BASE64_C #define MBEDTLS_CERTS_C #define MBEDTLS_PEM_PARSE_C /* Limit memory use*/ #define MBEDTLS_SSL_MAX_CONTENT_LEN 16384 /* For testing with compat.sh */ //#define MBEDTLS_FS_IO #include "check_config.h" #endif /* MBEDTLS_CONFIG_H */ Thanks, Dave P

4 years, 1 month

1
0
0 0

Compare certs' RSA keys, subjects etc..

by Nassim Eddequiouaq

Hi, I'd like to compare a signing cert in a cert chain against a pinned cert. Given two mbedtls_x509_crt (or two mbedtls_rsa_context), what is the recommended way to compare them? Thanks! -- Nassim Eddequiouaq

4 years, 1 month

1
0
0 0

Re: [mbed-tls] Could memory leak or heap fragmentation be the issue?

by Gilles Peskine

Hello, I don't see anything obviously wrong with the code. Heap fragmentation is a possibility. A memory leak is also a possibility; we do fairly extensive testing for memory leaks in unit tests, but this doesn't catch unusual conditions (especially not recovering after a low-memory condition). I think the first tool to investigate is to enable MBEDTLS_MEMORY_DEBUG. This has a small cost in code size and gives you access to some introspection functions mbedtls_memory_buffer_alloc_status() and mbedtls_memory_buffer_alloc_max_get(). Call these functions on an error, and also perhaps at other times for comparison. There's also an option MBEDTLS_MEMORY_BACKTRACE which creates extremely verbose logs. Those logs might be helpful, but they're so verbose that they often aren't practical in a real-world application. I notice that the allocation is for a little over 16kB. The default size of the SSL input/output buffers is 16kB because that's the maximum size of a message according to the specification. However you can usually get away with a lot less, especially on IoT networks where the infrastructure is geared towards much smaller messages. See https://tls.mbed.org/kb/how-to/controlling_package_size <https://tls.mbed.org/kb/how-to/controlling_package_size> for more information on message sizes and buffer sizes. If the problem is a memory leak, smaller buffers will only delay the failure. But if the problem is that the application just needs a bit more heap space, this could solve the problem. Concretely, try setting MBEDTLS_SSL_IN_CONTENT_LEN and MBEDTLS_SSL_OUT_CONTENT_LEN in the compile-time configuration to much lower values. MBEDTLS_SSL_OUT_CONTENT_LEN can be as low as you like as long as the handshake messages fit. MBEDTLS_SSL_IN_CONTENT_LEN has to be large enough for the messages that you're sent. Alternatively, enable the option MBEDTLS_SSL_VARIABLE_BUFFER_LENGTH, which results in smaller buffers but can make fragmentation worse due to reallocations. Hope this helps. -- Gilles Peskine Mbed TLS developer On 01/08/2021 22:40, Alan Chen via mbed-tls wrote: > > I posted the question on the mbedTLS forum, only to realized that > mbedTLS is now maintained by the projectï¿½s mailing list. Here is the > copy of what I wrote: > > ï¿½ > > *Occasionally*ï¿½ I am getting MBEDTLS_ERR_SSL_ALLOC_FAILED from > mbedtls_ssl_setup() during repeated HTTP partial content download. > Since this problem happens very rarely, it is a bit difficult to > troubleshoot. > > ï¿½ > > I am running mbedTLS on a Microchip PIC32MZ MCU, connected to a > LTE-M/NB-IoT modem. I have 128K static memory reserved for the library > with MBEDTLS_PLATFORM_MEMORY defined in the config.h file. The MCU > runs two main tasks - MQTT client, talking to the AWS MQTT broker, and > HTTPS client, for downloading new firmware image from the AWS S3 > bucket over the air. > > ï¿½ > > Due to the slowness and limited bandwidth of the LTE-M and NB-IoT > technologies, the HTTP file download has to use the partial content > GET, basically 2KB per request, until all ~700KB of data are received. > During the course of the file download, one can see as many as 30 > disconnect and reconnect, and each time the TLS session would close > down and re-open once the cell network is established. Here are some > of my functions: > > ï¿½ > > ``` > > #define MBEDTLS_MAX_MEMORY_ALLOCATEDï¿½ï¿½ï¿½ (1024 * 128) > > static uint8_t tls_memory_buf[MBEDTLS_MAX_MEMORY_ALLOCATED]; > > ï¿½ > > // called in main() > > void mbedtls_mem_init(void) > > { > > ï¿½ï¿½ï¿½ mbedtls_memory_buffer_alloc_init(tls_memory_buf, sizeof > tls_memory_buf); > > } > > ï¿½ > > void HTTPS_TLS_CLOSE(void) > > { > > ï¿½ï¿½ï¿½ if (server_fd_https.fd != -1) > > ï¿½ï¿½ï¿½ {ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½mbedtls_entropy_free(&entropy_https); > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ mbedtls_x509_crt_free(&cacert_https); > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ mbedtls_ctr_drbg_free(&ctr_drbg_https); > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ mbedtls_ssl_config_free(&conf_https); > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ mbedtls_ssl_free(&ssl_https); > > ï¿½ > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ server_fd_https.fd = -1; > > ï¿½ï¿½ï¿½ } > > } > > ï¿½ > > bool HTTPS_TLS_OPEN(void) > > { > > ï¿½ï¿½ï¿½ int ret; > > ï¿½ï¿½ï¿½ const char *pers = "https_tls_wrapper"; > > ï¿½ > > ï¿½ > > ï¿½ï¿½ï¿½ server_fd_https.fd = 1; > > ï¿½ï¿½ï¿½ mbedtls_debug_set_threshold(1); > > ï¿½ > > ï¿½ï¿½ï¿½ mbedtls_ssl_init(&ssl_https); > > ï¿½ï¿½ï¿½ mbedtls_ssl_config_init(&conf_https); > > ï¿½ï¿½ï¿½ mbedtls_ctr_drbg_init(&ctr_drbg_https); > > ï¿½ï¿½ï¿½ mbedtls_x509_crt_init(&cacert_https); > > ï¿½ï¿½ï¿½ > > ï¿½ï¿½ï¿½ï¿½mbedtls_entropy_init(&entropy_https);ï¿½ï¿½ï¿½ > > ï¿½ï¿½ï¿½ï¿½mbedtls_entropy_add_source(&entropy_https, my_https_entropy, NULL, > sizeof my_https_random, MBEDTLS_ENTROPY_SOURCE_STRONG); > > ï¿½ï¿½ï¿½ > > ï¿½ï¿½ï¿½ï¿½ret = mbedtls_ctr_drbg_seed(&ctr_drbg_https, mbedtls_entropy_func, > &entropy_https, (const unsigned char *)pers, strlen(pers)); > > ï¿½ï¿½ï¿½ if (ret != 0) > > ï¿½ï¿½ï¿½ { > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ printf("%s: mbedtls_ctr_drbg_seed ERROR -0x%x\r\n", > __FUNCTION__, -ret); > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ return false; > > ï¿½ï¿½ï¿½ } > > ï¿½ > > ï¿½ï¿½ï¿½ ret = mbedtls_x509_crt_parse(&cacert_https, TRUSTED_ROOT_CA, > TRUSTED_ROOT_CA_SIZE); > > ï¿½ï¿½ï¿½ if (ret != 0) > > ï¿½ï¿½ï¿½ { > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ printf("%s: mbedtls_x509_crt_parse cacert ERROR -0x%x\r\n", > __FUNCTION__, -ret); > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ return false; > > ï¿½ï¿½ï¿½ } > > ï¿½ï¿½ï¿½ > > ï¿½ï¿½ï¿½ï¿½ret = mbedtls_ssl_config_defaults(&conf_https, > MBEDTLS_SSL_IS_CLIENT, MBEDTLS_SSL_TRANSPORT_STREAM, > MBEDTLS_SSL_PRESET_DEFAULT); > > ï¿½ï¿½ï¿½ if (ret != 0) > > ï¿½ï¿½ï¿½ { > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ printf("%s: mbedtls_ssl_config_defaults ERROR -0x%x\r\n", > __FUNCTION__, -ret); > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ return false; > > ï¿½ï¿½ï¿½ } > > ï¿½ > > ï¿½ï¿½ï¿½ mbedtls_ssl_conf_verify(&conf_https, NULL, NULL); > > ï¿½ï¿½ï¿½ mbedtls_ssl_conf_authmode(&conf_https, MBEDTLS_SSL_VERIFY_REQUIRED); > > ï¿½ï¿½ï¿½ mbedtls_ssl_conf_rng(&conf_https, mbedtls_ctr_drbg_random, > &ctr_drbg_https); > > ï¿½ï¿½ï¿½ mbedtls_ssl_conf_dbg(&conf_https, my_https_debug, stdout); > > ï¿½ï¿½ï¿½ mbedtls_ssl_conf_ca_chain(&conf_https, &cacert_https, NULL); > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > > ï¿½ï¿½ï¿½ï¿½mbedtls_ssl_conf_read_timeout(&conf_https, TLS_TIMEOUT_MS); > > ï¿½ > > ï¿½ï¿½ï¿½ HTTPS_SetHostname(); /* calling mbedtls_ssl_set_hostname */ > > ï¿½ï¿½ï¿½ > > ï¿½ï¿½ï¿½ï¿½ret = mbedtls_ssl_setup(&ssl_https, &conf_https); > > ï¿½ï¿½ï¿½ if (ret != 0) > > ï¿½ï¿½ï¿½ { > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ printf("%s: mbedtls_ssl_setup ERROR -0x%x\r\n", __FUNCTION__, > -ret); > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ return false; > > ï¿½ï¿½ï¿½ } > > ï¿½ > > ï¿½ï¿½ï¿½ mbedtls_ssl_set_bio(&ssl_https, &server_fd_https, > mbedtls_https_send, mbedtls_https_recv, NULL); > > ï¿½ > > ï¿½ï¿½ï¿½ return true; > > } > > ``` > > Can someone please tell me if I am doing something inappropriate here? > I am speculating that perhaps there is a memory leak or the heap > becomes so fragmented that it fails on mbedtls_calloc(). The exact > error message in my case is: > > ï¿½ > > > ../mbedtls_lib/ssl_tls.c:5661: alloc(16717 bytes) failed > > ï¿½ > > Thanks. > > ï¿½ > > Alan Chen > > > > ------------------------------------------------------------------------ > <https://home.mcafee.com/utm_medium=email&utm_source=link&utm_campaign=sig-e…> > Scanned by McAfee > <https://home.mcafee.com/utm_medium=email&utm_source=link&utm_campaign=sig-e…> > and confirmed virus-free. > >

4 years, 1 month

1
0
0 0

R: Re: Mbed TLS: long term support versions

by matteo.cogi＠alice.it

Hi Dave and Gilles, Perfect, so I will wait for the last 2.x (presumably the 2.28.x) strand of the version later this year. Thanks again. Regards, Matteo ------ Messaggio Originale ------ Da: mbed-tls(a)lists.trustedfirmware.org A: Gilles.Peskine(a)arm.com; mbed-tls(a)lists.trustedfirmware.org Inviato: giovedì 29 luglio 2021 15:33 Oggetto: Re: [mbed-tls] Mbed TLS: long term support versions Sorry, just realised that myself! Gilles is correct, I should have said 2.28. Thanks Dave On 29/07/2021, 14:25, "mbed-tls on behalf of Gilles Peskine via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote: Off-by-one error! The current 2.x release is 2.27.0. Most development work is happening on 3.x but there will be at least one more 2.x release: 2.28.0. The last 2.x release will become an LTS. -- Gilles Peskine Mbed TLS developer On 29/07/2021 15:05, Dave Rodgman via mbed-tls wrote: > > Hi Matteo, > > > > We expect to release an LTS later this year. It’s likely to be 2.27, > and very likely will be supported for the usual LTS period of 3 years. > > > > So if you are considering updating to a new LTS, you could use 2.26 > for prototyping in the short term until the LTS becomes available. The > upcoming LTS will be API-compatible with 2.26. > > > > Hope this helps, > > > > Dave > > > > *From: *mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on > behalf of "matteo.cogi--- via mbed-tls" > <mbed-tls(a)lists.trustedfirmware.org> > *Reply to: *"matteo.cogi(a)alice.it" <matteo.cogi(a)alice.it> > *Date: *Tuesday, 27 July 2021 at 07:44 > *To: *"mbed-tls(a)lists.trustedfirmware.org" > <mbed-tls(a)lists.trustedfirmware.org> > *Subject: *[mbed-tls] Mbed TLS: long term support versions > > > > Dear all, > I wish to know which are the future LTS (Long Term Support) versions > for Mbed TLS. > In these last years I have been working with the 2.16.x, but I read it > will be maintained until at least the end of 2021 ( > https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra… > <https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra…> > ), so I am considering an update to a newer LTS version. > However I don’t find which are the next LTS version and for how much > time they will be maintained. > Thanks in advance. > Regards, > Matteo > > -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

4 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls