- mbed-tls - lists.trustedfirmware.org

by Work Only

I recently updated an embedded HTTPs web service using mbedtls from 2.22.0 to 3.2.1, and noticed the performance is about 30% better/faster. This is good for sure, but I am curious, what are the changes contributing to this improvement? Thanks!

2 weeks

2
2
0 0

MbedTLS 3.6.0 Compilation Error

by Satya Prakash Prasad

Hi, It seems that in latest MbedTLS 3.6.0 following declarations have been deleted: MBEDTLS_ERR_SSL_CERTIFICATE_REQUIRED MBEDTLS_ERR_SSL_PEER_VERIFY_FAILED The below function implementation is not there mbedtls_ssl_conf_export_keys_ext_cb Regards, Prakash

2 weeks, 2 days

1
1
0 0

MbedTLS 3.6.0 Compilation Error

by Satya Prakash Prasad

Hi, We are trying to compile the MBedTLS 3.6.0 version using nios2-elf-gcc compiler for an embedded product. We are receiving following compilation error- Compiling /mbedtls/library/platform_util.c ---------------------------------------------------- mbedtls/library/platform_util.c:261:2: #error "No mbedtls_ms_time available" Makefile:622: recipe for target '.mbedtls/library/platform_util.o' failed make: *** [mbedtls/library/platform_util.o] Error 1 I see the code in platform_util.c [snapshot below] - we have enabled MBEDTLS_HAVE_TIME and not MBEDTLS_PLATFORM_MS_TIME_ALT #if defined(MBEDTLS_HAVE_TIME) && !defined(MBEDTLS_PLATFORM_MS_TIME_ALT) #include <time.h> #if !defined(_WIN32) && \ // Note - Since we are compiling for embedded device this block gets disabled (defined(unix) || defined(__unix) || defined(__unix__) || \ (defined(__APPLE__) && defined(__MACH__)) || defined(__HAIKU__) || defined(__midipix__)) #include <unistd.h> #endif \ /* !_WIN32 && (unix || __unix || __unix__ || (__APPLE__ && __MACH__) || __HAIKU__ || __midipix__) */ #if (defined(_POSIX_VERSION) && _POSIX_VERSION >= 199309L) || defined(__HAIKU__) //// Note - Since we are compiling for embedded device this block gets disabled mbedtls_ms_time_t mbedtls_ms_time(void) { int ret; struct timespec tv; mbedtls_ms_time_t current_ms; #if defined(__linux__) && defined(CLOCK_BOOTTIME) || defined(__midipix__) ret = clock_gettime(CLOCK_BOOTTIME, &tv); #else ret = clock_gettime(CLOCK_MONOTONIC, &tv); #endif if (ret) { return time(NULL) * 1000; } current_ms = tv.tv_sec; return current_ms*1000 + tv.tv_nsec / 1000000; } #elif defined(_WIN32) || defined(WIN32) || defined(__CYGWIN__) || \ // Note - Since we are compiling for embedded device this block gets disabled defined(__MINGW32__) || defined(_WIN64) #include <windows.h> mbedtls_ms_time_t mbedtls_ms_time(void) { FILETIME ct; mbedtls_ms_time_t current_ms; GetSystemTimeAsFileTime(&ct); current_ms = ((mbedtls_ms_time_t) ct.dwLowDateTime + ((mbedtls_ms_time_t) (ct.dwHighDateTime) << 32LL))/10000; return current_ms; } #else #error "No mbedtls_ms_time available" //--> compilation error propagated from here #endif Regards, Prakash

2 weeks, 2 days

1
0
0 0

Generate a self-signed trusted certificate for server / client

by Satya Prakash Prasad

Hi, Referring to https://mbed-tls.readthedocs.io/en/latest/kb/how-to/generate-a-self-signed-… I am trying to create mutual certificates for server / client self signed certificates. As I derive from the web page the following steps need to be followed: Generic gen_key type=rsa rsa_keysize=2048 filename=ca.key format=pem cert_write selfsign=1 issuer_key=ca.key issuer_name=CN=myserver,O=myorganization,C=NL not_before=20130101000000 not_after=20251231235959 is_ca=1 max_pathlen=0 output_file=my_crt.crt Server Side: What steps to do to create the following files where server.crt is server side certificate, sever.key is the server private key and trusted.pem is the CA that it trusts. server.crt, server.key, trusted.pem[trusted.pem==>is it my_crt.crt] Do we need to create new server keys and certificates then do we need to bundle them - I am not sure how and what steps to do? Client Side What steps to do to create the following file where client.crt is client side certificate, client.key is the client private key and trusted.pem is the CA that it trusts. client.crt, client.key, trusted.pem[trusted.pem==>is it my_crt.crt] Do we need to create new client keys and certificates then do we need to bundle them - I am not sure how and what steps to do? Objective: Objective is that client and server should be able to connect securely successfully using their certs Request to provide help related to the generation of self-signed client / server certs that can be used for SSL handshake using MBedTLS library. Regards, Prakash

2 weeks, 3 days

1
0
0 0

Support SM2, SM3, SM4

by Zhi Liu

Hi all, Given TLS 1.3 has added two new cipher suites in RFC 8998 ( https://datatracker.ietf.org/doc/html/rfc8998), it would be useful to add these algorithms and ciphersuites in Mbedtls. CipherSuite TLS_SM4_GCM_SM3 = { 0x00, 0xC6 }; CipherSuite TLS_SM4_CCM_SM3 = { 0x00, 0xC7 }; There are some posts in this topic, https://github.com/Mbed-TLS/mbedtls/pull/4091, https://github.com/Mbed-TLS/mbedtls/pull/1620. But SM2/3/4 have not been added in recent versions(e.g., 3.6). I have implemented SM3, SM4 as standalone code( https://github.com/zliucd/cryptoshark), and want to port the code to Mbedtls while supporting SM2. However, to fully support the two new cipher suites, we need to add lots of other code. The first step is to add SM2, SM3 and SM as standalone ciphers. Thanks for any comments. Zhi

2 weeks, 4 days

1
0
0 0

EAP TLS - TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Unknown CA)

by Satya Prakash Prasad

Hi, I am not sure if this questions should be addressed to this support team but in hope that some positive information might come up. I am trying to analyze an SSL handshake failure issue. Based on the issue please find below steps to create client / server certificates. : openssl genrsa -out ca.key 2048 openssl req -new -x509 -days 1826 -key ca.key -out ca.crt openssl genrsa -out server.key 2048 openssl req -new -out server.csr -key server.key openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 360 At this step I have below files: ca.crt (which I use as trusted_client.pem), server.crt and server.key at server side Client Side certificate generation: openssl genrsa -out client.key 2048 openssl req -out client.csr -key client.key -new openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 360 So now at client side I have below files: client.crt client.key trusted_client.pem [generated during Server certificate step] I am not sure if I have generated the certificates correctly - but I am trying to test a Mutual trusted Server / Client SSL connection. So there is no certificate chain I have made during their certificate creation - they are self-signed ones. Note that when asked about the CN I gave "CA" (for CA), "example.com" (for server) and "client" (for client). When I run the flow I get below error: TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Unknown CA) Wireshark logs: 103 2024-04-01 11:17:42.886627 Device_00:8c:94 Nearest-non-TPMR-bridge EAPOL 60 Start 104 2024-04-01 11:17:42.887165 MS-NLB-PhysServer-17_11:11:11:11 Nearest-non-TPMR-bridge EAP 60 Request, Identity 105 2024-04-01 11:17:45.890174 MS-NLB-PhysServer-17_11:11:11:11 Nearest-non-TPMR-bridge EAP 60 Request, Identity 106 2024-04-01 11:17:45.892093 Device_00:8c:94 Nearest-non-TPMR-bridge EAP 60 Response, Identity 107 2024-04-01 11:17:45.892425 MS-NLB-PhysServer-17_11:11:11:11 Nearest-non-TPMR-bridge EAP 60 Request, TLS EAP (EAP-TLS) 108 2024-04-01 11:17:47.732072 Device_00:8c:94 Nearest-non-TPMR-bridge TLSv1.2 226 Client Hello 109 2024-04-01 11:17:47.746814 MS-NLB-PhysServer-17_11:11:11:11 Nearest-non-TPMR-bridge EAP 1421 Request, TLS EAP (EAP-TLS) 110 2024-04-01 11:17:47.750570 Device_00:8c:94 Nearest-non-TPMR-bridge EAP 60 Response, TLS EAP (EAP-TLS) 111 2024-04-01 11:17:47.750881 MS-NLB-PhysServer-17_11:11:11:11 Nearest-non-TPMR-bridge SSL 1068 Continuation Data 112 2024-04-01 11:17:49.896020 MS-NLB-PhysServer-17_11:11:11:11 Nearest-non-TPMR-bridge SSL 1068 Continuation Data 113 2024-04-01 11:17:50.104051 Device_00:8c:94 Nearest-non-TPMR-bridge TLSv1.2 233 Client Hello, Alert (Level: Fatal, Description: Certificate Unknown) -- Description: Certificate Unknown (46) 114 2024-04-01 11:17:50.104413 MS-NLB-PhysServer-17_11:11:11:11 Nearest-non-TPMR-bridge EAP 60 Failure Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done Frame 111: 1068 bytes on wire (8544 bits), 1068 bytes captured (8544 bits) on interface \Device\NPF_{87758CCA-2149-4961-9FDA-E59432A16D13}, id 0 Ethernet II, Src: MS-NLB-PhysServer-17_11:11:11:11 (02:11:11:11:11:11), Dst: Nearest-non-TPMR-bridge (01:80:c2:00:00:03) 802.1X Authentication Extensible Authentication Protocol Code: Request (1) Id: 56 Length: 1050 Type: TLS EAP (EAP-TLS) (13) EAP-TLS Flags: 0x00 0... .... = Length Included: False .0.. .... = More Fragments: False ..0. .... = Start: False [2 EAP-TLS Fragments (2437 bytes): #109(1393), #111(1044)] [Frame: 109, payload: 0-1392 (1393 bytes)] [Frame: 111, payload: 1393-2436 (1044 bytes)] [Fragment Count: 2] [Reassembled EAP-TLS Length: 2437] Transport Layer Security TLSv1.2 Record Layer: Handshake Protocol: Server Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 61 Handshake Protocol: Server Hello Handshake Type: Server Hello (2) Length: 57 Version: TLS 1.2 (0x0303) Random: e8497a7739576c02beabbb0b95a6b95f026ba3bc167b4992af22b64fb10f1e8b GMT Unix Time: Jun 29, 2093 21:29:51.000000000 India Standard Time Random Bytes: 39576c02beabbb0b95a6b95f026ba3bc167b4992af22b64fb10f1e8b Session ID Length: 0 Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) Compression Method: null (0) Extensions Length: 17 Extension: renegotiation_info (len=1) Type: renegotiation_info (65281) Length: 1 Renegotiation Info extension Extension: ec_point_formats (len=4) Type: ec_point_formats (11) Length: 4 EC point formats Length: 3 Elliptic curves point formats (3) EC point format: uncompressed (0) EC point format: ansiX962_compressed_prime (1) EC point format: ansiX962_compressed_char2 (2) Extension: extended_master_secret (len=0) Type: extended_master_secret (23) Length: 0 [JA3S Fullstring: 771,52392,65281-11-23] [JA3S: d7d95b173b904a8f4de65bd751cb534a] TLSv1.2 Record Layer: Handshake Protocol: Certificate Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 1793 Handshake Protocol: Certificate Handshake Type: Certificate (11) Length: 1789 Certificates Length: 1786 Certificates (1786 bytes) TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 401 Handshake Protocol: Server Key Exchange Handshake Type: Server Key Exchange (12) Length: 397 EC Diffie-Hellman Server Params TLSv1.2 Record Layer: Handshake Protocol: Certificate Request Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 153 Handshake Protocol: Certificate Request Handshake Type: Certificate Request (13) Length: 149 Certificate types count: 3 Certificate types (3 types) Signature Hash Algorithms Length: 40 Signature Hash Algorithms (20 algorithms) Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: ed25519 (0x0807) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (7) Signature Algorithm: ed448 (0x0808) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (8) Signature Algorithm: rsa_pss_pss_sha256 (0x0809) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (9) Signature Algorithm: rsa_pss_pss_sha384 (0x080a) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (10) Signature Algorithm: rsa_pss_pss_sha512 (0x080b) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (11) Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: SM2 (4) Signature Algorithm: rsa_pss_rsae_sha384 (0x0805) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (5) Signature Algorithm: rsa_pss_rsae_sha512 (0x0806) Signature Hash Algorithm Hash: Unknown (8) Signature Hash Algorithm Signature: Unknown (6) Signature Algorithm: rsa_pkcs1_sha256 (0x0401) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: rsa_pkcs1_sha384 (0x0501) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: rsa_pkcs1_sha512 (0x0601) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: SHA224 ECDSA (0x0303) Signature Hash Algorithm Hash: SHA224 (3) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: SHA224 RSA (0x0301) Signature Hash Algorithm Hash: SHA224 (3) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: SHA224 DSA (0x0302) Signature Hash Algorithm Hash: SHA224 (3) Signature Hash Algorithm Signature: DSA (2) Signature Algorithm: SHA256 DSA (0x0402) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: DSA (2) Signature Algorithm: SHA384 DSA (0x0502) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: DSA (2) Signature Algorithm: SHA512 DSA (0x0602) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: DSA (2) Distinguished Names Length: 101 Distinguished Names (101 bytes) TLSv1.2 Record Layer: Handshake Protocol: Server Hello Done Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 4 Handshake Protocol: Server Hello Done Handshake Type: Server Hello Done (14) Length: 0 Client Hello, Alert (Level: Fatal, Description: Certificate Unknown) Extensible Authentication Protocol Code: Response (2) Id: 56 Length: 215 Type: TLS EAP (EAP-TLS) (13) EAP-TLS Flags: 0x00 Transport Layer Security TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 197 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 193 Version: TLS 1.2 (0x0303) Random: 259ea02b1870ac3618e57b7cbdf4a4ad7df085bf1180f24c52141c38f640cdac Session ID Length: 0 Cipher Suites Length: 80 Cipher Suites (40 suites) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 72 Extension: signature_algorithms (len=22) Extension: supported_groups (len=24) Extension: ec_point_formats (len=2) Extension: encrypt_then_mac (len=0) Extension: extended_master_secret (len=0) Extension: session_ticket (len=0) [JA4: 12i400600_9479543b8654_7b0ba9b4cf08] [JA4_r [truncated]: 12i400600_002f,0033,0035,0039,003c,003d,0067,006b,009c,009d,009e,009f,00ff,c009,c00a,c013,c014,c023,c024,c027,c028,c02b,c02c,c02f,c030,c09c,c09d,c09e,c09f,c0a0,c0a1,c0a2,c0a3,c0ac,c0ad,c0ae,c0af,cca8,cca9,ccaa_000a,000b,] [JA3 Fullstring [truncated]: 771,52392-52393-52394-49196-49200-159-49325-49311-49188-49192-107-49162-49172-57-49327-49315-49195-49199-158-49324-49310-49187-49191-103-49161-49171-51-49326-49314-157-49309-61-53-49313-156-49308-60-47-49312-255] [JA3: fee1630eb5b7688c9f8303364702933f] TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Certificate Unknown) Content Type: Alert (21) Version: TLS 1.2 (0x0303) Length: 2 Alert Message Level: Fatal (2) Description: Certificate Unknown (46) Is it that certificates are correct the server / client code is at fault - I am running EAP-TLS [ https://github.com/championswimmer/kernel_sony_tamsui/tree/master/platform/…] code as client and hostapd daemon as server. Regards, Prakash

2 weeks, 4 days

1
0
0 0

[Mbed-tls-announce] Latest Release of Mbed TLS

by Minos Galanakis via Mbed-tls-announce

Hi Mbed TLS users, We have released Mbed TLS versions 3.6.0 LTS and 2.28.8. These releases of Mbed TLS address several security issues, provide bug fixes, and bring other minor changes. Full details are available in the release notes (https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.6.0, https://github.com/Mbed-TLS/mbedtls/releases/tag/v2.28.8). We recommend all users to consider whether they are impacted, and to upgrade appropriately. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org

3 weeks

7
8
0 0

Latest release of Mbed TLS

by Minos Galanakis

Hi Mbed TLS users, We have released Mbed TLS versions 3.6.0 LTS and 2.28.8. These releases of Mbed TLS address several security issues, provide bug fixes, and bring other minor changes. Full details are available in the release notes (https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.6.0, https://github.com/Mbed-TLS/mbedtls/releases/tag/v2.28.8). We recommend all users to consider whether they are impacted, and to upgrade appropriately.

3 weeks, 1 day

1
0
0 0

Assistance Requested: TLS Handshake Failure with MbedTLS on STM32F4

by Ashvajit Prasad

Hello Mbed-TLS team, I am reaching out for guidance on an issue I've encountered while integrating MbedTLS for HTTPS requests using the coreHTTP stack alongside FreeRTOSplusTCP on an STM32F4 device. Although I have successfully implemented an HTTP client, moving to HTTPS has presented some challenges. My approach has included several adjustments to the mbedtls_config file, such as: - Integrating a Random Number Generator (RNG) from STM32 within the mbed_Entropy_poll function. - Utilizing the calloc and free functions provided by FreeRTOS. - Modifying the search algorithm to correctly handle null-terminated PEM certificates. Despite these efforts, I am unable to establish a connection to the server, with the process consistently failing during the TLS handshake phase. Specifically, the client hello message is transmitted from my device, but no response is received from the server, resulting in an MBEDTLS_INTERNAL_ERROR. Enclosed with this email are my mbedtls_config file and a detailed account of the issue as posted on the FreeRTOS forum<https://forums.freertos.org/t/integration-of-ssl-in-corehttp/19561/11>. While I do not expect a full code review<https://github.com/AshvajitP/Eth_FreeRTOS_F4>, any insights into potential causes for this type of handshake failure would be greatly appreciated. Thank you for your time and assistance. Regards, Ashvajit Prasad

3 weeks, 2 days

1
0
0 0

Status of RFC 8449 support

by norbert.fabritius＠esrlabs.com

I saw the following comment when configuring Record Size Limit Extension (RFC 8449) in `mbedtls_config.h` [1]: > This extension is currently in development and must NOT be used except for testing purposes. Is this still accurate? What functionality is missing for full RFC 8449 support? Is this feature planned for a specific date? [1] https://github.com/Mbed-TLS/mbedtls/blob/611f899c0c9d397baedfaec34ea0861ad2…

3 weeks, 2 days

3
3
0 0

2024

2023

2022

2021

2020

mbed-tls