- mbed-tls - lists.trustedfirmware.org

handshake fail with "Alert (Level: Fatal, Description: Protocol Version)"

by 扶柏成

Hi all, We have encountered a challenge while using mbedTLS 3.5.1 and would greatly appreciate the assistance of the experts. Thank you in advance for your support. I used mbedTLS 3.5.1 to connect to the server acc.connect.cpms.milence.com, and the TLS handshake failed with an Alert (Level: Fatal, Description: Protocol Version) error. Detailed information is described at this GitHub issue<https://github.com/Mbed-TLS/mbedtls/issues/10141>. * We attempted to connect with the Windows EDGE browser and found through packet capture that the handshake was successful. * We were also able to successfully handshake using TLS 1.2. * When we limited the supported group to only: MBEDTLS_SSL_IANA_TLS_GROUP_SECP256R1 and used TLS 1.3, the handshake was also successful. For more details, please refer to the discussion on GitHub: Handshake fail with "Alert (Level: Fatal, Description: Protocol Version)" ・ Issue #10141 ・ Mbed-TLS/mbedtls<https://github.com/Mbed-TLS/mbedtls/issues/10141>. Best Regards, Fu Baicheng

2 days, 22 hours

1
0
0 0

Mbed TLS 3.6.3 and 2.28.10

by Minos Galanakis

Dear Mbed TLS users, We have released Mbed TLS versions 3.6.3 and 2.28.10. These releases provide bugfixes, security fixes and minor improvements. This release of Mbed TLS provides the fix for the TLS compatibility issue of handling fragmented handshake messages. This release includes fixes for security issues. Full details are available in the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-2.28.10 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.3 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Many thanks, Minos Galanakis Mbed TLS developer

1 month

1
0
0 0

[Mbed-tls-announce] Mbed TLS 3.6.3 and 2.28.10

by Minos Galanakis via Mbed-tls-announce

Dear Mbed TLS users, We have released Mbed TLS versions 3.6.3 and 2.28.10. These releases provide bugfixes, security fixes and minor improvements. This release of Mbed TLS provides the fix for the TLS compatibility issue of handling fragmented handshake messages. This release includes fixes for security issues. Full details are available in the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-2.28.10 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.3 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Many thanks, Minos Galanakis Mbed TLS developer 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

1 month

1
0
0 0

[Mbed-tls-announce] Announcing Mbed TLS 3.6.3 and 2.28.10

by Gilles Peskine via Mbed-tls-announce

Dear Mbed TLS users, The next release of Mbed TLS (3.6.3 and 2.28.10) is scheduled on Monday 2025-03-24. It will include a security fix for a vulnerability with a high impact to affected applications. Due to the nature of the vulnerability, which involves an insecure default in current versions of Mbed TLS, fixing it may require a small change in application code. We will provide instructions in the release notes. Without this change, affected applications will fail at runtime with Mbed TLS 3.6.3 or 2.28.10. Applications that are currently secure will generally not require any change. We apologize for the inconvenience. Best regards, -- Gilles Peskine On behalf of the Mbed TLS security team 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

1 month, 1 week

1
0
0 0

Inquiry about the ECC-160 bit size support in MbedTLS

by Ankita Hatmode

Hi Team, I am working on an embedded security project and exploring ECC support in MbedTLS 3.6.2. I would like to confirm whether the MbedTLS supports ECC-160 i.e. Elliptic Curve Cryptography with a 160 bit key size, in the latest version or any earlier versions. Looking forward to your response. Thanks and regards, Ankita Hatmode -- ------------------------------------------------------------------------------------------------------------------------- **Disclaimer:** This email message including any attachments is confidential, and may be privileged and proprietary to Agiliad. If you are not the intended recipient, please notify us immediately by replying to this message and destroy all copies of this message including any attachments. You are NOT authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. Thank you. ------------------------------------------------------------------------------------------------------------------------

1 month, 2 weeks

3
2
0 0

Problem during test_suite generation while cross-compiling on version 3.6.2

by Francois Mace

Hello Everybody, I am trying to migrate my cross-compilation setup from version 2.28.9 to version 3.6.2. I use a Makefile based approach for compilation. Everything seems to work fine up to the point where the compilation process reaches the test_suite data generation Gen suites/test_suite_psa_crypto_generate_key.generated.data suites/test_suite_psa_crypto_low_hash.generated.data suites/test_suite_psa_crypto_not_supported.generated.data suites/test_suite_psa_crypto_op_fail.generated.data suites/test_suite_psa_crypto_storage_format.current.data suites/test_suite_psa_crypto_storage_format.v0.data At that point it seems that the python based tools attempts to execute a temp executable (generated for my cross-compilation target ?) which fails. The traceback obtained is the following: Traceback (most recent call last): File "../framework/scripts/generate_psa_tests.py", line 849, in <module> test_data_generation.main(sys.argv[1:], __doc__, PSATestGenerator) File "/home/dev/test/mbed-TLS_3.6.2/framework/scripts/mbedtls_framework/test_data_generation.py", line 224, in main generator.generate_target(target) File "../framework/scripts/generate_psa_tests.py", line 845, in generate_target super().generate_target(name, self.info) File "/home/dev/test/mbed-TLS_3.6.2/framework/scripts/mbedtls_framework/test_data_generation.py", line 177, in generate_target self.write_test_data_file(name, test_cases) File "/home/dev/test/mbed-TLS_3.6.2/framework/scripts/mbedtls_framework/test_data_generation.py", line 164, in write_test_data_file test_case.write_data_file(filename, test_cases) File "/home/dev/test/mbed-TLS_3.6.2/framework/scripts/mbedtls_framework/test_case.py", line 88, in write_data_file for tc in test_cases: File "../framework/scripts/generate_psa_tests.py", line 694, in all_test_cases if key.location_value() != 0: File "/home/dev/test/mbed-TLS_3.6.2/framework/scripts/mbedtls_framework/psa_storage.py", line 186, in location_value return self.lifetime.value() >> 8 File "/home/dev/test/mbed-TLS_3.6.2/framework/scripts/mbedtls_framework/psa_storage.py", line 89, in value self.update_cache() File "/home/dev/test/mbed-TLS_3.6.2/framework/scripts/mbedtls_framework/psa_storage.py", line 67, in update_cache include_path=includes) #type: List[str] File "/home/dev/test/mbed-TLS_3.6.2/framework/scripts/mbedtls_framework/c_build_helper.py", line 158, in get_c_expression_values output = subprocess.check_output([exe_name]) File "/usr/lib/python3.7/subprocess.py", line 395, in check_output **kwargs).stdout File "/usr/lib/python3.7/subprocess.py", line 472, in run with Popen(*popenargs, **kwargs) as process: File "/usr/lib/python3.7/subprocess.py", line 775, in __init__ restore_signals, start_new_session) File "/usr/lib/python3.7/subprocess.py", line 1522, in _execute_child raise child_exception_type(errno_num, err_msg, err_filename) OSError: [Errno 8] Exec format error: '/tmp/tmp--m95sjmdw' make[2]: *** [Makefile:127: generated_psa_test_data] Error 1 make[2] : on quitte le répertoire « /home/dev/test/mbed-TLS_3.6.2/tests » make[1]: *** [Makefile:35: tests] Error 2 make[1] : on quitte le répertoire « /home/dev/test/mbed-TLS_3.6.2 » make: *** [test.make:152: all] Error 2 Looking at the format of the generated tmp executable, it seems it is generated for my cross-compilation target, it therefore cannot be executed in my compilation environment. I would like to be able to generate the test and test data in order to be able to execute them on my compilation target, which is what I used to do with the previously integrated version of the library. Is there something I am missing in my compilation? am I missing a specific setup variable in my Makefile? Thanks for your feedback. Best regards, Francois

2 months

2
1
0 0

Different performance from 2.6.2 to 3.6.2 for https file upload

by Stefano Tebaldi

Hello, I recently updated mbedTLS library version 2.6.2 to 3.6.2. I am using the library to add https to Mongoose web server on a STM32H753 with FreeRTOS + LWIP. 2.6.2 was generated in a IAR project using STMCubeMX. What I am noticing is that file transfer performance has gotten much worse. With version 2.6.2 it took a few minutes to transfer a file of around 33 MB, now with version 3.6.2 it takes around 15 min. What could this depend on? Attached is the configuration used for the two versions. The certificate for https is EC curve secp256r1. Thank you

2 months

2
4
0 0

[Mbed-tls-announce] Mbed TLS 4.0/TF-PSA Crypto 1.0 release timeline

by Janos Follath via Mbed-tls-announce

Dear Mbed TLS and PSA Crypto users, We would like to update you on the release timeline for Mbed TLS 4.0/TF-PSACrypto1.0 release. As a reminder, the key objectives of the release are a separate TF-PSA Crypto repo., PSA Crypto becoming the de facto Crypto API and Mbed TLS using PSA Crypto APIs as the crypto API by default. While TF-PSA Crypto repository is now available, the remaining effort to be ready for the release is more than we originally planned for. Based on remaining effort estimates, we plan to make Mbed TLS 4.0-Beta and TF-PSA Crypto 1.0-Beta release around end of June. The Mbed TLS 4.0, and TF-PSA Crypto 1.0 release is expected around end of September. We don’t expect users to integrate the Beta release. Beta is aimed to pipeclean the separate Mbed TLS and TF-PSA Crypto release process and get any early feedback. The release in September is expected to be integrated by users to their projects. We wanted to provide these revised release dates so that the users can plan accordingly. In the meantime, bug fixes and security fixes will continue to be provided via. Mbed TLS 3.6.x LTS releases. Thanks, Mbed TLS/PSA Crypto Maintainers. -- 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

2 months, 2 weeks

1
0
0 0

Support for Quantum Safe Algorithms

by NAYNA JAIN

Hi MbedTLS team, I have been following up the MbedTLS roadmap from here - https://mbed-tls.readthedocs.io/en/latest/project/roadmap/ . It talks about Post Quantum Cryptography support in future. And in the section of Long Term Plans for MbedTLS, I see the note related to PQC as "Regarding post-quantum cryptography (PQC) in particular, we do plan to wait until there are official standards: as of 2023, apart from stateful hash-based signatures, there are too many open questions about selected algorithms (choice of parameters, data formats, hybrid combinations…). This note seems to be pretty old as it refers to 2023.. So, are there any latest update on the roadmap? Is there any plan to support latest NIST standardized algorithms (ML-DSA, ML-KEM, SLH-DSA) in this year or next year. Thanks & Regards, * Nayna

2 months, 3 weeks

3
2
0 0

Using mbedTLS for TLS&X509 with a separate PSA Crypto Implementation

by Zak, Kevin

Hello mbedtls mailing list, I'm working to modify mbedTLS (3.6.2) to use our PSA Crypto Implementation in a separate library. Our solution does not make use of PSA 'drivers' that mbedTLS refers to. I've modified makefiles to not build PSA Crypto files, and have enabled MBEDTLS_PSA_CRYPTO_C & MBEDTLS_USE_PSA_CRYPTO. I've also defined MBEDTLS_PSA_ACCEL_ALG_XXX for our supported algorithms. 1. Is there a good way to determine whether a given TLS/X509 configuration would require a certain 'legacy' (maybe a better term is 'non-PSA') crypto file to be built into the mbedTLS library? * The goal is to build as few crypto source files into the mbedTLS source files as possible, maximizing usage of our separate PSA implementation 2. Example: My test application using mbedtls_x509_crt_parse() receives linking errors for mbedtls_ecp_(group/point)_xxx() and mbedtls_mpi_xxx() that are referenced in pkparse.c (which I am building into the library). * Ecp.c is currently excluded from the build (as is its define) - if I add it, I add significantly more linking errors for mbedtls_mpi APIs. I was under the impression that ECP and MPI APIs could be avoided with the correct configuration. * If ecp/mpi helper APIs are needed still for x509, this would be good to know. However, I'd like to avoid usage of MPI APIs that perform actual software calculations. See the screenshot for a list of non-PSA crypto files I am currently building to test with. I imagine I may have to add more incrementally. [cid:image001.png@01DB726D.879014D0] Any insights on this general use case or my ECP troubles with x509 would be appreciated. I plan to extend the strategy as these are the findings from an attempt to use just one x509 API. Best, Kevin Zak

2 months, 3 weeks

2
1
0 0

Use mbedtls_gcm_auth_decrypt get wrong tag

by Elva Huang

Dear mbed TLS team, Recently, while debugging my code, I encountered an issue when using the AES-GCM algorithm. I found that when calling the mbedtls_gcm_auth_decrypt interface in version 3.6.1, the calculated tag consistently does not match the input tag. However, when using the same interface in version 2.28.2, the tag is successfully calculated as expected. Below is the demo code we are using: tstSecKeyList g_stPreInterKey = { .u8KeyNum = 5U, .u8IsUse = 1U, .u16KeyLen = 16U, .u16IVLen = 12U, .u16AddLen = 16U, .enuSecType = SEC_AES_GCM, .au8Key = { 0x68U, 0xffU, 0xb7U, 0xffU, 0x5eU, 0xffU, 0x10U, 0xffU, 0x9eU, 0xffU, 0xb8U, 0xffU, 0x01U, 0xffU, 0xb9U, 0xffU, 0xa0U, 0xffU, 0x1cU, 0xffU, 0xdfU, 0xffU, 0x0aU, 0xffU, 0xe6U, 0xffU, 0xc8U, 0xffU, 0xc5U, 0xffU, 0x39U, 0xffU }, .au8Iv = { 0x3, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x0, 0x1, 0x2, 0x3 }, .au8Add = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 } .u16AddLen = 0, }; static uint8_t s_au8SecMemoryBuffer[6*1024]; mbedtls_gcm_context aesGcmContext; uint8_t *pau8EncryptedPlain = inParam0; (note: inParam0=434421d30c9abf31b96d2d28d00b5cb4e6fe84033999d53d3a50674b3aedd81f) uint8_t *pau8AesTag = inParam0 + 16; (e6fe84033999d53d3a50674b3aedd81f) uint8_t u8EncryptedPlainLen = 16; uint8_t u8AesTagKeyLen = 16; mbedtls_gcm_init(&aesGcmContext); mbedtls_memory_buffer_alloc_init(s_au8SecMemoryBuffer, 6*1024); vidPreInterKeyget(g_stPreInterKey.au8Key, au8preInterKey); mbedtls_gcm_setkey(&aesGcmContext, MBEDTLS_CIPHER_ID_AES, au8preInterKey, 16*8); s32Ret = mbedtls_gcm_auth_decrypt(&aesGcmContext, u8EncryptedPlainLen, g_stPreInterKey.au8Iv, g_stPreInterKey.u16IVLen, g_stPreInterKey.au8Add, g_stPreInterKey.u16AddLen, pau8AesTag, u8AesTagKeyLen, pau8EncryptedPlain, s_au8DecryptKey); Best regards,

3 months

1
1
0 0

Question Regarding Change Cipher Spec States in the TLS 1.3 Handshake Protocol

by 千山啼祢

Dear Developer, I was reviewing the code and noticed that in the TLS 1.3 handshake protocol state machine, the "Change Cipher Spec" state has been divided into five different states based on its occurrence timing. Could you please clarify if there are any specific considerations for this approach? Additionally, these states can appear multiple times during a single handshake, which implies multiple "Change Cipher Spec" messages. However, the TLS 1.3 standard suggests that the "Change Cipher Spec" should only appear once in a single handshake. Could you kindly explain the rationale behind this design decision? Thank you for your time and assistance. I look forward to your response. Best regards, XiangDong Li

3 months, 2 weeks

1
0
0 0

Inquiry Regarding mbedTLS v2.16.2 Compatibility for Secure MQTT Connection on STM32CubeIDE

by Noushad

Hello, I am currently working on a project using STM32CubeIDE, where I am leveraging mbedTLS v2.16.2 to establish a secure MQTT connection with a Mosquitto broker on port 8883. During my implementation, I encountered a TLS handshake error with the following details: mbedtls_ssl_handshake failed. -29312 (-0x7280) I would like to confirm if mbedTLS v2.16.2, as provided in STM32CubeIDE, supports secure TLS connections (e.g., Secure MQTT) and is compatible with Mosquitto broker configurations. Additionally, I would appreciate guidance on resolving this error. Here are some specific details about my setup: 1. mbedTLS version: 2.16.2 (as integrated into STM32CubeIDE). 2. Broker: Mosquitto, configured for secure MQTT on port 8883. 3. Issue: TLS handshake fails with the error mentioned above. 4. Certificates: [CA certificates, ]. Please let me know if additional information Regards, Noushad Embedded systems engineer Inthings Technologies Private Limited www.inthings.tech<http://www.inthings.tech> [cid:image001.png@01DB65BA.1F5B9660]

3 months, 2 weeks

1
0
0 0

Question Regarding Change Cipher Spec States in the TLS 1.3 Handshake Protocol

by 千山啼祢

Dear Developer, I was reviewing the code and noticed that in the TLS 1.3 handshake protocol state machine, the "Change Cipher Spec" state has been divided into five different states based on its occurrence timing. Could you please clarify if there are any specific considerations for this approach? Additionally, these states can appear multiple times during a single handshake, which implies multiple "Change Cipher Spec" messages. However, the TLS 1.3 standard suggests that the "Change Cipher Spec" should only appear once in a single handshake. Could you kindly explain the rationale behind this design decision? Thank you for your time and assistance. I look forward to your response. Best regards, XiangDong Li

3 months, 2 weeks

1
0
0 0

Heap and stack usage information

by Michael Thomas

Hi, I am trying to determine what would be an optimal stack and heap allocation for mbedtls. I realize this changes with algorithms, some configuration macros for the algorithms as well as concurrency. But is there any information on stack and heap usage that I can use as a starting point? And is there any information on the same for a crypto suite. Thanks Michael T Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not an intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you.

3 months, 2 weeks

1
0
0 0

Inquiry Regarding mbedTLS v2.16.2 Compatibility for Secure MQTT Connection on STM32CubeIDE

by Noushad

Hello, I am currently working on a project using STM32CubeIDE, where I am leveraging mbedTLS v2.16.2 to establish a secure MQTT connection with a Mosquitto broker on port 8883. During my implementation, I encountered a TLS handshake error with the following details: mbedtls_ssl_handshake failed. -29312 (-0x7280) I would like to confirm if mbedTLS v2.16.2, as provided in STM32CubeIDE, supports secure TLS connections (e.g., Secure MQTT) and is compatible with Mosquitto broker configurations. Additionally, I would appreciate guidance on resolving this error. Here are some specific details about my setup: 1. mbedTLS version: 2.16.2 (as integrated into STM32CubeIDE). 2. Broker: Mosquitto, configured for secure MQTT on port 8883. 3. Issue: TLS handshake fails with the error mentioned above. 4. Certificates: [Specify if you are using self-signed certificates, CA certificates, etc.]. Please let me know if additional information or logs would be helpful for diagnosing the issue. Thank you for your assistance. Regards, Noushad Embedded systems engineer Inthings Technologies Private Limited www.inthings.tech<http://www.inthings.tech> [cid:image001.png@01DB5D28.96B30030] Regards, Noushad Embedded systems engineer Inthings Technologies Private Limited www.inthings.tech<http://www.inthings.tech> [cid:image001.png@01DB5D28.96B30030]

3 months, 3 weeks

2
1
0 0

Request for Assistance with Iterative Loading and Verification of Built-in Certificates in Mbed TLS

by xiaobing wang

Dear Mbed TLS Support Team, I am currently working on a project using Mbed TLS version 3.6 on FreeRTOS, and I am encountering an issue with handling multiple CA certificates during the TLS handshake process. My device has a set of built-in certificates, and I need to try each certificate one by one to establish a successful connection to my server. However, I am facing difficulties in this process. ### System Information: - **Mbed TLS version**: 3.6 - **Operating System**: FreeRTOS - **Configuration**: Default - **Compiler and Options**: N/A (using default configuration) ### Expected Behavior: The first certificate (e.g., `cdotroot.cer`) cannot be verified by Mbed TLS, while the correct certificate should successfully establish a connection. ### Actual Behavior: Both the incorrect and correct CA certificates fail to establish a connection successfully. ### Steps to Reproduce: Here is a sample of my code: ```c static int load_and_verify_certificates(int conn_id, uint8_t *cert_buffer, size_t buffer_size) { int ret; bool connection_established = false; uint32_t cert_index = 0; while (!connection_established && cert_index < MAX_CERT_COUNT) { size_t cert_size = buffer_size; // Free and initialize the certificate context mbedtls_x509_crt_free(&cacert[conn_id]); mbedtls_x509_crt_init(&cacert[conn_id]); // Load the built-in certificate ret = try_built_in_certificate(cert_buffer, &cert_size, cert_index); if (ret == CERT_ERR_INDEX_OUT_OF_RANGE) { break; } if (ret != CERT_SUCCESS) { cert_index++; continue; } // Parse the certificate cert_buffer[cert_size] = '\0'; ret = mbedtls_x509_crt_parse(&cacert[conn_id], cert_buffer, cert_size + 1); if (ret < 0) { cert_index++; continue; } // Set the certificate chain mbedtls_ssl_conf_ca_chain(&conf[conn_id], &cacert[conn_id], NULL); // Perform the TLS handshake ret = mbedtls_ssl_handshake(&ssl[conn_id]); if (ret == 0) { uint32_t flags = mbedtls_ssl_get_verify_result(&ssl[conn_id]); if (flags == 0) { connection_established = true; // Cache the certificate cache_certificate(cert_buffer, cert_size, cert_index); break; } } else { LOGD("Failed to perform handshake with certificate index %d, error: -0x%x\n", cert_index, -ret); } // Reset the SSL session ret = mbedtls_ssl_session_reset(&ssl[conn_id]); if (ret != 0) { LOGD("Failed to reset SSL session, error: -0x%x\n", -ret); return ret; } cert_index++; } return connection_established ? 0 : -1; } ``` ### Additional Information: Here are the logs: ``` Reading certificate 'cdotroot.cer' at address 0x08100650, size: 1348 Failed to perform handshake with certificate index 0, error: -0x2700 Reading certificate 'digicertroot.cer' at address 0x08100B94, size: 1360 Failed to perform handshake with certificate index 1, error: -0x7300 ... ``` I suspect that the issue may be related to the limited RAM space available on my device. I am looking for guidance on how to properly iterate through and verify the built-in certificates within these constraints. Any suggestions or best practices for handling multiple certificates in such an environment would be greatly appreciated. Thank you for your assistance. Best regards, [Tony] --- Feel free to replace `[Your Name]` with your actual name before sending the email.

4 months

1
0
0 0

How to use a different mbedtls_config.h file?

by Alexander Slatina

Hello, I described an issue I have here: https://github.com/Mbed-TLS/mbedtls/issues/9867 During compilation it compiles with the wrong mbedtls_config.h even though I set up this part in my CMakeLists.txt: #MbedTLS default START # 1. MbedTLS custom config setup set(MBEDTLS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/mbedtls) set(MBEDTLS_CONFIG_FILE "${CMAKE_CURRENT_SOURCE_DIR}/mbedtls_config.h") add_compile_definitions( MBEDTLS_CONFIG_FILE="${MBEDTLS_CONFIG_FILE}" MBEDTLS_USER_CONFIG_FILE="${MBEDTLS_CONFIG_FILE}" ) set(ENABLE_TESTING OFF CACHE BOOL "Disable mbedtls testing" FORCE) set(ENABLE_PROGRAMS OFF CACHE BOOL "Disable mbedtls programs" FORCE) set(MBEDTLS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/mbedtls) # Add mbedtls build add_subdirectory(${MBEDTLS_DIR}) #MbedTLS END There’s more information on the GitHub link. Thank you in advance. Alex

4 months

1
0
0 0

TF-PSA-Crypto

by Janos Follath

Dear Mbed TLS users, Mbed TLS has contained the reference implementation of the PSA Crypto API since the early days of the standard. This implementation was experimental at first, but over years of development it reached maturity, and the experimental status was removed three years ago (in version 3.6.1.). Shortly after that, in 2022, the TF-PSA-Crypto<https://github.com/Mbed-TLS/TF-PSA-Crypto> repository was created just for the PSA Crypto API implementation to make it more accessible for users only interested in that. This repository was only a mirror of the main one and the development of the PSA Crypto API implementation remained integral part of Mbed TLS. In the background, work has been started to make this repository the place where the development of the PSA Crypto API reference implementation happens. This work has finally been completed and from now on TF-PSA-Crypto<https://github.com/Mbed-TLS/TF-PSA-Crypto> is ready to receive contributions, bug reports and enhancement requests. TF-PSA-Crypto<https://github.com/Mbed-TLS/TF-PSA-Crypto> will now be the development repository for the PSA Crypto reference implementation. Mbed TLS will continue to rely on TF-PSA-Crypto<https://github.com/Mbed-TLS/TF-PSA-Crypto> and will be using it as a submodule. Many thanks, Janos Follath Mbed TLS developer

4 months, 1 week

1
0
0 0

advice on mbedtls_ssl_context change between v2.16.1 and 3.6.2

by Daniel Webb

Hi, Can you give me a little advice on how v3 works? I've updated our mbed library from 2.16.1 to 3.6.2 which was mostly a very smooth experience, thanks. The one question in my mind relates to making p_bio private in mbedtls_ssl_context *I used to free it before calling mbedtls_ssl_free - is it ok to skip this now? ie:* //mbedtls_net_free((mbedtls_net_context *) m_ssl.p_bio); mbedtls_ssl_free(&m_ssl); *I also used to poll it before calling mbedtls_ssl_close_notify - is ok to skip this now? ie:* //if(mbedtls_net_poll((mbedtls_net_context *) m_ssl.p_bio, MBEDTLS_NET_POLL_WRITE, 0) < 0) // return; int ret; while((ret = mbedtls_ssl_close_notify(&m_ssl)) < 0) { if(ret != MBEDTLS_ERR_SSL_WANT_READ && ret != MBEDTLS_ERR_SSL_WANT_WRITE) return; } It all seems to run just fine like this, but I could really do with some confidence boosting validation of my cavalier commenting. Thank you Daniel

4 months, 1 week

1
1
0 0

Integrating Mbed TLS with LWIP

by Bas Prins

Dear Mbed TLS team, I am trying to integrate Mbed TLS in our platform: - nxp imx rt 1024 CPU (arm based) - FreeRTOS (10.6) - Lwip (2.2) - Mbed TLS (3.6.2) I am using the LWIP port to Mbed TLS and managed to create an client configuration by supplying a google certificate which I created as follows: openssl s_client -showcerts -connect www.google.com:443 </dev/null 2>/dev/null | openssl x509 -outform PEM > google_root_ca.pem PS: using the true random number generator in our CPU as the entropy source for Mbed TLS. I ran into some issues which I managed to resolve by adding another option in Mbed TLS (found this on a forum which solved the problem): #define MBEDTLS_RSA_C /* required for google's root CA */ #define MBEDTLS_PKCS1_V21 /* required for RSA */ Next I connected our http client to use the TLS configuration and gave it a first spin by trying to send a HTTP GET request to google.com. The TLS handshake failed. I enabled logging in the hope this would give me a direction, but I can't see where things go wrong (until the obvious error -0x7780 (MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE)). Can somebody see what goes wrong on the client side, which results in the server deciding to fail the request? Attached the log and will paste it here in the email. ====================== [2024-12-11 09:08:28] 2024-12-10 12:53:35.612 [Info ] [Http] GET from google.com:443 - / [2024-12-11 09:08:28] 2024-12-10 12:53:35.630 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(1327): The SSL configuration is tls12 only. [2024-12-11 09:08:28] 2024-12-10 12:53:35.676 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4606): => handshake [2024-12-11 09:08:28] 2024-12-10 12:53:35.678 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:28] 2024-12-10 12:53:35.678 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:28] 2024-12-10 12:53:35.696 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4525): client state: MBEDTLS_SSL_HELLO_REQUEST [2024-12-11 09:08:28] 2024-12-10 12:53:35.718 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:28] 2024-12-10 12:53:35.736 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:28] 2024-12-10 12:53:35.766 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4525): client state: MBEDTLS_SSL_CLIENT_HELLO [2024-12-11 09:08:28] 2024-12-10 12:53:35.792 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(919): => write client hello [2024-12-11 09:08:28] 2024-12-10 12:53:35.820 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(486): dumping 'client hello, random bytes' (32 bytes) [2024-12-11 09:08:28] 2024-12-10 12:53:35.848 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(486): 0000: 7b 5a 55 53 71 4d 5d ec 7e 88 19 f8 fc b7 72 b4 {ZUSq M].~.....r. [2024-12-11 09:08:28] 2024-12-10 12:53:35.878 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(486): 0010: d1 7e 13 df 21 b8 b6 3f 38 36 d4 63 19 f4 27 89 .~..! ..?86.c..'. [2024-12-11 09:08:28] 2024-12-10 12:53:35.904 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(511): dumping 'session id' (0 bytes) [2024-12-11 09:08:28] 2024-12-10 12:53:35.930 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(369): client hello, add ciphersuite: c02b, TLS-ECDHE-ECDSA-WITH-AES -128-GCM-SHA256 [2024-12-11 09:08:28] 2024-12-10 12:53:35.962 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(387): adding EMPTY_RENEGOTIATION_INFO_SCSV [2024-12-11 09:08:28] 2024-12-10 12:53:35.988 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(396): client hello, got 2 cipher suites [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(230): client hello, adding supported_groups extension [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(249): got supported group(0017) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(281): NamedGroup: secp256r1 ( 17 ) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(249): got supported group(0018) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(281): NamedGroup: secp384r1 ( 18 ) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(301): dumping 'Supported groups extension' (6 bytes) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(301): 0000: 00 04 00 17 00 18 ..... . [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(9593): adding signature_algorithms extension [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(9613): got signature scheme [403] ecdsa_secp256r1_sha256 [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(9622): sent signature scheme [403] ecdsa_secp256r1_sha256 [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(9613): got signature scheme [401] rsa_pkcs1_sha256 [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(9622): sent signature scheme [401] rsa_pkcs1_sha256 [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls12_client.c(105): client hello, adding supported_point_formats extension [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(688): client hello, total extension length: 26 [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(690): dumping 'client hello extensions' (26 bytes) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(690): 0000: 00 1a 00 0a 00 06 00 04 00 17 00 18 00 0d 00 06 ..... ........... [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(690): 0010: 00 04 04 03 04 01 00 0b 00 02 ..... ..... [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2783): => write handshake message [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2943): => write record [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3027): output record: msgtype = 22, version = [3:3], msglen = 75 [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3032): dumping 'output record sent to network' (80 bytes) [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3032): 0000: 16 03 03 00 4b 01 00 00 47 03 03 7b 5a 55 53 71 ....K.. .G..{ZUSq [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3032): 0010: 4d 5d ec 7e 88 19 f8 fc b7 72 b4 d1 7e 13 df 21 M].~... ..r..~..! [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3032): 0020: b8 b6 3f 38 36 d4 63 19 f4 27 89 00 00 04 c0 2b ..?86.c ..'.....+ [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3032): 0030: 00 ff 01 00 00 1a 00 0a 00 06 00 04 00 17 00 18 ....... ......... [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3032): 0040: 00 0d 00 06 00 04 04 03 04 01 00 0b 00 02 01 00 ....... ......... [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3080): <= write record [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2904): <= write handshake message [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_client.c(1012): <= write client hello [2024-12-11 09:08:28] 2024-12-10 12:53:35.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:28] 2024-12-10 12:53:36.008 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2367): message length: 80, out_left: 80 [2024-12-11 09:08:28] 2024-12-10 12:53:36.044 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2374): ssl->f_send() returned 80 (-0xffffffb0) [2024-12-11 09:08:28] 2024-12-10 12:53:36.082 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2401): <= flush output [2024-12-11 09:08:28] 2024-12-10 12:53:36.114 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4525): client state: MBEDTLS_SSL_SERVER_HELLO [2024-12-11 09:08:28] 2024-12-10 12:53:36.142 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls12_client.c(1193): => parse server hello [2024-12-11 09:08:28] 2024-12-10 12:53:36.170 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(4189): => read record [2024-12-11 09:08:28] 2024-12-10 12:53:36.196 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2155): => fetch input [2024-12-11 09:08:28] 2024-12-10 12:53:36.226 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2295): in_left: 0, nb_want: 5 [2024-12-11 09:08:28] 2024-12-10 12:53:36.256 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2315): in_left: 0, nb_want: 5 [2024-12-11 09:08:28] 2024-12-10 12:53:36.284 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4617): <= handshake [2024-12-11 09:08:28] 2024-12-10 12:53:36.314 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:29] 2024-12-10 12:53:36.344 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:29] 2024-12-10 12:53:36.374 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:29] 2024-12-10 12:53:36.400 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:29] 2024-12-10 12:53:36.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:29] 2024-12-10 12:53:36.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:29] 2024-12-10 12:53:37.380 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:29] 2024-12-10 12:53:37.382 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:30] 2024-12-10 12:53:37.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:30] 2024-12-10 12:53:37.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:30] 2024-12-10 12:53:38.392 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:30] 2024-12-10 12:53:38.394 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:31] 2024-12-10 12:53:38.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:31] 2024-12-10 12:53:38.999 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:31] 2024-12-10 12:53:39.346 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4606): => handshake [2024-12-11 09:08:31] 2024-12-10 12:53:39.346 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2353): => flush output [2024-12-11 09:08:31] 2024-12-10 12:53:39.348 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2362): <= flush output [2024-12-11 09:08:31] 2024-12-10 12:53:39.348 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4525): client state: MBEDTLS_SSL_SERVER_HELLO [2024-12-11 09:08:31] 2024-12-10 12:53:39.350 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls12_client.c(1193): => parse server hello [2024-12-11 09:08:32] 2024-12-10 12:53:39.350 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(4189): => read record [2024-12-11 09:08:32] 2024-12-10 12:53:39.352 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2155): => fetch input [2024-12-11 09:08:32] 2024-12-10 12:53:39.378 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2295): in_left: 0, nb_want: 5 [2024-12-11 09:08:32] 2024-12-10 12:53:39.404 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2315): in_left: 0, nb_want: 5 [2024-12-11 09:08:32] 2024-12-10 12:53:39.430 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2318): ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) [2024-12-11 09:08:32] 2024-12-10 12:53:39.460 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2340): <= fetch input [2024-12-11 09:08:32] 2024-12-10 12:53:39.490 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3855): dumping 'input record header' (5 bytes) [2024-12-11 09:08:32] 2024-12-10 12:53:39.516 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3855): 0000: 15 03 03 00 02 ..... [2024-12-11 09:08:32] 2024-12-10 12:53:39.542 [Debug] [Http] 3 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3857): input record: msgtype = 21, version = [0x303], msglen = 2 [2024-12-11 09:08:32] 2024-12-10 12:53:39.570 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2155): => fetch input [2024-12-11 09:08:32] 2024-12-10 12:53:39.598 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2295): in_left: 5, nb_want: 7 [2024-12-11 09:08:32] 2024-12-10 12:53:39.630 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2315): in_left: 5, nb_want: 7 [2024-12-11 09:09:51] 2024-12-10 12:53:39.656 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2318): ssl->f_recv(_timeout)() returned 2 (-0xfffffffe) [2024-12-11 09:09:51] 2024-12-10 12:53:39.688 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(2340): <= fetch input [2024-12-11 09:09:51] 2024-12-10 12:53:39.722 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3964): dumping 'input record from network' (7 bytes) [2024-12-11 09:09:52] 2024-12-10 12:53:39.756 [Debug] [Http] 4 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(3964): 0000: 15 03 03 00 02 02 28 ......( [2024-12-11 09:09:55] 2024-12-10 12:53:39.782 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(5092): got an alert message, type: [2:40] [2024-12-11 09:09:55] 2024-12-10 12:53:39.810 [Debug] [Http] 1 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(5099): is a fatal alert message (msg 40) [2024-12-11 09:09:55] 2024-12-10 12:54:59.004 [Debug] [Http] 1 - /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c(4244): mbedtls_ssl_handle_message_type() returned -30592 (-0x7780) [2024-12-11 09:09:55] 2024-12-10 12:54:59.036 [Debug] [Http] 1 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls12_client.c(1197): mbedtls_ssl_read_record() returned -30592 (-0x7780) [2024-12-11 09:09:55] 2024-12-10 12:54:59.062 [Debug] [Http] 2 - /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c(4617): <= handshake [2024-12-11 09:09:55] 2024-12-10 12:54:59.094 [Debug] [External] mbedtls_ssl_handshake failed: -30592 [2024-12-11 09:09:55] 2024-12-10 12:55:02.000 [Debug] [Http] Download failed: httpc_result 4, srv_resp 0, err -15 ====================== Many thanks in advance! Best regards, Bas

4 months, 2 weeks

1
0
0 0

C448 according RFC7748?

by Tom Strolch

Hello all, I want to use mbedtls-functions for "Shared Secret" according ECDH with C448. First I want to check the test vectors mentioned in RFC7748 (chapter 6.2). But it fails in function mbedtls_ecdh_compute_shared(...) with return value -0x4C80 MBEDTLS_ERR_ECP_INVALID_KEY (please see code below) But up to now I can't find the root cause. Is there a similar example available? Regards, Tom // Alice's private key static const unsigned char alice_private_key[] = { 0x77, 0x07, 0x6d, 0x0a, 0x73, 0x18, 0xa5, 0x7d, 0x3c, 0x16, 0xc1, 0x72, 0x51, 0xb2, 0x66, 0x45, 0xdf, 0x4c, 0x2f, 0x87, 0xeb, 0xc0, 0x99, 0x2a, 0xb1, 0x77, 0xfb, 0xa5, 0x1d, 0xb9, 0x2c, 0x2a }; // Bob's private key static const unsigned char bob_private_key[] = { 0x5d, 0xab, 0x08, 0x7e, 0x62, 0x4a, 0x8a, 0x4b, 0x79, 0xe1, 0x7f, 0x8b, 0x83, 0x80, 0x0e, 0xe6, 0x6f, 0x3b, 0xb1, 0x29, 0x26, 0x18, 0xb6, 0xfd, 0x1c, 0x2f, 0x8b, 0x27, 0xff, 0x88, 0xe0, 0xeb }; int main() { mbedtls_ecdh_context ecdh; unsigned char shared_secret[32]; size_t olen; int ret; mbedtls_ecdh_init(&ecdh); // Load Bob's private key ret = mbedtls_ecp_group_load(&ecdh.grp, MBEDTLS_ECP_DP_CURVE25519); if (ret != 0) { printf("Failed to load group\n"); return 1; } ret = mbedtls_mpi_read_binary(&ecdh.d, bob_private_key, sizeof(bob_private_key)); if (ret != 0) { printf("Failed to read private key\n"); return 1; } // Compute the shared secret ret = mbedtls_ecdh_compute_shared(&ecdh.grp, &ecdh.z, &ecdh.Qp, &ecdh.d, mbedtls_ctr_drbg_random, NULL); if (ret != 0) { printf("Failed to compute shared secret\n"); return 1; } ... Test vector: Alice's private key, a: 9a8f4925d1519f5775cf46b04b5800d4ee9ee8bae8bc5565d498c28d d9c9baf574a9419744897391006382a6f127ab1d9ac2d8c0a598726b Alice's public key, X448(a, 5): 9b08f7cc31b7e3e67d22d5aea121074a273bd2b83de09c63faa73d2c 22c5d9bbc836647241d953d40c5b12da88120d53177f80e532c41fa0 Bob's private key, b: 1c306a7ac2a0e2e0990b294470cba339e6453772b075811d8fad0d1d 6927c120bb5ee8972b0d3e21374c9c921b09d1b0366f10b65173992d Bob's public key, X448(b, 5): 3eb7a829b0cd20f5bcfc0b599b6feccf6da4627107bdb0d4f345b430 27d8b972fc3e34fb4232a13ca706dcb57aec3dae07bdc1c67bf33609 Their shared secret, K: 07fff4181ac6cc95ec1c16a94a0f74d12da232ce40a77552281d282b b60c0b56fd2464c335543936521c24403085d59a449a5037514a879d

4 months, 3 weeks

1
0
0 0

Migrate LWIP mbed TLS port to Mbed TLS 3.6.2 (or later)

by Bas Prins

Dear Mbed TLS team, I am trying to integrate Mbed TLS in our platform: - nxp imx rt 1024 CPU (arm based) - FreeRTOS (10.6) - Lwip (2.2) - Mbed TLS (3.6.2) LWIP supports Mbed TLS when adding defines in their configuration: /* ---------- TLS ------------------------- */ #define LWIP_ALTCP 1 #define LWIP_ALTCP_TLS 1 #define LWIP_ALTCP_TLS_MBEDTLS 1 But, unfortunately this supports an older version of Mbed TLS (I believe 2.2.x). When I try to compile against the Mbed TLS 3.6.2 libraries, I get a bunch of compiler warnings / errors. Most of them are mentioned in the migration guide, but even then, I have a hard time figuring out how to resolve them "the right way". 1. Private fields The migration guide <https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-3.6/docs/3.0-migration-gui…> explains that most structs are now considered private. 1.1: The altcp_mbed module in LWIP relies on the *out_left* field of the *ssl context* struct. /* calculate TLS overhead part to not send it to application */ overhead = state->overhead_bytes_adjust + state->ssl_context.out_left; I am correct that this field is simply not exposed through accessor functions? I can find functions like mbedtls_ssl_get_avail, so I would expect something like mbedtls_ssl_get_bytes_to_write or something like that? 1.2: The altcp_mbed module in LWIP relies on the *start* field of the *ssl session* struct. err_t altcp_tls_set_session(struct altcp_pcb *conn, struct altcp_tls_session *session) { if (session && conn && conn->state) { altcp_mbedtls_state_t *state = (altcp_mbedtls_state_t *)conn->state; int ret = -1; * if (session->data.start)* ret = mbedtls_ssl_set_session(&state->ssl_context, &session->data); return ret < 0 ? ERR_VAL : ERR_OK; } return ERR_ARG; } I also don't know how to obtain this field "the right way". I know this is a bad idea, but it's all I got if (session->data.*private_start)* ... 2. parse key expects a RNG function This is also explained in the migration guide: *Some functions gained an RNG parameterThis affects users of the following functions: `mbedtls_ecp_check_pub_priv()`,`mbedtls_pk_check_pair()`, `mbedtls_pk_parse_key()`, and`mbedtls_pk_parse_keyfile()`.You now need to pass a properly seeded, cryptographically secure RNG whencalling these functions. It is used for blinding, a countermeasure againstside-channel attacks.* Can you please give me some guidance here? I looked for examples in Mbed TLS repo and ended up with this (bold parts are added, using the key_app.c in your repo as leading example): * mbedtls_entropy_context entropy; mbedtls_ctr_drbg_context ctr_drbg; mbedtls_entropy_init(&entropy); mbedtls_ctr_drbg_init(&ctr_drbg); if ((ret = mbedtls_ctr_drbg_seed( &ctr_drbg, mbedtls_entropy_func, &entropy, privkey, privkey_len)) != 0) { // TODO: handle error } * ret = mbedtls_pk_parse_key( conf->pkey, privkey, privkey_len, privkey_pass, privkey_pass_len, *mbedtls_ctr_drbg_random, &ctr_drbg*); 3. The altcp_mbed module in LWIP relies on mbedtls_ssl_flush_output The altcp_mbed module had an include on ssl internal. #include "mbedtls/ssl_internal.h" /* to call mbedtls_flush_output after ERR_MEM */ This header seems no longer part of the library. But the prototype of the function is now part of ssl_misc.h, but I don't think I am supposed to rely on this header either. I have a couple of options: - ignore the compiler warning /home/dev_container/app/thirdparty/lwip/src/apps/altcp_tls/altcp_tls_mbedtls.c:535:5: warning: implicit declaration of function 'mbedtls_ssl_flush_output'; did you mean 'mbedtls_ssl_tls_prf'? [-Wimplicit-function-declaration] 535 | mbedtls_ssl_flush_output(&state->ssl_context); - copy paste the declaration in the LWIP source file - Or.... don't flush any buffers managed by Mbed TLS in the first place? For the last one, I could really use your input. Can you say anything meaningful about the flush (line in bold) In the below function, Is it mandatory? Or can I trust the Mbed TLS will flush the output buffer whenever it needs to get flushed? /** Sent callback from lower connection (i.e. TCP) * This only informs the upper layer the number of ACKed bytes. * This now take care of TLS added bytes so application receive * correct ACKed bytes. */ static err_t altcp_mbedtls_lower_sent(void *arg, struct altcp_pcb *inner_conn, u16_t len) { struct altcp_pcb *conn = (struct altcp_pcb *)arg; LWIP_UNUSED_ARG(inner_conn); /* for LWIP_NOASSERT */ if (conn) { int overhead; u16_t app_len; altcp_mbedtls_state_t *state = (altcp_mbedtls_state_t *)conn->state; LWIP_ASSERT("state", state != NULL); LWIP_ASSERT("pcb mismatch", conn->inner_conn == inner_conn); /* calculate TLS overhead part to not send it to application */ mbedtls_ssl_get_bytes_avail(&state->ssl_context); overhead = state->overhead_bytes_adjust + state->ssl_context.private_out_left; if ((unsigned)overhead > len) { overhead = len; } /* remove ACKed bytes from overhead adjust counter */ state->overhead_bytes_adjust -= len; /* try to send more if we failed before (may increase overhead adjust counter) */ *mbedtls_ssl_flush_output(&state->ssl_context); // Does it make sense this LWIP port is responsible for flushing here??* /* remove calculated overhead from ACKed bytes len */ app_len = len - (u16_t)overhead; /* update application write counter and inform application */ if (app_len) { state->overhead_bytes_adjust += app_len; if (conn->sent) return conn->sent(conn->arg, conn, app_len); } } return ERR_OK; } After applying the changes I mentioned above, the software compiles against Mbed TLS. I haven't dared to run anything, I just want to enjoy this short moment where I have the feeling I achieved something before runtime errors ruin my day :). Many thanks in advance for any reply! Best regards, Bas [image: image.png]

4 months, 3 weeks

1
0
0 0

MbedTLS 2.5 vs MbedTLS 3.6

by Michael Khoyilar

Hi Team I am investigating the move from MbedTLS 2.25 to 3.6, however, our client uses the 2.25 currently (looks like they prefer to stay with it) and I need to provide convincing proof to move to 3.6 considering the upgrade issues that might arise. Any suggestions here that is convincing proof to do the migration to 3.6? I would appreciate your comments. Thanks Michael

4 months, 3 weeks

5
5
0 0

Trying to integrate Mbed TLS (3.6) with LWIP (2.x)

by Bas Prins

Dear Mbed TLS team, I am at the early steps of trying to integrate Mbed TLS with LWIP for our project (imx rt 1024 NXP micro, arm M7, running FreeRTOS and LWIP). I understand the basics of TLS, but I am far from an expert. Let me first apologise for the lengthy first email. I am afraid to leave out details. Feel free to skip directly to the end marked with: ============================= My questions: ============================= Some background / translation of how I think it (should) work: From a distance, I understand that LWIP has an abstraction layer on their TCP module, which can be used to integrate Mbed TLS. In fact, LWIP already did this, all I need to do is enable some directives (LWIP_ALTCP_TLS and LWIP_ALTCP_TLS_MBEDTLS). The implemented integration assumes a somewhat older version of Mbed TLS, so I have to adjust a couple to cope with the breaking changes from Mbed TLS 2.x to Mbed TLS 3.6.2. But other than that, integrating Mbed TLS would mean: - figure out which options i want to enable in Mbed TLS - cross compile it for our arm toolchain - extend our build scripts to compile against 3 static Mbed TLS libraries - figure out how to read the CA certificates, and provide them to Mbed TLS - test and fail, and hopefully be man enough to solve the challenges ahead... I haven't achieved much yet, but at least I managed to compile Mbed TLS with our toolchain and recompile our project against the linked libraries. This steps fails though, I get a bunch of linker errors : [100%] Linking CXX executable app.axf /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_msg.c.obj): in function `mbedtls_ssl_encrypt_buf': /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c:1211:(.text.mbedtls_ssl_encrypt_buf+0x1b4): undefined reference to `mbedtls_cipher_auth_encrypt_ext' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_msg.c.obj): in function `mbedtls_ssl_decrypt_buf': /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c:1638:(.text.mbedtls_ssl_decrypt_buf+0x180): undefined reference to `mbedtls_cipher_auth_decrypt_ext' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_msg.c.obj): in function `mbedtls_ssl_transform_free': /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c:6213:(.text.mbedtls_ssl_transform_free+0x14): undefined reference to `mbedtls_cipher_free' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/thirdparty/mbedtls/library/ssl_msg.c:6214:(.text.mbedtls_ssl_transform_free+0x1e): undefined reference to `mbedtls_cipher_free' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_tls.c.obj): in function `mbedtls_ssl_transform_init': /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:1028:(.text.mbedtls_ssl_transform_init+0x18): undefined reference to `mbedtls_cipher_init' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:1029:(.text.mbedtls_ssl_transform_init+0x22): undefined reference to `mbedtls_cipher_init' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_tls.c.obj): in function `mbedtls_ssl_get_mode_from_ciphersuite': /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:2453:(.text.mbedtls_ssl_get_mode_from_ciphersuite+0x12): undefined reference to `mbedtls_cipher_info_from_type' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_tls.c.obj): in function `mbedtls_ssl_parse_finished': /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:8680:(.text.mbedtls_ssl_parse_finished+0xac): undefined reference to `mbedtls_ct_memcmp' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_tls.c.obj): in function `ssl_tls12_populate_transform': /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:8878:(.text.ssl_tls12_populate_transform+0xa6): undefined reference to `mbedtls_cipher_info_from_type' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:9136:(.text.ssl_tls12_populate_transform+0x454): undefined reference to `mbedtls_cipher_setup' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:9142:(.text.ssl_tls12_populate_transform+0x476): undefined reference to `mbedtls_cipher_setup' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:9148:(.text.ssl_tls12_populate_transform+0x4a8): undefined reference to `mbedtls_cipher_setkey' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/thirdparty/mbedtls/library/ssl_tls.c:9155:(.text.ssl_tls12_populate_transform+0x4da): undefined reference to `mbedtls_cipher_setkey' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: CMakeFiles/app.dir/home/dev/app/thirdparty/lwip/src/apps/altcp_tls/altcp_tls_mbedtls.c.obj: in function `altcp_mbedtls_sndbuf': /home/dev/app/thirdparty/lwip/src/apps/altcp_tls/altcp_tls_mbedtls.c:1192:(.text.altcp_mbedtls_sndbuf+0x7e): undefined reference to `mbedtls_ssl_get_max_frag_len' /opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: /home/dev/app/source/iobox-app/../../thirdparty/mbedtls/build/library/libmbedtls.a(ssl_tls12_server.c.obj): in function `ssl_parse_client_psk_identity': /home/dev/app/thirdparty/mbedtls/library/ssl_tls12_server.c:3638:(.text.ssl_parse_client_psk_identity+0xb6): undefined reference to `mbedtls_ct_memcmp' The distinct list undefined references of the above: undefined reference to `mbedtls_cipher_auth_encrypt_ext' undefined reference to `mbedtls_cipher_auth_decrypt_ext' undefined reference to `mbedtls_cipher_free' undefined reference to `mbedtls_cipher_init' undefined reference to `mbedtls_cipher_info_from_type' undefined reference to `mbedtls_ct_memcmp' undefined reference to `mbedtls_cipher_setup' undefined reference to `mbedtls_cipher_setup' undefined reference to `mbedtls_cipher_setkey' undefined reference to `mbedtls_cipher_setkey' undefined reference to `mbedtls_ssl_get_max_frag_len' All except the last one are coming from Mbed TSL internally, so I *guess* this means I am missing options? Or maybe I am still having too many? The last one is called from the LWIP integration of Mbed TLS, and I could "sweep this under the carpet" by disabling "MBEDTLS_SSL_MAX_FRAGMENT_LENGTH". But I haven't looked further in what I cause if I do not support "RFC 6066 max_fragment_length extension in SSL" My Mbed TLS configuration: I followed the suggestion of your documentation, and went for a minimal example configuration. Pure on intuition, I went for "config-ccm-psk-dtls1_2.h". Because the file name suggests it brings TSL 1.2 which is basically all I need. I think. I did had to make the following changes in order to be able to compile it: 1. Comment out two defines in order to get rid of module requiring "windows or unix" //#define MBEDTLS_NET_C //#define MBEDTLS_TIMING_C 2. Add a define, again to get rid of the compiler error "require windows or unix" #define MBEDTLS_NO_PLATFORM_ENTROPY After applying these small changes to the include/mbedtls/mbedtls_config.h I was able to cross compile (and link) Mbed TLS with arm-none-eabi toolchain. Once I adjusted the build scripts to lnk against the Mbed TLS static libraries, I finally ended up with the earlier mentioned linker errors. ============================= My questions: ============================= 1. Does my starting point configuration make sense? As mentioned earlier, pure intuition made me try the "config-ccm-psk-dtls1_2.h" configuration example, which after some modifications compiled and produced 3 static libraries. but, this bit in the example header worries me a bit: * Distinguishing features: * - Optimized for small code size, low bandwidth (on an unreliable transport), * and low RAM usage. * - No asymmetric cryptography (no certificates, no Diffie-Hellman key * exchange). * - Fully modern and secure (provided the pre-shared keys are generated and * stored securely). * - Very low record overhead with CCM-8. * - Includes several optional DTLS features typically used in IoT. What does "no asymmetric cryptography" exactly mean? Isn't that the pure basis of TLS altogether? If I want to achieve HTTPS using TLS, is this a good starting point? 2. Undefined references: wrong configuration, or should I supply some of the implementations? As mentioned before, I have quite a few linking errors related to the cipher module. I tried to find answers in the documentation, but came up empty. I assume (again...) that I should be able to get rid of these linking errors by enabling more features in Mbed TLS. But I honestly get lost in #define's. And maybe it's documented somewhere, but I couldn't find it. 3. Root CA provided by me? I assume I *need* to provide at least one root CA for Mbed TLS to be able to verify the public key provided by the server, at some point, right? I would expect some callback I need to implement where such a root CA was read (in my case, i would have to read if from flash). Am I misunderstanding Mbed TLS on this aspect also? Or did I just miss the obvious spot where to Mbed TLS requests a root CA? 4. More examples available for typical microcontroller projects (FreeRTOS/LWIP)? My experience so far is: - Mbed TLS is well documented - LWIP is no longer actively maintained, and lacks documentation in general - Google finds a painful amount of LWIP/TLS integrations which are based on really old implementations of both, which does more harm than good for me - Chat GPT knows everything, even when it doesn't, which is a really great recipe to get on the wrong track... It doesn't seem rather helpful on my integration questions for Mbed TLS/LWIP. Disclaimer: could be that my lack of knowledge is causing gpt to come up with wrong answers of course... I understand that my email is (too?) long, and that the chance somebody will actually find the time to help me out is limited. I expect nothing, I hope for everything :) ANY help is more than welcome. Good references, links to official documentation I missed, or in the best case: answers to my questions/uncertainties. Many thanks in advance. Best regards, Bas

4 months, 3 weeks

2
1
0 0

TLS 1.3 and brainpool curves

by Maren Konrad

Dear MbedTLS maintainers, we are already using MBedTLS, however, we recently enabled TLS 1.3 and found that our certificates doesn't work anymore, because they are brainpoolP256r1 (https://datatracker.ietf.org/doc/html/rfc8734). So the question would be, if I missed any configuration to enable the usage of brainpool curves (which are working for TLS 1.2) or if there are any plans, that these are getting supported by MBedTLS 3.6.x? Best regards, Maren Konrad

5 months, 2 weeks

2
1
0 0

Confirm if there is an upgrade to the PKCS#1 V2.2 standard.

by Elva Huang

Dear mbedtls platform, I would like to inquire whether the PKCS#1 standard in the source code of mbedtls V2.28.2 has been upgraded to V2.2. From which version does mbedtls start supporting PKCS#1 v2.2? Looking forward to your reply, thank you. Elva Huang | SW Engineer Tel: 18150372635 Email:elva.huang@robosense.cn<elva.huang(a)robosense.cn> 深圳市 - 南山区 - 速腾聚创产品中心 [image]<http://www.robosense.cn/> [image]<https://www.linkedin.com/company/13232246/admin/>[image]<https://twitter.com/RoboSenseLiDAR>[image]<https://www.facebook.com/RoboSenseLiDAR/>[image]<https://www.youtube.com/channel/UCYCK8j678N6d_ayWE_8F3rQ>

5 months, 2 weeks

2
1
0 0

How to export mbedtls_snprintf ?

by Gal Rosen

Hi, I am trying to build lief which is dependent on mbedtls as a static library. I am using conan recipe to build using cmake. The build of the library succeeded, however later while trying to build my own application and link with lief I get the following error: LIEF.lib(x509.obj) : error LNK2001: unresolved external symbol mbedtls_snprintf What do I do wrong? Or should I configure something while building the mbedtls library ? Thanks, Gal.

5 months, 3 weeks

1
0
0 0

Question about contribution of AES hardware support for RISC-V

by Rick Chen

Dear Mbed TLS maintainers, I have surveyed Mbed TLS and know that it has features which can improve AES block cipher performance by hardware instructions instead of SW implementation e.q., AESCE of ARMV8 and AESNI of INTEL. AS far as I know about RISC-V Cryptography extension(Zkne and Zknd), it also supports relevant AES instructions which can accelerate aes key schedule, encryption and decryption process. (https://tools.cloudbear.ru/docs/riscv-crypto-spec-scalar-1.0.0-rc6-20211012…) I want to ask for your opinions and agreement. Is there any willingness to accept this RISC-V accelerated feature idea and contribution to Mbed TLS ? If you agree with it, I would like to prepare a pull request for you to review. Sincerely, Rick

6 months, 1 week

2
1
0 0

Mbed TLS 3.6.2 release

by David Horstmann

Dear Mbed TLS users, We have released Mbed TLS version 3.6.2. This release provides a security fix for an out-of-bounds write vulnerability in the pkwrite module. Full details are available in the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.2 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Many thanks, David Horstmann Mbed TLS developer

6 months, 2 weeks

1
0
0 0

Checking that RSA key and issuer certificate match using mbedTLS 3.x

by Fabian Keil

Hi, I'm currently working on adding mbedTLS 3.x support for Privoxy [0]. Everything seems to be working but I ifdef'ed out the following code in [1] that worked with mbedTLS 2.28.8: /* * Check if key and issuer certificate match */ if (!mbedtls_pk_can_do(&issuer_cert.pk, MBEDTLS_PK_RSA) || mbedtls_mpi_cmp_mpi(&mbedtls_pk_rsa(issuer_cert.pk)->N, &mbedtls_pk_rsa(*issuer_key)->N) != 0 || mbedtls_mpi_cmp_mpi(&mbedtls_pk_rsa(issuer_cert.pk)->E, &mbedtls_pk_rsa(*issuer_key)->E) != 0) { log_error(LOG_LEVEL_ERROR, "Issuer key doesn't match issuer certificate"); ret = -1; goto exit; } As N and E are private now it no longer compiles. Is there a way to implement the check with mbedTLS 3.x? My impression is that the sanity check is overly cautious and we don't have equivalent code for OpenSSL and wolfSSL but I'm curious. Thanks, Fabian [0] <https://www.privoxy.org/> [1] <https://www.privoxy.org/gitweb/?p=privoxy.git;a=blob;f=ssl.c;h=e8007cd9adad…>

6 months, 2 weeks

2
2
0 0

Client Certificate Request Question

by Michael Reutman

Hello, I'm running into an issue with using Mbed-TLS on an embedded device of ours and I'm curious if anyone would be able to point me in the right direction. If this is the wrong channel for general use questions, let me know and I'll search elsewhere. As a forewarning, I'm still getting my bearings around the nuts and bolts of Mbed-TLS and network security; apologies if I misstate something or jumble things up. Our device uses Mbed-TLS 3.0.0; ideally I'd like to upgrade this to a newer version, but this version was included in a SDK package for our device and I'd like to get some basic functionality proven out first before trying to reintegrate a newer version into the rest of provided code. The current goal is to get our device to serve a web page over HTTPS with TLS. What we currently see is that the initial hello client and server messages are exchanged without issue, but the connection is rejected after the server requests a certificate from the client. In some browsers, this opens a prompt where you can select a given certificate on the machine; in others, it skips this prompt and sends a response back with an empty certificate. In both instances, the server will return an error and deny the connection. This seems like some sort of user configuration error, given your average web page served over HTTPS on the internet avoids making this request. The literature I've been able to find so far also seems to suggest this request is entirely optional. Is there some option I'm overlooking that makes the server skip asking the client for its certificate and lets connection continue on? Michael Reutman Senior Embedded Software Engineer NovaTech Automation 261 Brodhead Rd. Bethlehem, PA 18017 novatechautomation.com<http://www.novatechautomation.com/> | NovaTechLinkedIn<https://www.linkedin.com/company/565017> NovaTech Automation is Net Zero committed. #KeepItCool<https://www.keepitcool.earth/> Receipt of this email implies compliance with our terms and conditions<https://www.novatechautomation.com/email-terms-conditions>.

6 months, 3 weeks

2
2
0 0

Problem when parsing certificate without Distinguished Name

by Diego Santos

Hi, I'm trying to parse this DER encoded certificate in hex format: 3082018230820128a003020102020900f3b305f55622cfdf300a06082a8648ce3d04030230003020170d3735303130313030303030305a180f34303936303130313030303030305a30003059301306072a8648ce3d020106082a8648ce3d0301070342000458f7e9581748ff9bdd933b655cc0e5552a1248f840658cc221dec2186b5a2fe4641b86ab7590a3422cdbb1000cf97662f27e5910d7569f22feed8829c8b52e0fa38188308185308182060a2b0601040183a25a01010101ff0471306f042508021221026b053094d1112bce799dc8026040ae6d4eb574157929f1598172061f753d9b1b04463044022040712707e97794c478d93989aaa28ae1f71c03af524a8a4bd2d98424948a782302207b61b7f074b696a25fb9e0059141a811cccc4cc28042d9301b9b2a4015e87470300a06082a8648ce3d04030203480030450220143ae4d86fdc8675d2480bb6912eca5e39165df7f572d836aa2f2d6acfab13f8022100831d1979a98f0c4a6fb5069ca374de92f1a1205c962a6d90ad3d7554cb7d9df4 This certificate is part of a simple test for this specification https://github.com/libp2p/specs/blob/master/tls/tls.md I'm using this https://github.com/status-im/nim-mbedtls Nim language library wrapper for mbedtls. I don't know the mbedtls version exactly, but the lib is based on this commit https://github.com/Mbed-TLS/mbedtls/tree/09d23786f6fdcb4dfa88aad30c8767bd27…. In my code I use: proc parseUnverified*(derInput: seq[byte]) = var crt: mbedtls_x509_crt mbedtls_x509_crt_init(addr crt) var ret = mbedtls_x509_crt_parse_der(addr crt, unsafeAddr derInput[0], derInput.len.uint) if ret != 0: raise newException(Exception, "Failed to parse certificate, error code: " & $ret) which is a straightforward version of the C code, but ti fails with: Failed to parse certificate, error code: -9186 [Exception] It seems the problem is because the certificate doesn't have the Distinguished Name set. Does it make sense? If this is really the cause of the problem, is there any workaround? Regards.

7 months

1
0
0 0

Need Info : mbedtls_x509_get_sig_alg API

by Satya Prakash Prasad

Hi, We were using old MBed TLS version 2.19.1 and existing trusted CA certificates were working fine in that release. Recently we upgraded to 3.6.0 and see that now certificate parsing is returning -ox262e value from function mbedtls_x509_get_sig_alg cause of which handshake is not even initiated. Can you please let us know what can cause such an issue and remedy the same? Regards, Prakash

7 months

1
2
0 0

Looking for suggestions about make Mbed TLS APIs non-secure callable APIs on armv8m

by Lee, William

Hi Mbed TLS, I am looking for some suggestions about make some (or all) Mbed TLS APIs non-secure callable APIs on armv8m. The background is that I am going to have a secure firmware that provides encryption services by building part (or whole) of Mbed TLS into that firmware and make those original mbedtls_x APIs non-secure callable, so the existing non-secure firmware could link those non-secure callable APIs and use them. Some of my thoughts: (1) The easiest way to do it I can think of is just add the attribute "cmse_nonsecure_call" to those APIs' declaration (or use a macro to wrap the attribute for conditional build to not impact others don't want it), but I do not think this modification could be accepted by upstream 🙂. (2) So my another thought is duplicate all header files and put them under another folder, assuming it is my-include folder, then I can do whatever I want to my-include folder, but there is also a problem I can think of: a merge/compare burden between include and my-include folder after I have updated Mbed TLS. I really appreciate other suggestions! Thanks, William

7 months

3
3
0 0

Reminder: MBed TLS Tech Forum - US/Europe

by Don Harbin

Hi All, A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum is next Monday at 4:30pm UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Janos know. :) Don

7 months, 1 week

1
0
0 0

Setting ciphersuite causes MBEDTLS_ERR_SSL_ILLEGAL_PARAMETER

by Mbed TLS

My mbedtls client has been working for 2 years. It did what I required and has been stable. However, I now need to force a new server to use my preferred cipher suite. I found the helper function to force the cipher suite here: https://github.com/Mbed-TLS/mbedtls/blob/de4d5b78558666d2e258d95e6c5875f9c7… I added mbedtls_ssl_conf_preference_order(conf, MBEDTLS_SSL_SRV_CIPHERSUITE_ORDER_CLIENT) to the end of the function to force the server to choose my ciphersuite. Prior to this change I called the mbedtls functions in this chronological order: mbedtls_ssl_init(&_ssl); mbedtls_ssl_config_init(&_conf); mbedtls_ctr_drbg_init(&_ctr_drbg); mbedtls_entropy_init(&_entropy); mbedtls_x509_crt_init(&_cacert); mbedtls_pk_init(&_pkey); mbedtls_ctr_drbg_seed mbedtls_ssl_config_defaults mbedtls_ssl_conf_rng mbedtls_ssl_conf_authmode mbedtls_x509_crt_parse_file mbedtls_ssl_conf_ca_chain mbedtls_ssl_setup mbedtls_ssl_set_hostname and then proceed to call: mbedtls_ssl_set_bio mbedtls_ssl_handshake Now: If I call mbedtls_ssl_conf_ciphersuites BEFORE mbedtls_ssl_config_defaults, the ciphersuite list is ignored/seems to get overriden. If I call mbedtls_ssl_conf_ciphersuites AFTER mbedtls_ssl_config_defaults, my ciphersuite list changes are accepted and transmitted (I can see in Wireshark). The server then responds agreeing to use my chosen cipher suite. However, mbedtls_ssl_handshake returns with value -26112, which I have looked up to be MBEDTLS_ERR_SSL_ILLEGAL_PARAMETER. Unfortunately I have no clue what is causing this. Could somebody please advise how this should be done? I can see Client2 example but there are functions I have which are not in there. Client1 seems too simple for me but Client2 seems beyond what I require.

7 months, 2 weeks

2
5
0 0

Connect using IP address instead of URL "509 - Certificate verification failed, e.g. CRL, CA or signature check failed"

by M M

I am using MbedTLS client code based on this: https://github.com/machinezone/IXWebSocket/blob/master/ixwebsocket/IXSocket… I am connecting to a server via it's URL. However, I would like to connect directly using an IP address returned from running the traceroute command on the URL. So I replaced the URL with the IP address. However, MBedTLS fails on the handshake: https://github.com/machinezone/IXWebSocket/blob/master/ixwebsocket/IXSocket… I get the error: "error in handshake : X509 - Certificate verification failed, e.g. CRL, CA or signature check failed" If I revert back to URL, it works. The IP address does exist. How can I connect using the IP address, instead of the URL?

7 months, 2 weeks

3
3
0 0

Re: mbedtls and PQC algorithms support

by Raunak Gupta

Micron Confidential Hi, I find that mbed-tls already support LMS, could you please Point to some reference and starting from which version mbedTLS lib version supports LMS? Best Regards, Raunak Get Outlook for iOS<https://aka.ms/o0ukef> Micron Confidential

7 months, 3 weeks

2
1
0 0

Re: [EXT] RE: Inquiry About PQC Cryptos in embedTLS Library

by Raunak Gupta

Micron Confidential Dear MbedTLS, Can you please help to provide some references for LMS stateful signatures schemes support in MbedTLS, May be something like documentation and github repo link? Unfortunately I am not able to find it online? Thanks, Raunak Get Outlook for iOS<https://aka.ms/o0ukef> Micron Confidential ________________________________ From: Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com> Sent: Tuesday, September 3, 2024 8:48 PM To: Raunak Gupta <raunakgupta(a)micron.com>; enquiries(a)trustedfirmware.org <enquiries(a)trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [EXT] RE: Inquiry About PQC Cryptos in embedTLS Library Micron Confidential CAUTION: EXTERNAL EMAIL. Do not click links or open attachments unless you recognize the sender and were expecting this message. Hi Raunak, Mbed TLS today supports LMS stateful hash-based signature scheme. While supporting other PQC algorithms is in the Mbed TLS project roadmap, the team isn’t actively working on it. The focus for the team now is preparing for Mbed TLS 4.0. Feel free to ask any further technical questions in the Mbed TLS public mailing list - mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> (https://lists.trustedfirmware.org/mailman3/lists/mbed-tls.lists.trustedfirm…) Regards, Shebu Micron Confidential From: 'Raunak Gupta' via TFenquiries <enquiries(a)trustedfirmware.org> Sent: Tuesday, September 3, 2024 2:34 AM To: enquiries(a)trustedfirmware.org Subject: Inquiry About PQC Cryptos in embedTLS Library Micron Confidential Dear Trusted Firmware Team, I hope this message finds you well. My name is Raunak, and I am a Security Engineer at Micron Technology. I would like to inquire whether the embedTLS library has been updated to include Post-Quantum Cryptography (PQC) algorithms such as LMS, HSS, and XMSS. Additionally, is the embedTLS team actively working on integrating these PQC algorithms? Thank you for your assistance. Best regards, Raunak Micron Confidential To unsubscribe from this group and stop receiving emails from it, send an email to enquiries+unsubscribe(a)trustedfirmware.org<mailto:enquiries+unsubscribe@trustedfirmware.org>.

7 months, 3 weeks

1
0
0 0

Mbed TLS 3.6.1 and 2.28.9

by David Horstmann

Dear Mbed TLS users, We have released Mbed TLS versions 3.6.1 and 2.28.9. These releases provide bugfixes, security fixes and minor improvements. The 3.6.1 release includes fixes for issues caused by enabling TLS 1.3 for TLS connections in the default configuration. Full details are available in the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-2.28.9 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.1 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Many thanks, David Horstmann Mbed TLS developer

8 months

1
0
0 0

Mbed TLS 4.0 roadmap and bignum/ecp API

by Gernot Kvas

Hi all, From the announcement and also the long term plans (https://mbed-tls.readthedocs.io/en/latest/project/long-term-plans/) it is apparent that bignum/ecp operations on the public API will go away and usage will be restricted to internal only. I do understand and welcome the shift towards PSA API and to abandon the ALT interface for higher level legacy API crypto functions. However, I'm not so positive about removal of the bignum and ecp API. There are projects using those functions even in their PSA porting layer (Matter comes to mind: https://github.com/project-chip/connectedhomeip/blob/master/src/crypto/CHIP…) or projects using the bignum layer as abstraction (Zephyr hostap/wpa_supplicant: https://github.com/zephyrproject-rtos/hostap/tree/main/src/crypto, crypto_mbedtls*.c). There might be a case to support those functions to have (hardware-accelerated) low level building blocks for algorithms Mbed TLS doesn't yet or never will support. As other SSL libraries such as OpenSSL also expose similar API (BN_ and EC_POINT_ ), the removal in Mbed TLS will certainly leave a gap. What's the view here from the project team? Cheers, Gernot

8 months

2
1
0 0

Requesting information for mbed-tls commercial license & support

by Kumar, Praveen

Hi, We are in the process of qualifying a suitable encryption library for our pre-hospital patient monitor and the telemedicine system. I am writing to request your guidance regarding the mbed-tls use for commercial purposes. I look forward to your response. Regards, Praveen Kumar R&D Project Manager Emergency Care Professional (EC-Pro) Philips Tel +44 (0) 1256 362427 Email praveen.m.kumar(a)philips.com<mailto:praveen.m.kumar@philips.com> Remote Diagnostic Technologies Limited. Registered office: Ascent 1, Farnborough Aerospace Centre, Aerospace Boulevard, Farnborough GU14 6XW, UK. Registered in England No. 3321782. [Logo Description automatically generated]<http://www.philips.com/> Connect with Philips [cid:image002.gif@01DAE7F8.0802FC50]<https://www.linkedin.com/company/philips/>[cid:image003.gif@01DAE7F8.0802FC50]<https://twitter.com/PhilipsHealth>[cid:image004.gif@01DAE7F8.0802FC50]<https://www.youtube.com/PhilipsHealthcare/videos> ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

8 months, 1 week

3
6
0 0

Major changes in Mbed TLS 4.0

by Gilles Peskine

Hello, Following consultations with the community and internal discussions among the Mbed TLS maintenance team, we can now present the major changes that will happen in the next major version of Mbed TLS. Our plan remains to release in the second quarter of 2025. The next major version will focus on two things: 1. The cryptography library will be a separate product called TF-PSA-Crypto 1.0. The X.509 and TLS library will be called Mbed TLS 4.0, and will rely on TF-PSA-Crypto for all cryptographic functionality. 2. This release completes the migration of cryptography APIs from classic mbedtls APIs to PSA APIs. Please find more information below about what this means in practice. What follows are just headlines, not an exhaustive list of changes. We expect many small changes that do not affect major functionality. Please note that the changes presented here are our current plan. We may revise it based on new inputs, new insights or unexpected hurdles. You can follow the advancement of the design, planning and development of the next release on the 4.0+1.0 planning board at https://github.com/orgs/Mbed-TLS/projects/15/views/1 . Removal of legacy APIs The following low-level application interfaces will no longer be present in the API of TF-PSA-Crypto 1.0 and Mbed TLS 4.0: * Hashes: hkdf.h, md5.h, ripemd160.h, sha1.h, sha3.h, sha256.h, sha512.h; * Random generation: ctr_drbg.h, hmac_drbg.h, entropy.h; * Ciphers and modes: aes.h, aria.h, camellia.h, chacha20.h, chachapoly.h, cipher.h, cmac.h, gcm.h, poly1305.h; * Private key encryption mechanisms: pkcs5.h, pkcs12.h. * Asymmetric cryptography: bignum.h, dhm.h, ecdh.h, ecdsa.h, ecjpake.h, ecp.h, rsa.h. The cryptographic mechanisms remain present, but they will only be accessible via the PSA API (psa_xxx functions introduced gradually starting with Mbed TLS 2.17). If you maintain code that uses these interfaces, you can already start migrating it today, since almost all PSA interfaces are available in the mbedtls-3.6 long-time support branch (and many even in 2.28 LTS). Please consult the PSA transition guide https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-3.6/docs/psa-transition.md for guidance. Some non-PSA crypto interfaces will still be present in TF-PSA-Crypto 1.0: * pk.h will remain with some changes, mainly to provide an interface to key parsing and formatting which does not have a PSA equivalent yet. * md.h will remain as a thin layer over PSA hash functions (not HMAC) to ease the transition. * nist_kw.h will remain because it does not have a PSA equivalent yet. Removal of legacy integration interfaces TF-PSA-Crypto 1.0 and Mbed TLS 4.0 will no longer support MBEDTLS_xxx_ALT replacement of functions and modules. Use PSA transparent drivers instead. TF-PSA-Crypto 1.0 and Mbed TLS 4.0 will no longer support MBEDTLS_PK_RSA_ALT and MBEDTLS_PSA_CRYPTO_SE_C. Use PSA opaque drivers instead. TF-PSA-Crypto 1.0 and Mbed TLS 4.0 will no longer have the mbedtls/entropy.h interface to configure entropy sources. This will be replaced by PSA random drivers. In addition, we are planning to rework the platform abstraction layer (MBEDTLS_PLATFORM_xxx configuration options). More details will be available in the coming months. Removal of legacy mechanisms The following cryptographic mechanisms are planned to be removed in TF-PSA-Crypto 1.0 and Mbed TLS 4.0: * DES (including 3DES). * PKCS#1v1.5 encryption/decryption (RSAES-PKCS1-v1_5). (OAEP, PSS, and PKCS#1v1.5 signature are staying.) * Finite-field Diffie-Hellman with custom groups. (RFC 7919 groups remain supported.) * Elliptic curves of size 225 bits or less. The following cipher suites are planned to be removed from (D)TLS 1.2 in Mbed TLS 4.0: * TLS_RSA_* (including TLS_RSA_PSK_*), i.e. cipher suites using RSA decryption. (RSA signatures, i.e. TLS_ECDHE_RSA_*, are staying.) * TLS_ECDH_*, i.e. cipher suites using static ECDH. (Ephemeral ECDH, i.e. TLS_ECDHE_*, is staying.) * TLS_DHE_*, i.e. cipher suites using finite-field Diffie-Hellman. (Ephemeral ECDH, i.e. TLS_ECDHE_*, is staying.) * TLS_*CBC*, i.e. all cipher suites using CBC. Non-functional changes Due to the separation into two separate products (TF-PSA-Crypto and Mbed TLS), there will be major changes to the directory structure and to the build system. We plan to use CMake as the primary build system. Since TF-PSA-Crypto is a new product, identifiers that are not PSA interfaces (such as optimisation options and platform interfaces) will be renamed with a new prefix. Best regards, -- Gilles Peskine Mbed TLS developer

8 months, 2 weeks

3
4
0 0

Usage of ECB in AES mode

by Chaitanya Tata

Hi, ECB is unsecure, see https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_cod… and shouldn't be used in production. So, I have switched to one of CBC/CMAC/CTR modes, but in `mbedtls_cipher_cmac_starts` I see that it only accepts ECB variants, and also doesn't seem to be using the `type`. From https://github.com/Mbed-TLS/mbedtls/issues/8617 I see that ECB for AES was intentional, even for the CMAC API. Is this expected? 1. Is using ECB for CMAC API correct? 2.Shouldn't we remove the ECB altogether? Appreciate any clarifications. Cheers, Chaitanya.

8 months, 2 weeks

2
4
0 0

[Hyosung TNS] Request a quote for embedded encryption library

by SHIN JAE WHAN(신재환)

Dear Trusted Firmware, I’m Jay, an embedded security firmware developer at Hyosung TNS<https://global.hyosunginnovue.com/?lang_switch>. We are a company that manufactures ATMs. For cryptographic communication between ATM PC software and ATM devices, we are looking for a cryptographic library to apply to ATM devices(e.g. cash dispenser). If there is an appropriate library that meets the requirements below, I would appreciate it if you could provide us an estimate. If custom development is required, I would also like to know the expected development period. [Development environment] - CPU : TI AM1806(ARM9) - Compiler : ARM DS-5(armcc) - RTOS : ThreadX - C language - No dynamic allocation - VFP(Vectored Floating Point) not supported [Security Features] - RSA(2048bits) : Certificate and signature verification, Data encryption and decryption - ECC(256bits) : Generating a symmetric key using ECDH and ECDSA - 3DES, AES, AEAD, SHA256, HMAC256, etc : Algorithms related to data encryption and decryption - Random : Prevent replay attacks Please contact me if you have any questions. Best Regards, Jay [cid:image001.png@01DAE289.1B3D4C90] Jaewhan Shin Performance Manager | CISSP | Firmware Development Team Suseo Bldg., 281, Gwangpyeong-ro, Gangnam-gu, Seoul, 06349 Korea t. 82-2-6181-2480, m. 82-10-8158-3015 e. jaewhan.shin(a)hyosung.com<mailto:jaewhan.shin@hyosung.com> hyosunginnovue.com<https://hyosunginnovue.com/> [cid:image002.png@01DAE289.1B3D4C90]<https://www.linkedin.com/company/hyosung-tns/> [cid:image003.png@01DAE289.1B3D4C90] <https://www.youtube.com/@hyosungtns3918> HYOSUNG TNS, Inc. Email Disclaimer. This communication, including attachments, is intended only for the exclusive use of addressee and may contain proprietary, confidential, or privileged information. Any use, review, duplication, disclosure, dissemination, or distribution is strictly prohibited. If you were not the intended recipient, and you have received this communication in error, please notify sender immediately by return e-mail, delete this communication, and destroy any copies.

9 months

1
0
0 0

TLS 1.3 failures in Mbed TLS 3.6.0

by Gilles Peskine

Hello, Mbed TLS 3.6.0 was the first release to enable TLS 1.3 support by default. Unfortunately, this breaks many applications that open a TLS connection with default settings, which are now negotiating TLS 1.3 instead of TLS 1.2, but hit a difference in how Mbed TLS 3.6.0 implements the two versions of the protocol. The most common symptom is: you are using the default configuration (or something close), and your application fails in the handshake with an internal error whenever it negotiates TLS 1.3. To resolve this, call psa_crypto_init() before starting a TLS handshake. For a list of other known issues, please see https://github.com/Mbed-TLS/mbedtls/issues/9223 If you are encountering a problem due to the enablement of TLS 1.3 that is not listed on that page, please let us know by opening an issue on GitHub. If no workaround or patch is available for your problem yet, you can disable TLS 1.3 by calling mbedtls_ssl_conf_max_tls_version(ssl_config, MBEDTLS_SSL_VERSION_TLS1_2) before mbedtls_ssl_setup(). We are planning to fix all the issues listed on that page before the 3.6.1 patch release. We do not yet have a date for the 3.6.1 release. Best regards, -- Gilles Peskine Mbed TLS developer

9 months

2
1
0 0

TLS-Exporter in TLS 1.3

by Maximilian Fillinger

Hello! I am trying to add TLS 1.3 support to OpenVPN when using Mbed TLS as the TLS library. My current roadblock is that OpenVPN needs the TLS-Exporter functionality (RFC 8446, Section 7.5). For TLS 1.2, we get the master secret through mbedtls_ssl_set_export_keys_cb() and then implement the exporter using mbedtls_ssl_tls_prf(). For TLS 1.3, an approach like this doesn't work because the callback isn't called with the exporter master secret. Am I missing anything, or does this feature not yet exist? Are there any plans to add it? If not, I'd be interested in trying to make a patch. Best regards, Max

9 months, 2 weeks

2
1
0 0

bestwritercontent

by hma3yf39＠mediaholy.com

https://www.bestwritercontent.com A man was going to the house of some rich person. As he went along the road, he saw a box of good apples at the side of the road. He said, "I do not want to eat those apples; for the rich man will give me much food; he will give me very nice food to eat." Then he took the apples and threw them away into the dust. He went on and came to a river. The river had become very big; so he could not go over it. He waited for some time; then he said, "I cannot go to the rich man's house today, for I cannot get over the river." He began to go home. He had eaten no food that day. He began to want food. He came to the apples, and he was glad to take them out of the dust and eat them.

9 months, 2 weeks

1
0
0 0

[Mbed-tls-announce] Requests for feedback about Mbed TLS 4: summary

by Gilles Peskine via Mbed-tls-announce

Hello, In the past few weeks, we have sent a number of requests for feedback on the mbed-tls mailing list about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4.0). Most are about features that we may remove because we think they are not used much and are not worth maintaining. This message is a summary of the requests. If you have concerns about any of these topics, please reply on the GitHub issue (preferred), or on the mbed-tls mailing list, or by private email. (If you reply privately, we will anonymize before sharing outside Arm.) Please reply before 31 July so that we have time to plan 4.0 preparation. While we won't ignore later replies, they will be harder to accommodate. List archive: https://lists.trustedfirmware.org/archives/search?count=25&q=feedback&page=… GitHub links — cryptographic mechanisms https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/102 — Custom ECC mechanisms https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/104 — Custom RSA mechanisms https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/105 — Import of incomplete RSA private keys https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/107 — Direct access to CTR_DRBG and HMAC_DRBG https://github.com/Mbed-TLS/mbedtls/issues/8459 — RSA PKCS#1v1.5 encryption https://github.com/Mbed-TLS/mbedtls/issues/9164 — DES (including 3DES) GitHub links — cryptography implementations https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/103 — Partial ECC acceleration https://github.com/Mbed-TLS/mbedtls/issues/8151 — Dynamically registered secure element drivers GitHub links — TLS 1.2 https://github.com/Mbed-TLS/mbedtls/issues/5278 — FFDH in TLS 1.2 https://github.com/Mbed-TLS/mbedtls/issues/8170 — RSA decryption cipher suites (RSA without DH/ECDH) https://github.com/Mbed-TLS/mbedtls/issues/9201 — Static ECDH cipher suites https://github.com/Mbed-TLS/mbedtls/issues/9202 — CBC cipher suites <https://github.com/Mbed-TLS/mbedtls/issues/9201> GitHub links — platform https://github.com/Mbed-TLS/mbedtls/issues/8108 — Platform interface redesign https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/106 — Building with plain make or CMake https://github.com/Mbed-TLS/mbedtls/issues/8231 — x86_64: AESNI without compiler intrinsics https://github.com/Mbed-TLS/mbedtls/issues/9307 — Support for %zu in printf If you have an opinion on a topic where we haven't requested feedback, you can find our (rapidly evolving) planning board at https://github.com/orgs/Mbed-TLS/projects/15/views/1 . As a reminder, the main focus of the release will be that all cryptography goes through PSA APIs. Low-level legacy cryptography APIs (bignum.h, rsa.h, aes.h, etc.) will no longer be public. Except as indicated here, we generally intend feature parity, but it's possible that we've missed some unusual scenario, so please let us know if you have concerns. Best regards, -- Gilles Peskine Mbed TLS developer 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

9 months, 2 weeks

1
0
0 0

Reminder: MBed TLS Tech Forum - Asia/Europe

by Don Harbin

Hi All, A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech forum is next Monday at 10:00am PM UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org ReplyReply to allForward Compose: Community activity: OpenCV, Sensors, AI [image: Minimise][image: Pop-out][image: Close] Compose: Reminder: MBed TLS Tech Forum - Asia/Europe [image: Minimise][image: Pop-out][image: Close] Recipients

9 months, 2 weeks

1
3
0 0

Can TLS client send `Encrypted Alert 21` to server

by Satya Prakash Prasad

Hi All, We are using the MBedTLS 3.6.0 release stack and often see the TLS client -> server sending Encrypted Alert 21 packets followed by closing the SSL connection (or rather reconnection starting from new handshake messages). As far as I understand Alert 21 is a fatal message stating Decryption of a TLSCiphertext record is decrypted in an invalid way: either it was not an even multiple of the block length or its padding values, when checked, were not correct - copied from the Internet. But then Handshake and Application Data goes thru fine for a while and then we see our client sending Alert 21 encrypted message Is it legitimate that the client can send Alert 21 messages to the server and close the current connection - we are observing that the server application is waiting for messages from the client and is un-aware that a connection reset has occurred. So the server application states a timeout for receiving messages from the client. Further, how can we assert such a scenario? When and how can it occur? Is there a way we can simulate it and send details to owners of server firmware to fix their issue? Regards, Prakash

9 months, 4 weeks

1
0
0 0

FIPS 140-3 compliance of MbedTLS Test suites

by Viktor.Ivanets＠infineon.com

Hi All, We are using MbedTLS on our devices and implementing PSA wrappers to use our Crypto hardware. For validating this one we are using MbedTLS test suites. Could you please tell me: 1. Does your test suites compliant to FIPS 140-3? 2. Do you use NIST test vectors to validate your algorithm implementations? Thanks. Viktor Ivanets.

10 months

1
0
0 0

3.6.0 library size

by Steven Burck

On a project at my company, we're using mbedtls to encrypt and sign our data. We began the project with mbedtls 2.2.6, and have continuously upgraded until now, 3.6.0. I've noticed my application has grown greatly since then, even though we are only using the following APIs: Encryption:(only decryption on the embedded side) - mbedtls_aes_init - mbedtls_aes_setkey_dec - mbedtls_aes_crypt_cbc Signing (only verification on the embedded side) - mbedtls_ecp_point_read_binary - mbedtls_sha256_init/free - mbedtls_sha256_starts_ret - mbedtls_sha256_update_ret - mbedtls_sha256_finish_ret - mbedtls_ecdsa_init/free - mbedtls_ecp_group_load - mbedtls_ecdsa_read_signature The size of libembedcrypto.a has grown from under 400K to almost 800K. I've tried reducing it with mbedtls_config,h, but it is not entirely clear to me which #defines do what. I tried one of the sample configs which by it;s name looked promising (crypto-config-ccm-aes-sha256.h), and it reduced the size of the library by 90%, but left me with link errors for all of the above functions. Going one #define at a time manually to see if it saves or grows is slow, and so I hoped I could find some assistance here. Thanks in advance

10 months

2
2
0 0

Question about random number g

by Zhang, Hao

Hi TF-M and mbedtls community, I am new to TF-M, I have a few questions about CryptoCell and random number generation. Thank you in advance. 1. I figure there seems to have two CryptoCell 312 implementations within TF-M. One under lib/ext/cryptocell-312-runtime and the other under platform/ext/accelerator/cc312/cc312-rom. What are the difference between these two? 2. For lib/ext/cryptocell-312-runtime, it does not define MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG whereas /ext/accelerator/cc312/cc312-rom does. Does that mean cryptocell-312-runtime is initiating RNG cryptodriver by using mbedtls_entropy_add_source whereas cc312-rom is using mbedtls_psa_external_get_random<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…>. If so, may I ask why these two cryptocells take two different approaches? I read from one of the documentation that mbedtls_psa_external_get_random is used when entropy is sufficient. So if entropy is sufficient, is it always preferred to have MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG defined and implements mbedtls_psa_external_get_random? What are the differences between the two approaches. 3. I also found cryptocell-312-runtime defines the entry point function cc3xx_init_random<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…>. But since PSA random number entry point funciton is not complete, the cc3xx_init_random is not being called anywhere, right? [https://opengraph.githubassets.com/17cdebc400b0ed807c620b586b21f3f77ff9c5d3…]<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…> trusted-firmware-m/platform/ext/accelerator/cc312/cc312-rom/psa_driver_api/src/cc3xx_psa_random.c at 8df9cc8baf46252fd188bba1d87333a8daa9a5e8 · zephyrproject-rtos/trusted-firmware-m<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…> Zephyr repository tracking https://git.trustedfirmware.org/trusted-firmware-m.git/ - zephyrproject-rtos/trusted-firmware-m github.com 4. I know random number generation PSA entry point function is in development, may I ask when that would be expected to complete? Thank you very much! Best regards, Hao

10 months

1
0
0 0

Request for feedback about Mbed TLS 4: DRBG interfaces

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/107 Should TF-PSA-Crypto 1.0 (and thus Mbed TLS 4.0) have an interface for *pseudo*-random generation? It will, of course, still have a pseudorandom generator (= deterministic random bit generator = DRBG) internally, to power psa_generate_random(), psa_generate_key(), etc. The question is whether there will still be a public interface to create other DRBG instances, and if so, with what interface. If you want to be able to create instances of HMAC_DRBG and CTR_DRBG from application code in TF-PSA-Crypto 1.0, please let us know what your use case is. In particular, what parameters do you need (HMAC_DRBG and CTR_DRBG have many)? Do you need reseeding, and if so under whose control (the DRBG, or the caller)? In the absence of feedback, it is likely that HMAC_DRBG and CTR_DRBG will not be publicly available. Best regards, -- Gilles Peskine Mbed TLS developer

10 months

1
0
0 0

mbedtls 3.6.0: zero-sized array gives compiler warning (is undefined behavior)

by Almut Herzog

Hi all, I have a custom configuration where MBEDTLS_ECDSA_C is defined but MBEDTLS_PSA_CRYPTO_C and MBEDTLS_PSA_CRYPTO_CONFIG are not. This leads to a compiler warning in e.g. psa_util.c because a zero-sized array is declared (because PSA_VENDOR_ECC_MAX_CURVE_BITS is defined as 0). As of C99, §6.7.5.2 Array declarators: "If the expression is a constant expression, it shall have a value greater than zero." psa_util.c: #if defined(MBEDTLS_PSA_UTIL_HAVE_ECDSA) // Line 368 int mbedtls_ecdsa_raw_to_der(...) // Line 433 unsigned char r[PSA_BITS_TO_BYTES(PSA_VENDOR_ECC_MAX_CURVE_BITS)]; // Line 436 --> becomes in my config: unsigned char r[0]; MBEDTLS_PSA_UTIL_HAVE_ECDSA is automatically defined in my configuration due to the following code in config_adjust_legacy_crypto.h: #if defined(MBEDTLS_ECDSA_C) || (defined(MBEDTLS_PSA_CRYPTO_C) && \ (defined(PSA_WANT_ALG_ECDSA) || defined(PSA_WANT_ALG_DETERMINISTIC_ECDSA))) #define MBEDTLS_PSA_UTIL_HAVE_ECDSA #endif PSA_VENDOR_ECC_MAX_CURVE_BITS only receives a non-zero value if a PSA_WANT_<CURVE>, e.g. PSA_WANT_ECC_BRAINPOOL_P_R1_256, is defined. PSA_WANT_<CURVE> only gets defined in crypto_config.h if MBEDTLS_PSA_CRYPTO_CONFIG is defined (which it is not in my configuration). I have worked around it by explicitly defining e.g. PSA_WANT_ECC_BRAINPOOL_P_R1_256 in my configuration. But I believe there is some mismatch in the defines, at least in this example case, because mbedtls_ecdsa_raw_to_der() is only used in pk_wrap.c if MBEDTLS_USE_PSA_CRYPTO is defined. Impact: * In general, zero-sized arrays have undefined behavior in C (but are allowed by some compiler extensions) and thus behave differently for different compilers --> you might want to review PSA_VENDOR_ECC_MAX_CURVE_BITS and PSA_VENDOR_FFDH_MAX_KEY_BITS (and possibly more definitions) that fall through to 0 and are used as array sizes. * In my particular case, I believe code is compiled that is not needed (defines in psa_util.c and pk_wrap.c do not seem to match)

10 months, 1 week

2
1
0 0

Request for feedback about Mbed TLS 4: size_t printing with %zu

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/mbedtls/issues/9307 Mbed TLS requires a C99 platform, with some pragmatic restrictions. One restriction is that we do not require printf and friends to support %zu for size_t printing. Starting with Mbed TLS 4.0, we are considering requiring printf() and friends (or the mbedtls_printf() and friends alternatives if overridden) to support %zu. This only affects the TLS library, not X.509 and crypto. Is it still necessary in 2025 to support platforms where printf() does not support the z modifier? Best regards, -- Gilles Peskine Mbed TLS developer

10 months, 1 week

1
0
0 0

Request for feedback about Mbed TLS 4 and TF-PSA-Crypto: build system

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/106 We are evaluating build systems for TF-PSA-Crypto, and this will influence the Mbed TLS build as well (the Mbed TLS build scripts will call the TF-PSA-Crypto build scripts, whatever they are). Our current thinking is that we would like to have *CMake as the sole build system*. (We're still investigating whether CMake can do all we need.) That would mean that we would no longer provide GNU makefiles or Visual Studio solutions. As this remains a C project, for just building the library, compiling all the .c files with an include path covering all the .h files will keep working in common cases (but, as today, it isn't something we support officially). The main case I can think of where this wouldn't work is when cryptographic accelerator support requires special includes or compiler flags. Are there environments where the use of CMake is a problem? What is the oldest version of CMake that you'd like us to be compatible with? Best regards, -- Gilles Peskine Mbed TLS developer

10 months, 1 week

1
0
0 0

Request for feedback about Mbed TLS 4: RSA decryption cipher suites

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/mbedtls/issues/8170 We are considering removing support for RSA and RSA-PSK key exchanges in Mbed TLS 4. These are cipher suites that use RSA encryption, as opposed to cipher suites using a key agreement (ECDHE) plus RSA signature. These key exchanges are hard to implement securely (we believe we got it right, but it's very delicate code), and they add significantly to the complexity of the TLS code. They have been formally deprecated for a long time and were removed in TLS 1.3. However, I'm aware that some ecosystems are clinging to RSA key exchange. Are RSA-encryption key exchanges still relevant for Mbed TLS? If you want Mbed TLS 4 to keep supporting RSA-encryption cipher suites in TLS 1.2, please let us know and tell us about your use cases. Best regards, -- Gilles Peskine Mbed TLS developer

10 months, 1 week

1
1
0 0

Request for feedback about Mbed TLS 4: AESNI without compiler intrinsics

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/mbedtls/issues/8231 We currently have two implementations of accelerated AES on x86_64 using AESNI (Intel AES acceleration): using assembly or using compiler intrinsics. The assembly code works with GCC and Clang without any compilation options, but not with MSVC. The intrinsics work with MSVC, but not with ancient GCC/Clang and they require compiling at least aesni.c with suitable CPU variant options (e.g. -maes -mpclmul for Clang). We're considering removing the assembly implementation. Is there still interest in compiling AESNI support with older compilers or with simple build systems that don't pass machine options? Best regards, -- Gilles Peskine Mbed TLS developer

10 months, 1 week

1
0
0 0

How to read ecp private key

by arun.lal＠intel.com

I am generating a ECP key in following way. And now how do I get the private key? TEE_Result gen_ec_keys(mbedtls_pk_context* pk, mbedtls_entropy_f_source_ptr f_source, __maybe_unused TEE_Param params[TEE_NUM_PARAMS]) { int ret = 1; mbedtls_entropy_context entropy; mbedtls_ctr_drbg_context ctr_drbg; const char* pers = "gen_key"; TEE_Result res = TEE_SUCCESS; unsigned char output_buf[16000]; memset(output_buf, 0, 16000); mbedtls_entropy_init(&entropy); mbedtls_ctr_drbg_init(&ctr_drbg); if ((ret = mbedtls_entropy_add_source(&entropy, f_source, NULL, 48, MBEDTLS_ENTROPY_SOURCE_STRONG)) != 0) { params[2].value.a = 1; goto exit; } if ((ret = mbedtls_ctr_drbg_seed(&ctr_drbg, f_entropy, &entropy, (const unsigned char*)pers, strlen(pers))) != 0) { mbedtls_printf(" failed\n ! mbedtls_ctr_drbg_seed returned -0x%04x\n", (unsigned int)-ret); params[2].value.a = 2; goto exit; } if ((ret = mbedtls_pk_setup(pk, mbedtls_pk_info_from_type(MBEDTLS_PK_ECKEY))) != 0) { EMSG(" failed\n ! mbedtls_pk_setup returned -0x%04x", (unsigned int)-ret); params[2].value.a = 3; goto exit; } if ((ret = mbedtls_ecp_gen_key(MBEDTLS_ECP_DP_SECP384R1, mbedtls_pk_ec(*pk), mbedtls_ctr_drbg_random, &ctr_drbg)) != 0) { EMSG(" failed\n ! mbedtls_ecp_gen_key returned -0x%04x", (unsigned int)-ret); params[2].value.a = 4; goto exit; } exit: mbedtls_ctr_drbg_free(&ctr_drbg); mbedtls_entropy_free(&entropy); return res; }

10 months, 3 weeks

4
4
0 0

Re: PSA Cryptoprocessor Driver Interface

by Shebu Varghese Kuriakose

+ Mbed TLS mailing list as well for visibility and any comments. Regards, Shebu From: Zhang, Hao via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, June 5, 2024 12:37 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA Cryptoprocessor Driver Interface Hi TF-M community, TF-M allows Semiconductor vendors to plug in their HW accelerator using PSA cryptoprocessor driver interface. I have a couple of questions in terms of the driver interface. 1. To port customized HW accelerator to TF-M's Crypto service for TF-M v2.1.0 LTS using driver interface, for the multipart operation, https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa… states that "A driver that implements a multi-part operation must define all of the entry points in this family as well as a type that represents the operation context." Take aead encrypt as an example, if the underlying hardware does not support aead_abort, could it implements aead_abort by simply return PSA_ERROR_NOT_SUPPORTED? 1. The driver interface depends heavily on psa_crypto_driver_wrappers.h to dispatch operations to customized HW accelerator, where the psa_crypto_driver_wrappers.h file is automatically generated by scripts/data_files/driver_templates/psa_crypto_driver_wrappers.h.jinja. To port customized HW accelerator to TF-M's Crypto service for TF-M v2.1.0 LTS, would the approach be creating a customized psa_crypto_driver_wrappers.h.jinja file, the driver description file in JSON, and entry point functions. If so and we are considering upstreaming TF-M in the future, all these files would go inside platform/ext/accelerator/<vendor name>. Efforts need to be made so files such as psa_crypto_driver_wrappers.h.jinja should point to mbedtls, right? Additionally, as .jinja is retiring (mentioned in another email exchange), how would semi vendors update psa_crypto_driver_wrappers.h in the future? [https://opengraph.githubassets.com/c87e79773a7fb0841ea038f7cf3dfdf4170debb8…]<https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa…> mbedtls/docs/proposed/psa-driver-interface.md at zephyr * zephyrproject-rtos/mbedtls<https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa…> mbedtls module for Zephyr, this is not a mirror of the official mbedtls repository. - zephyrproject-rtos/mbedtls github.com Thank you very much! Best regards

10 months, 3 weeks

3
4
0 0

mbedtls_x509_dn_gets(): Different DN string for 2.28.8 and 3.6.0

by Almut Herzog

Hi, Not sure whether I should report this as a bug or maybe an enhancement issue or maybe it is as-designed: I recently migrated from 2.28.8 to 3.6.0 and noticed: An X.509 certificate DN coded as T61 string (done automatically so by openssl for a DN that contains an underscore) is returned as a hex string in 3.6.0 while it is returned as a regular, human-readable string in 2.28.8. As this is not working for us I patched mbedtls_c509_dn_gets() locally as shown below. Please feedback whether you want me to report an issue or if the 3.6.0 behavior is as-designed for a good reason. Best regards, /Almut --- mbedtls-3.6.0_orig/library/x509.c 2024-03-28 09:59:12.000000000 +0100 +++ mbedtls-3.6.0/library/x509.c 2024-05-21 10:43:43.327442284 +0200 @@ -840,9 +840,7 @@ MBEDTLS_X509_SAFE_SNPRINTF; } - print_hexstring = (name->val.tag != MBEDTLS_ASN1_UTF8_STRING) && - (name->val.tag != MBEDTLS_ASN1_PRINTABLE_STRING) && - (name->val.tag != MBEDTLS_ASN1_IA5_STRING); + print_hexstring = !MBEDTLS_ASN1_IS_STRING_TAG(name->val.tag); if ((ret = mbedtls_oid_get_attr_short_name(&name->oid, &short_name)) == 0) { ret = mbedtls_snprintf(p, n, "%s=", short_name);

10 months, 3 weeks

1
0
0 0

What is the right way to use ecp

by arun.lal＠intel.com

I have a very basic use case, to use a buffer and perform ECDSA encryption in a TA application. I also want to read back the private key which is generated. I see functions like mbedtls_ecp_gen_key but I have failed to find enough details on what steps to follow to use this function. It will be really helpful if I can be pointed to a example. Or let me know If there is some other way to achieve the end goal.

11 months

2
3
0 0

Are you requesting feedback about ED25519?

by Christian Huitema

Hello Gilles, I see that you are requesting feedback on a set of issues, but not on support of EdDSA. Yet, support for ED25519 is an important requirement for TLS and QUIC. With other crypto suites, the CPU load is significantly lower for ED25519 than for ECDSA/secp255r1. Somewhat related, but there is also demand for ChaCha20-poly1035, for performance reason on some systems. Are there any plans? -- Christian Huitema

11 months

2
1
0 0

Request for feedback about Mbed TLS 4: CBC cipher suites

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/mbedtls/issues/9202 In 2025 (by the time Mbed TLS 4.0 is released), are CBC-based cipher suites still relevant for Mbed TLS? If you still need support for CBC-based cipher suites (as opposed to cipher suites using AEAD: CCM, GCM or ChaChaPoly, or null cipher suites), please let us know. Removing them would allow us to significantly simplify some parts of the TLS code. They are difficult to implement securely due to being very sensitive to side channels; we think we got it right, but at the expense of performance, code size and maintainability. One option we're considering is to keep CBC cipher suites, but only when the encrypt-then-MAC (EtM) extension is enabled. However, this is problematic because the TLS protocol does not allow a client to indicate that it requires EtM support, which could lead to a failed connection even when the server also have an AEAD cipher suite in common. Best regards, -- Gilles Peskine Mbed TLS developer

11 months

1
0
0 0

Request for feedback about Mbed TLS 4: static ECDH cipher suites

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/mbedtls/issues/9201 We are considering removing static ECDH cipher suites. (Mbed TLS has never supported static non-EC DH.) They are officially deprecated by RFC 9325. OpenSSL dropped them in 2016. If you want Mbed TLS 4.0 to continue supporting ECDH, please let us know in what ecosystem they're still relevant. Best regards, -- Gilles Peskine Mbed TLS developer

11 months

1
0
0 0

Request for feedback about Mbed TLS 4: dynamic secure element drivers

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4,0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/mbedtls/issues/8151 We are planning to remove the dynamic secure element interface enabled by MBEDTLS_PSA_CRYPTO_SE_C, in favor of PSA secure element drivers declared at compile time. The functionality is the same, but with a cleaner interface (we learned from the first draft). However, this does mean that all drivers must be declared at compile time. If you are currently using MBEDTLS_PSA_CRYPTO_SE_C and relying on runtime declaration of drivers, please let us know about your use case, so that we can try to find an alternative solution. Best regards, -- Gilles Peskine Mbed TLS developer

11 months

1
0
0 0

Request for feedback about Mbed TLS 4: partial ECC acceleration

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4,0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/103 We are removing all the ALT interfaces to implement hardware-accelerated cryptography, in favor of PSA drivers. For the most part, PSA accelerator drivers provide equivalent functionality to ALT interface. However, there is one main exception: the ECC code allows replacing just code ECC arithmetic (MBEDTLS_ECP_ALT) or even just selected functions (sub-options of MBEDTLS_ECP_INTERNAL_ALT). On the other hand, the granularity of PSA accelerators is whole mechanisms: ECDH, ECDSA, etc. on a specific set of curves. If you are currently using MBEDTLS_ECP_ALT or MBEDTLS_ECP_INTERNAL_ALT to implement accelerated ECC airthmetic and relying on code from ecp.c, ecdh.c and ecdsa.c to provide ECC mechanisms, please let us know what your requirements are and how much of a pain it would be to have to fully implement ECDH/ECDSA/... in your driver. Best regards, -- Gilles Peskine Mbed TLS developer

11 months

1
0
0 0

Request for feedback about Mbed TLS 4: RSA private key import

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4,0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/105 Mbed TLS 4 and TF-PSA-Crypto will complete our migration to PSA cryptography APIs. For simplicity, PSA only requires implementations to support complete representations RSA private keys, where all the fields are provided (n, e, d, p, q, dp, dq, u). Thus, with only PSA APIs, it is not possible to import an RSA private key without the public exponent, or an RSA private key without the CRT parameters. Should TF-PSA-Crypto provide an extension to support such private keys? If you need this, please let us know about your use case. Best regards, -- Gilles Peskine Mbed TLS developer

11 months

1
0
0 0

Request for feedback about Mbed TLS 4: custom ECC mechanisms

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4,0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/102 Mbed TLS 4 and TF-PSA-Crypto will complete our migration to PSA cryptography APIs, which are higher-level than the legacy mbedtls_xxx() APIs in Mbed TLS ≤3.x. As a consequence, the API will only provide access to ECC-based cryptographic mechanisms such as ECDH, ECDSA and ECJPAKE. (ECIES can be implemented on top of ECDH. Support for EdDSA and SPAKE2+ is planned, but might not be ready at the 4.0 release time.) It will not provide access to ECC arithmetic functions such as mbedtls_ecp_muladd(). Do you need custom ECC-based mechanisms (e.g. custom PAKE)? If so, please let us know which mechanisms and what arithmetic they require. We are not currently planning to make it possible to use such mechanisms without patching the TF-PSA-Crypto code. Best regards, -- Gilles Peskine Mbed TLS developer

11 months

1
0
0 0

Request for feedback about Mbed TLS 4: custom RSA mechanisms

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4,0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/104 Mbed TLS 4 and TF-PSA-Crypto will complete our migration to PSA cryptography APIs, which are higher-level than the legacy mbedtls_xxx() APIs in Mbed TLS ≤3.x. As a consequence, the API will only provide access to RSA-based encryption and signature mechanisms (PKCS#1v1.5 encryption, OAEP, PKCS#1v1.5 signature, RSS), not to the low-level RSA-public and RSA-private operations. Do you need custom RSA-based mechanisms (e.g. full-domain encryption or hashing)? If so, please let us know. We are not currently planning to make it possible to use such mechanisms without patching the TF-PSA-Crypto code. Best regards, -- Gilles Peskine Mbed TLS developer

11 months

1
0
0 0

Request for feedback about Mbed TLS 4: DES (including 3DES)

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4,0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/mbedtls/issues/9164 We are considering fully removing DES, including 3DES, from the library. Is any DES variant still relevant to Mbed TLS users these days? If you want Mbed TLS 4 to include DES, please let us know what you're using it for. Reasons to remove: it's long obsolete, and no longer accepted even by NIST except to handle legacy data. Removing it would be one less module to support and would allow generic block cipher code to focus on modern ciphers with 128-bit blocks. Best regards, -- Gilles Peskine Mbed TLS developer

11 months

1
0
0 0

MBEDTLS Default Search Path

by Frozen Forest

I am trying to build *https://github.com/ithewei/libhv <https://github.com/ithewei/libhv>* with MBEDTLS on Windows but it doesn't have include and library define options on *CMake*. When I ask them with an issue on *GitHub*, they said I need to use *"Default Search Path"*. I installed it with *cmake --build . --config Release --target INSTALL *and I can see it in *Program Files/MBed TLS. *I think I need to define an environment variable. But what is correct names for includes and libraries ?

11 months

1
0
0 0

Certificate validation

by Sushma Narayan Shetty

Hi Team, Need support on one the below query. I had previously raised this in issue #9116 : Client certificate verify · Issue #9116 · Mbed-TLS/mbedtls · GitHub<https://github.com/Mbed-TLS/mbedtls/issues/9116> .However I was asked to redirect the query to the mbedTLS support. Q#1 : I have a client certificate chain (end entity cert, intermediate cert and root cert) and I have got 1 public key (extracted from root CA cert) on my server. Is there any way in mbedTLS where I can validate the client certificate using just the public key of the root CA and not the whole root CA certificate on my server? As per my understanding of CA and certificate validation we would need a whole CA cert and not just the public key of the root certificate. However, I would like to know if there are any API's in mbedTLS for this validation? Thanks, Sushma ________________________________ Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient of this message , or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited. Email transmission cannot be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender, therefore, does not accept liability for any errors, omissions or contaminations in the contents of this message which might have occurred as a result of email transmission. If verification is required, please request for a hard-copy version. ________________________________

11 months, 2 weeks

2
1
0 0

Testing an an Ubuntu VM, issue with configuration

by Christian Huitema

I am testing a test program in an Ubuntu VM, and I have an issue. I started by configuring MbedTLS in "full" mode (scripts/config.py full), but in that case the linker fails, "in function `psa_load_builtin_key_into_slot`, psa_crypto_slot_management.c: undefined reference to 'mbedtls_psa_platform_get_builtin_key`. I can suppress the error by editing `include\mbedtls\mbedtls_config.h` and removing the option `MBEDTLS_PSA_CRYPTO_BUILTIN_KEYS`. The compile succeeds, but the call to `psa_crypto_init` fails when initializing the RNG module. I am struggling. I must be making some mistake, I will keep trying to understand, but I would appreciate a little bit of help! -- Christian Huitema

11 months, 2 weeks

1
1
0 0

UTF-8 in code files

by Stephan Koch

Hello Mbed TLS team, Mbed TLS 3.6 introduced the first UTF-8 characters “±” in source code, see mbedtls_config.h, line 4179: * at the same pace. The typical accuracy of an RTC crystal is ±100 to ±20 parts Is this intended? Thanks Stephan

11 months, 2 weeks

3
3
0 0

Using the "psa_verify_message" function

by Christian Huitema

The specification of the "psa_verify_message" function is simple enough: pass a key ID, an algorithm ID, the data that were signed, the signature received from the peer, and receive a status. There is just one tiny problem: in the application, the algorithm ID is specified as a 16 bit TLS SignatureScheme (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-si…), which is not quite the same as "psa_algorithm_t". Is there a simple way to covert from TLS SignatureScheme to PSA ALgorithm identifier? Maybe a two columns table? -- Christian Huitema

11 months, 2 weeks

2
1
0 0

Error while parsing certificate

by Subramanian Gopi Krishnan

Hi, I have an inhouse developed secure authentication program that uses certificate for authentication. I have used mbedtls library for the x.509 certificate verification purpose. In our custom PKI we have only three level of certificates, Root-CA -> Intermediate-CA -> Device-Cert. The embedded device has very limited memory, so instead of sending whole certificate chain, the devices communicates intermediate_CA and device cert (in der format base64 encoded) in separate packet. Root-CA will be available on node as trusted-ca. Intermediate is verified against Root; then device cert is verified against intermediate. The problem is, the poc developed on linux platform is working fine - but on embedded platform I encounter either 0x3b00(parsing failed) or 0x2700(with flag 8). Also the error code are inconsistent. I verified the integrity of packet with certificate using crc16. So no chance of certificate getting corrupted. Also verified the certificate's base64 format integrity using crc16. All certificates are sha256WithRSAEncryption; RSA Public-Key: (4096 bit) Attached config.h on target platform for reference - could you help me if anything wrong with configuration. While trying to trace, the flag was set from x509_crt.c from below code. /* No parent? We're done here */ if( parent == NULL ) { printf("NO_PARENT\r\n"); *flags |= MBEDTLS_X509_BADCERT_NOT_TRUSTED; return( 0 ); } Any clue would be helpful. Thanks, Gopi Krishnan

11 months, 3 weeks

2
1
0 0

Help debugging TLS handshake failure

by Jay Malhotra

Hi, I'm having an issue with some code using Mbed TLS and I was pointed to this mailing list as the correct place to ask for support. Please let me know if I should ask somewhere else. I'm trying to connect to my local government's website via a Raspberry Pi Pico, using a TLS client based on lwIP and altcp_tls. It's based off of the example from the Raspberry Pi team here: https://github.com/raspberrypi/pico-examples/tree/master/pico_w/wifi/tls_cl… . My Mbed TLS config is the same as what they have there, aside from some extra defines I added for debugging. The issue I am facing is that while various hosts work fine (e.g. postman-echo.com for testing), when I attempt to connect to my local council's website I get a TLS handshake error. My client has TLS verification disabled for the moment, but I have tried with the correct root certificates as well. The error I receive is mbedtls_ssl_handshake failed: -30592 I cloned down the mbed_tls repo, and had a similar issue with ssl_client1 -- i.e. works on postman-echo, not for my government, with mbedtls_ssl_handshake returning the error. Notably however, the error code in that instance was -31488. Interestingly, ssl_client2 works flawlessly with both hosts. I wasn't quite sure what part of ssl_client2 would cause it to work with my government host, as it's several thousand lines long, but I'm sure the answer is in there somewhere. I've attached a trace taken with debug logging level 4 on my Pico which shows where the TLS handshake is failing. I'd really appreciate any guidance of areas to troubleshoot next. Thanks, Jay

11 months, 3 weeks

1
1
0 0

Memory Cleanup of Persistent Key Slots

by Zak, Kevin

Hello, I am referencing the Mbed TLS (v3.5) implementation for key slots & how they interact with the PSA key management APIs. In the PSA documentation<https://arm-software.github.io/psa-api/crypto/1.1/overview/implementation.h…>, sections 6.3.3 and 6.3.4 describe that persistent keys (that are handled according to the Memory cleanup rule) would have to be loaded from NVM on each use of the key, unless PSA_KEY_USAGE_CACHE is set. However, I'm not certain I see this followed in the Mbed TLS code. 'psa_export_key()' is the simplest example. This function retrieves and locks the key slot for the requested key ID using 'psa_get_and_lock_key_slot_with_policy()' - this function may retrieve the persistent key material from NVM if necessary (it seems to return sooner if it finds that persistent key in a slot already). The remainder of psa_export_key() copies the key material from the slot directly to the output buffer, but it never removes the key material from the slot. My understanding was that the key material should be removed from the slot unless PSA_KEY_USAGE_CACHE was set. Can anyone clear this up for me? Does this just mean that the reference implementation does not follow the memory cleanup rule, or is the slot buffer cleared at some later point for the persistent key? Thank you, Kevin Zak

12 months

2
1
0 0

Reminder: MBed TLS Tech Forum - US/Europe

by Don Harbin

Hi All, A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum is next Monday at 4:30 PM UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

12 months

1
6
0 0

The road towards Mbed TLS 4.0

by Nathan Sircombe

Dear Mbed TLS users, We recently announced the release of Mbed TLS 3.6.0, starting the 3.6 long-term support branch. We intend for this to be the last 3.x feature release. Mbed TLS 3.6.x will as usual receive bug fixes (including security improvements), but no new features. This will allow the Mbed TLS team to focus on preparing the next major release, Mbed TLS 4.0, planned for 2025 (expect further updates when the timeline becomes more precise). The main focus of Mbed TLS 4.0 is to complete the migration to PSA crypto APIs. This means that most mbedtls_xxx cryptography APIs will be removed. We expect mbedtls_x509 and mbedtls_ssl to change in relatively minor, but sometimes incompatible ways. Alongside this technical change, the crypto APIs will be published as a separate product, TF-PSA-Crypto<https://github.com/Mbed-TLS/TF-PSA-Crypto> (very early preview so far), while the X.509 and TLS libraries will continue to be called Mbed TLS. The work on 4.0 will happen on the development branch in the mbedtls repository, so you can expect more instability than usual on that branch. The mbedtls-3.6<https://github.com/Mbed-TLS/mbedtls/tree/mbedtls-3.6> branch is available if you want the latest patches on Mbed TLS 3.6 LTS. As usual, you can see our high-level plans in the roadmap<https://mbed-tls.readthedocs.io/en/latest/project/roadmap/>, and in more detail on GitHub<https://github.com/Mbed-TLS/mbedtls/issues>. Look for issues labeled api-break<https://github.com/Mbed-TLS/mbedtls/issues?q=is%3Aissue+is%3Aopen+label%3Aa…> (note that we haven't filed issues on all topics yet). We will launch some consultations on the mbed-tls mailing list<https://lists.trustedfirmware.org/mailman3/lists/mbed-tls.lists.trustedfirm…> soon, to gather community input on some topics. Many Thanks, Nathan Sircombe (On behalf of the Mbed TLS development team)

12 months

3
4
0 0

Introductions

by Nathan Sircombe

Hi Mbed TLS list, I’d just like to introduce myself to the wider Mbed TLS community. I’ve recently joined the Mbed TLS team as the Engineering Manager for the Arm team. Although I’m new to this project, I’m not new to Arm having worked here for a while on a number of closed and open source library projects. I look forward to working with you, and meeting some of you on our regular community calls. Cheers, Nathan. p.s. my GitHub usid is nSircombe (https://github.com/nSircombe)

12 months

1
0
0 0

Ask about using mbedtls

by blaine

hello： Recently, I am transplanting mbedtls from a 32-bit system to a 64-bit system. The compilation operating system is ubuntu20.4. The screenshot below is the code I use mbedtls(version number: 2.24.0). In the API mbedtls_rsa_gen_key implementation, there is a line of code that is ""MBEDTLS_MPI_CHK( mbedtls_mpi_lset( &ctx ->E, exponent ) );"", the program crashed at the memset in mbedtls_mpi_set during execution. This has not happened on 32-bit platforms before, so I would like to ask whether it has something to do with the platform used or whether I call the API. It’s a question about how to use it, thank you very much

1 year

2
1
0 0

Exports from the shared libraries vs API

by Zaki, Ahmed

Hi, I am trying to identify the API available by looking up exported symbols from the built shared libraries libmbedcrypto.so ,libmbedtls.so and libmbedx509.so. I noticed that many of the exported functions are not documented here https://mbed-tls.readthedocs.io/projects/api/en/development/ . My question really is, are those functions exported through the shared libraries intended to be so ? For example, function mbedtls_mpi_core_add does not seem to be part of the API but it is exported. Is this intentional ? It's not uncommon that functions would be exported but not part of the API, I just wanted to get some clarification if possible regarding the reasons for doing so in the case of MbedTLS. Thanks Ahmed

1 year

2
1
0 0

MbedTLS Test Cases

by Satya Prakash Prasad

Hi, I am sorry but I need to know test case scenarios to verify what is supported in the recent MBedTLS stack - what should be tested. Objective is that we cover MBedTLS code the maximum. Since I am a new learner, I need to build the test cases from scratch. So I thought to first find from stack what TLS ciphers suites / digest it supports, what are the different keysize, and protocols - TLSvX (where x=1,2 or 3). Then build certificates related to the same and verify the data as found. Are there other ways to find different features in the current MBedTLs stack and verify each one of them? Is this approach the right way - do we have known test case scenarios to verify? Any other additional help will aid us out. Thanks in advance. Regards, Prakash

1 year

1
0
0 0

MbedTLS 3.6.0 - Memory or other issue

by Satya Prakash Prasad

Hi, We are using MbedTLS 3.6.0 in an embedded device which has limited memory available. Since we are implementing the same for the first time hence from the logs please confirm if it is coding integration issue (like caught in infinite loop, not correct integration etc) or the flow errors out because of unavailable of memory. In our embedded device we have allocated .5 MB (half MB) of space for TLS thread stack. How much do we actually need - 1 MB or 2 MB. Is there any memory leak issue? Please find the logs below and let me know is there is any issue in integration or memory issue. Thanks in advance. Regards, Prakash ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 4622 => handshake ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_HELLO_REQUEST ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_CLIENT_HELLO ssl_client.c 919 => write client hello ssl_client.c 725 client hello, current time: 1714521657 ssl_client.c 487 dumping 'client hello, random bytes' (32 bytes) ssl_client.c 487 0000: 66 31 86 39 78 bc 58 af ec e1 20 b2 82 67 fb 9b f1.9x.X... ..g.. ssl_client.c 487 0010: 2f 56 40 0f b1 35 c1 b9 27 f1 e5 06 89 c2 23 69 /V@..5..'.....#i ssl_client.c 512 dumping 'session id' (0 bytes) ssl_client.c 371 client hello, add ciphersuite: cca8, TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256 ssl_client.c 371 client hello, add ciphersuite: cca9, TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256 ssl_client.c 371 client hello, add ciphersuite: ccaa, TLS-DHE-RSA-WITH-CHACHA20-POLY1305-SHA256 ssl_client.c 371 client hello, add ciphersuite: c0ad, TLS-ECDHE-ECDSA-WITH-AES-256-CCM ssl_client.c 371 client hello, add ciphersuite: c09f, TLS-DHE-RSA-WITH-AES-256-CCM ssl_client.c 371 client hello, add ciphersuite: 006b, TLS-DHE-RSA-WITH-AES-256-CBC-SHA256 ssl_client.c 371 client hello, add ciphersuite: c00a, TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: c014, TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: 0039, TLS-DHE-RSA-WITH-AES-256-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: c0af, TLS-ECDHE-ECDSA-WITH-AES-256-CCM-8 ssl_client.c 371 client hello, add ciphersuite: c0a3, TLS-DHE-RSA-WITH-AES-256-CCM-8 ssl_client.c 371 client hello, add ciphersuite: c02b, TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256 ssl_client.c 371 client hello, add ciphersuite: c02f, TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256 ssl_client.c 371 client hello, add ciphersuite: 009e, TLS-DHE-RSA-WITH-AES-128-GCM-SHA256 ssl_client.c 371 client hello, add ciphersuite: c0ac, TLS-ECDHE-ECDSA-WITH-AES-128-CCM ssl_client.c 371 client hello, add ciphersuite: c09e, TLS-DHE-RSA-WITH-AES-128-CCM ssl_client.c 371 client hello, add ciphersuite: c023, TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256 ssl_client.c 371 client hello, add ciphersuite: c027, TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256 ssl_client.c 371 client hello, add ciphersuite: 0067, TLS-DHE-RSA-WITH-AES-128-CBC-SHA256 ssl_client.c 371 client hello, add ciphersuite: c009, TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: c013, TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: 0033, TLS-DHE-RSA-WITH-AES-128-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: c0ae, TLS-ECDHE-ECDSA-WITH-AES-128-CCM-8 ssl_client.c 371 client hello, add ciphersuite: c0a2, TLS-DHE-RSA-WITH-AES-128-CCM-8 ssl_client.c 371 client hello, add ciphersuite: c09d, TLS-RSA-WITH-AES-256-CCM ssl_client.c 371 client hello, add ciphersuite: 003d, TLS-RSA-WITH-AES-256-CBC-SHA256 ssl_client.c 371 client hello, add ciphersuite: 0035, TLS-RSA-WITH-AES-256-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: c0a1, TLS-RSA-WITH-AES-256-CCM-8 ssl_client.c 371 client hello, add ciphersuite: 009c, TLS-RSA-WITH-AES-128-GCM-SHA256 ssl_client.c 371 client hello, add ciphersuite: c09c, TLS-RSA-WITH-AES-128-CCM ssl_client.c 371 client hello, add ciphersuite: 003c, TLS-RSA-WITH-AES-128-CBC-SHA256 ssl_client.c 371 client hello, add ciphersuite: 002f, TLS-RSA-WITH-AES-128-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: c0a0, TLS-RSA-WITH-AES-128-CCM-8 ssl_client.c 387 adding EMPTY_RENEGOTIATION_INFO_SCSV ssl_client.c 398 client hello, got 34 cipher suites ssl_client.c 230 client hello, adding supported_groups extension ssl_client.c 249 got supported group(001d) ssl_client.c 283 NamedGroup: x25519 ( 1d ) ssl_client.c 249 got supported group(0017) ssl_client.c 283 NamedGroup: secp256r1 ( 17 ) ssl_client.c 249 got supported group(0018) ssl_client.c 283 NamedGroup: secp384r1 ( 18 ) ssl_client.c 249 got supported group(001e) ssl_client.c 283 NamedGroup: x448 ( 1e ) ssl_client.c 249 got supported group(0019) ssl_client.c 283 NamedGroup: secp521r1 ( 19 ) ssl_client.c 249 got supported group(001a) ssl_client.c 283 NamedGroup: bp256r1 ( 1a ) ssl_client.c 249 got supported group(001b) ssl_client.c 283 NamedGroup: bp384r1 ( 1b ) ssl_client.c 249 got supported group(001c) ssl_client.c 283 NamedGroup: bp512r1 ( 1c ) ssl_client.c 302 dumping 'Supported groups extension' (18 bytes) ssl_client.c 302 0000: 00 10 00 1d 00 17 00 18 00 1e 00 19 00 1a 00 1b ................ ssl_client.c 302 0010: 00 1c .. ssl_tls.c 9611 adding signature_algorithms extension ssl_tls.c 9633 got signature scheme [603] ecdsa_secp521r1_sha512 ssl_tls.c 9642 sent signature scheme [603] ecdsa_secp521r1_sha512 ssl_tls.c 9633 got signature scheme [806] rsa_pss_rsae_sha512 ssl_tls.c 9633 got signature scheme [601] rsa_pkcs1_sha512 ssl_tls.c 9642 sent signature scheme [601] rsa_pkcs1_sha512 ssl_tls.c 9633 got signature scheme [403] ecdsa_secp256r1_sha256 ssl_tls.c 9642 sent signature scheme [403] ecdsa_secp256r1_sha256 ssl_tls.c 9633 got signature scheme [804] rsa_pss_rsae_sha256 ssl_tls.c 9633 got signature scheme [401] rsa_pkcs1_sha256 ssl_tls.c 9642 sent signature scheme [401] rsa_pkcs1_sha256 ssl_tls12_client.c 106 client hello, adding supported_point_formats extension ssl_tls12_client.c 307 client hello, adding encrypt_then_mac extension ssl_tls12_client.c 339 client hello, adding extended_master_secret extension ssl_tls12_client.c 372 client hello, adding session ticket extension ssl_client.c 689 client hello, total extension length: 54 ssl_client.c 691 dumping 'client hello extensions' (54 bytes) ssl_client.c 691 0000: 00 36 00 0a 00 12 00 10 00 1d 00 17 00 18 00 1e .6.............. ssl_client.c 691 0010: 00 19 00 1a 00 1b 00 1c 00 0d 00 0a 00 08 06 03 ................ ssl_client.c 691 0020: 06 01 04 03 04 01 00 0b 00 02 01 00 00 16 00 00 ................ ssl_client.c 691 0030: 00 17 00 00 00 23 .....# ssl_msg.c 2783 => write handshake message ssl_msg.c 2943 => write record ssl_msg.c 3030 output record: msgtype = 22, version = [3:3], msglen = 167 ssl_msg.c 3033 dumping 'output record sent to network' (172 bytes) ssl_msg.c 3033 0000: 16 03 03 00 a7 01 00 00 a3 03 03 66 31 86 39 78 ...........f1.9x ssl_msg.c 3033 0010: bc 58 af ec e1 20 b2 82 67 fb 9b 2f 56 40 0f b1 .X... ..g../V@.. ssl_msg.c 3033 0020: 35 c1 b9 27 f1 e5 06 89 c2 23 69 00 00 44 cc a8 5..'.....#i..D.. ssl_msg.c 3033 0030: cc a9 cc aa c0 ad c0 9f 00 6b c0 0a c0 14 00 39 .........k.....9 ssl_msg.c 3033 0040: c0 af c0 a3 c0 2b c0 2f 00 9e c0 ac c0 9e c0 23 .....+./.......# ssl_msg.c 3033 0050: c0 27 00 67 c0 09 c0 13 00 33 c0 ae c0 a2 c0 9d .'.g.....3...... ssl_msg.c 3033 0060: 00 3d 00 35 c0 a1 00 9c c0 9c 00 3c 00 2f c0 a0 .=.5.......<./.. ssl_msg.c 3033 0070: 00 ff 01 00 00 36 00 0a 00 12 00 10 00 1d 00 17 .....6.......... ssl_msg.c 3033 0080: 00 18 00 1e 00 19 00 1a 00 1b 00 1c 00 0d 00 0a ................ ssl_msg.c 3033 0090: 00 08 06 03 06 01 04 03 04 01 00 0b 00 02 01 00 ................ ssl_msg.c 3033 00a0: 00 16 00 00 00 17 00 00 00 23 00 00 .........#.. ssl_msg.c 3080 <= write record ssl_msg.c 2904 <= write handshake message ssl_client.c 1012 <= write client hello ssl_msg.c 2353 => flush output ssl_msg.c 2369 message length: 172, out_left: 172 ssl_msg.c 2374 ssl->f_send() returned 172 (-0xffffff54) ssl_msg.c 2401 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_SERVER_HELLO ssl_tls12_client.c 1193 => parse server hello ssl_msg.c 4189 => read record ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 0, nb_want: 5 ssl_msg.c 2317 in_left: 0, nb_want: 5 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 0 (-0x0000) ssl_msg.c 4861 mbedtls_ssl_fetch_input() returned -29312 (-0x7280) ssl_msg.c 4220 ssl_get_next_record() returned -29312 (-0x7280) ssl_tls12_client.c 1197 mbedtls_ssl_read_record() returned -29312 (-0x7280) ssl_tls.c 4635 <= handshake ssl_tls.c 4622 => handshake ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_SERVER_HELLO ssl_tls12_client.c 1193 => parse server hello ssl_msg.c 4189 => read record ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 0, nb_want: 5 ssl_msg.c 2317 in_left: 0, nb_want: 5 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_msg.c 2340 <= fetch input ssl_msg.c 3855 dumping 'input record header' (5 bytes) ssl_msg.c 3855 0000: 16 03 03 00 3d ....= ssl_msg.c 3859 input record: msgtype = 22, version = [0x303], msglen = 61 ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 5, nb_want: 66 ssl_msg.c 2317 in_left: 5, nb_want: 66 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 61 (-0xffffffc3) ssl_msg.c 2340 <= fetch input ssl_msg.c 3965 dumping 'input record from network' (66 bytes) ssl_msg.c 3965 0000: 16 03 03 00 3d 02 00 00 39 03 03 76 36 49 0c df ....=...9..v6I.. ssl_msg.c 3965 0010: c5 5f 16 59 fa a0 24 de 4f 91 1d 01 18 c4 f4 75 ._.Y..$.O......u ssl_msg.c 3965 0020: a1 f9 ee 64 aa 85 27 40 09 f4 59 00 cc a8 00 00 ...d..'@..Y..... ssl_msg.c 3965 0030: 11 ff 01 00 01 00 00 0b 00 04 03 00 01 02 00 17 ................ ssl_msg.c 3965 0040: 00 00 .. ssl_msg.c 3234 handshake message: msglen = 61, type = 2, hslen = 61 ssl_msg.c 4261 <= read record ssl_tls12_client.c 1267 dumping 'server hello, version' (2 bytes) ssl_tls12_client.c 1267 0000: 03 03 .. ssl_tls12_client.c 1292 server hello, current time: 1983269132 ssl_tls12_client.c 1298 dumping 'server hello, random bytes' (32 bytes) ssl_tls12_client.c 1298 0000: 76 36 49 0c df c5 5f 16 59 fa a0 24 de 4f 91 1d v6I..._.Y..$.O.. ssl_tls12_client.c 1298 0010: 01 18 c4 f4 75 a1 f9 ee 64 aa 85 27 40 09 f4 59 ....u...d..'@..Y ssl_tls12_client.c 1360 server hello, session id len.: 0 ssl_tls12_client.c 1361 dumping 'server hello, session id' (0 bytes) ssl_tls12_client.c 1386 no session has been resumed ssl_tls12_client.c 1388 server hello, chosen ciphersuite: cca8 ssl_tls12_client.c 1390 server hello, compress alg.: 0 ssl_tls12_client.c 1425 server hello, chosen ciphersuite: TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256 ssl_tls12_client.c 1447 server hello, total extension length: 17 ssl_tls12_client.c 1463 found renegotiation extension ssl_tls12_client.c 1543 found supported_point_formats extension ssl_tls12_client.c 841 point format selected: 0 ssl_tls12_client.c 1516 found extended_master_secret extension ssl_tls12_client.c 1659 <= parse server hello ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_SERVER_CERTIFICATE ssl_tls.c 8204 => parse certificate ssl_msg.c 4189 => read record ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 0, nb_want: 5 ssl_msg.c 2317 in_left: 0, nb_want: 5 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_msg.c 2340 <= fetch input ssl_msg.c 3855 dumping 'input record header' (5 bytes) ssl_msg.c 3855 0000: 16 03 03 06 c7 ..... ssl_msg.c 3859 input record: msgtype = 22, version = [0x303], msglen = 1735 ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 5, nb_want: 1740 ssl_msg.c 2317 in_left: 5, nb_want: 1740 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 1735 (-0xfffff939) ssl_msg.c 2340 <= fetch input ssl_msg.c 3965 dumping 'input record from network' (1740 bytes) ssl_msg.c 3965 0000: 16 03 03 06 c7 0b 00 06 c3 00 06 c0 00 03 2f 30 ............../0 ssl_msg.c 3965 0010: 82 03 2b 30 82 02 13 02 14 6d 4f 99 2e 33 c5 10 ..+0.....mO..3.. ssl_msg.c 3965 0020: 1e ea 27 57 74 8f cf 4d 01 60 54 51 76 30 0d 06 ..'Wt..M.`TQv0.. ssl_msg.c 3965 0030: 09 2a 86 48 86 f7 0d 01 01 0b 05 00 30 53 31 0b .*.H........0S1. ssl_msg.c 3965 0040: 30 09 06 03 55 04 06 13 02 55 53 31 0b 30 09 06 0...U....US1.0.. ssl_msg.c 3965 0050: 03 55 04 08 0c 02 43 41 31 12 30 10 06 03 55 04 .U....CA1.0...U. ssl_msg.c 3965 0060: 07 0c 09 53 6f 6d 65 77 68 65 72 65 31 10 30 0e ...Somewhere1.0. ssl_msg.c 3965 0070: 06 03 55 04 0a 0c 07 53 6f 6d 65 6f 6e 65 31 11 ..U....Someone1. ssl_msg.c 3965 0080: 30 0f 06 03 55 04 03 0c 08 46 6f 6f 62 61 72 43 0...U....FoobarC ssl_msg.c 3965 0090: 41 30 1e 17 0d 32 34 30 34 30 33 30 39 33 35 30 A0...24040309350 ssl_msg.c 3965 00a0: 30 5a 17 0d 32 35 30 34 30 33 30 39 33 35 30 30 0Z..250403093500 ssl_msg.c 3965 00b0: 5a 30 51 31 0b 30 09 06 03 55 04 06 13 02 55 53 Z0Q1.0...U....US ssl_msg.c 3965 00c0: 31 0b 30 09 06 03 55 04 08 0c 02 43 41 31 12 30 1.0...U....CA1.0 ssl_msg.c 3965 00d0: 10 06 03 55 04 07 0c 09 53 6f 6d 65 77 68 65 72 ...U....Somewher ssl_msg.c 3965 00e0: 65 31 10 30 0e 06 03 55 04 0a 0c 07 53 6f 6d 65 e1.0...U....Some ssl_msg.c 3965 00f0: 6f 6e 65 31 0f 30 0d 06 03 55 04 03 0c 06 46 6f one1.0...U....Fo ssl_msg.c 3965 0100: 6f 62 61 72 30 82 01 22 30 0d 06 09 2a 86 48 86 obar0.."0...*.H. ssl_msg.c 3965 0110: f7 0d 01 01 01 05 00 03 82 01 0f 00 30 82 01 0a ............0... ssl_msg.c 3965 0120: 02 82 01 01 00 c1 9f d8 d2 15 fe e5 68 e8 fe 65 ............h..e ssl_msg.c 3965 0130: 21 e4 c4 78 ea 22 da 31 4d 08 77 df 03 d5 13 03 !..x.".1M.w..... ssl_msg.c 3965 0140: ec 36 8f d1 d3 c1 5c 15 52 fd 9d c8 27 f2 ca 51 .6....\.R...'..Q ssl_msg.c 3965 0150: 79 18 22 95 d7 6b 09 72 96 79 5a d0 cd cc ac 20 y."..k.r.yZ.... ssl_msg.c 3965 0160: 2e f2 05 cb 57 57 f3 91 07 9f 3d d7 2c e7 4e 97 ....WW....=.,.N. ssl_msg.c 3965 0170: 56 31 0a 3c 04 fd 43 9d ee 9f e7 5b d8 b7 41 0e V1.<..C....[..A. ssl_msg.c 3965 0180: d8 9b 28 8b 82 33 cd ff 7d db 8c c2 3d b6 c0 ff ..(..3..}...=... ssl_msg.c 3965 0190: 48 df dd bb 9e d6 d1 84 0a d5 f5 f5 c4 88 cc 7f H............... ssl_msg.c 3965 01a0: 2b 82 67 f0 9c 47 54 27 00 6a f0 59 0a d6 0f 84 +.g..GT'.j.Y.... ssl_msg.c 3965 01b0: a9 10 8f d2 a5 d3 26 53 3c 28 57 94 01 06 8a 1d ......&S<(W..... ssl_msg.c 3965 01c0: ff 90 e2 48 25 55 7e fd 03 cc 2c 6b e4 0e 3e 09 ...H%U~...,k..>. ssl_msg.c 3965 01d0: b2 2c 97 23 32 29 b2 55 a4 f1 37 3d 1c f8 d0 a3 .,.#2).U..7=.... ssl_msg.c 3965 01e0: 4b 6d 78 db 68 2c ac 6e 6b d6 14 2e 86 e6 0f 3d Kmx.h,.nk......= ssl_msg.c 3965 01f0: d1 61 38 de ba cb bf 4f d8 d0 af 66 b2 3f 09 0e .a8....O...f.?.. ssl_msg.c 3965 0200: 51 c5 4b c6 d2 c0 90 8a db 51 98 32 bf a3 9b e9 Q.K......Q.2.... ssl_msg.c 3965 0210: 94 a2 69 9a 0a e1 a1 6e ad 63 59 92 e2 81 4a 29 ..i....n.cY...J) ssl_msg.c 3965 0220: 36 84 36 33 2b 02 03 01 00 01 30 0d 06 09 2a 86 6.63+.....0...*. ssl_msg.c 3965 0230: 48 86 f7 0d 01 01 0b 05 00 03 82 01 01 00 1d eb H............... ssl_msg.c 3965 0240: c0 c7 45 0b 99 54 89 c9 9c 6b 18 c7 22 bf d8 a1 ..E..T...k.."... ssl_msg.c 3965 0250: 30 b6 09 ca b1 8e b4 fc a1 a7 f9 27 f8 12 ff b0 0..........'.... ssl_msg.c 3965 0260: fb c8 44 b1 d8 52 40 71 05 7d 8e 1d c1 69 0f ff ..D..R@q.}...i.. ssl_msg.c 3965 0270: f4 d2 a3 8b df e1 0b f0 8c de fb 60 e1 81 87 bc ...........`.... ssl_msg.c 3965 0280: 0f 46 84 0e db 64 dd cc c0 eb 7b bd 35 ac 5d 33 .F...d....{.5.]3 ssl_msg.c 3965 0290: 9c f7 96 24 05 4d 45 27 37 6d 0c 9f 92 ea 7d fe ...$.ME'7m....}. ssl_msg.c 3965 02a0: 4a 9b c9 54 3b 91 0f 87 7c f4 46 64 b0 3d 54 c4 J..T;...|.Fd.=T. ssl_msg.c 3965 02b0: 5f 17 bd 88 a5 07 85 24 71 44 6c be 3b 3a f8 a4 _......$qDl.;:.. ssl_msg.c 3965 02c0: 7a 2b 67 5e 3d bd 5a 12 8d 2e bd 47 8d 6f 0d 02 z+g^=.Z....G.o.. ssl_msg.c 3965 02d0: 90 af fe 8b a9 ef a8 12 73 77 29 ce fe ef 79 51 ........sw)...yQ ssl_msg.c 3965 02e0: 68 6b 2f 18 fd da f8 1e 52 eb e9 eb 38 c0 ee ee hk/.....R...8... ssl_msg.c 3965 02f0: 45 de 8f 5f 3f c4 d8 9e c4 12 87 83 5c 48 0b c9 E.._?.......\H.. ssl_msg.c 3965 0300: 5a 28 6a ec e4 28 f1 07 5b 27 7d 75 d5 2b c2 dd Z(j..(..['}u.+.. ssl_msg.c 3965 0310: ff 88 08 e3 89 14 36 6d 8b ce e3 27 d7 ef 90 bd ......6m...'.... ssl_msg.c 3965 0320: 4e da 78 f6 bf 99 4d f7 95 bf d9 d5 e8 52 f1 c8 N.x...M......R.. ssl_msg.c 3965 0330: df 5c e1 c3 fd 8e 10 0f ae cf ef bb 94 2f 00 03 .\.........../.. ssl_msg.c 3965 0340: 8b 30 82 03 87 30 82 02 6f a0 03 02 01 02 02 14 .0...0..o....... ssl_msg.c 3965 0350: 22 df a0 f5 03 ec 52 a6 04 2e 69 b4 86 56 5f 5c ".....R...i..V_\ ssl_msg.c 3965 0360: 29 ec 05 e6 30 0d 06 09 2a 86 48 86 f7 0d 01 01 )...0...*.H..... ssl_msg.c 3965 0370: 0b 05 00 30 53 31 0b 30 09 06 03 55 04 06 13 02 ...0S1.0...U.... ssl_msg.c 3965 0380: 55 53 31 0b 30 09 06 03 55 04 08 0c 02 43 41 31 US1.0...U....CA1 ssl_msg.c 3965 0390: 12 30 10 06 03 55 04 07 0c 09 53 6f 6d 65 77 68 .0...U....Somewh ssl_msg.c 3965 03a0: 65 72 65 31 10 30 0e 06 03 55 04 0a 0c 07 53 6f ere1.0...U....So ssl_msg.c 3965 03b0: 6d 65 6f 6e 65 31 11 30 0f 06 03 55 04 03 0c 08 meone1.0...U.... ssl_msg.c 3965 03c0: 46 6f 6f 62 61 72 43 41 30 1e 17 0d 32 34 30 34 FoobarCA0...2404 ssl_msg.c 3965 03d0: 30 33 30 39 33 33 34 30 5a 17 0d 32 35 30 34 30 03093340Z..25040 ssl_msg.c 3965 03e0: 33 30 39 33 33 34 30 5a 30 53 31 0b 30 09 06 03 3093340Z0S1.0... ssl_msg.c 3965 03f0: 55 04 06 13 02 55 53 31 0b 30 09 06 03 55 04 08 U....US1.0...U.. ssl_msg.c 3965 0400: 0c 02 43 41 31 12 30 10 06 03 55 04 07 0c 09 53 ..CA1.0...U....S ssl_msg.c 3965 0410: 6f 6d 65 77 68 65 72 65 31 10 30 0e 06 03 55 04 omewhere1.0...U. ssl_msg.c 3965 0420: 0a 0c 07 53 6f 6d 65 6f 6e 65 31 11 30 0f 06 03 ...Someone1.0... ssl_msg.c 3965 0430: 55 04 03 0c 08 46 6f 6f 62 61 72 43 41 30 82 01 U....FoobarCA0.. ssl_msg.c 3965 0440: 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 "0...*.H........ ssl_msg.c 3965 0450: 03 82 01 0f 00 30 82 01 0a 02 82 01 01 00 c7 25 .....0.........% ssl_msg.c 3965 0460: 6d c2 a1 b4 55 87 c1 90 64 49 5f d0 b4 c3 4a 07 m...U...dI_...J. ssl_msg.c 3965 0470: b8 40 d9 ff 10 5b ea 01 fa a2 d7 06 97 af b2 1a .@...[.......... ssl_msg.c 3965 0480: 72 0f 81 14 10 18 b2 17 dc f3 70 72 18 90 00 87 r.........pr.... ssl_msg.c 3965 0490: 0c 04 bb fa 50 8c ee d6 f0 83 1e ea 97 54 cb 37 ....P........T.7 ssl_msg.c 3965 04a0: 1f 5e b8 a5 fc b8 90 5d 88 2a b4 7e a8 5f 9c dc .^.....].*.~._.. ssl_msg.c 3965 04b0: b7 e5 3c 5b c3 d0 21 0e ed 81 16 a0 81 54 42 17 ..<[..!......TB. ssl_msg.c 3965 04c0: 02 bf 79 3d b2 11 dc 3d 35 e1 36 a1 c4 55 0d 8f ..y=...=5.6..U.. ssl_msg.c 3965 04d0: c5 31 87 7c be 02 20 6e de 3e aa c5 e5 25 03 37 .1.|.. n.>...%.7 ssl_msg.c 3965 04e0: 13 c7 17 18 36 5f 80 bd d4 d7 d3 f7 60 4c 0b 04 ....6_......`L.. ssl_msg.c 3965 04f0: 33 aa a6 c9 49 fa df b4 7c 13 7d 37 67 a7 8c b7 3...I...|.}7g... ssl_msg.c 3965 0500: c4 12 45 8a 88 80 f9 80 8f ab df f8 3c 78 e6 2c ..E.........<x., ssl_msg.c 3965 0510: e1 03 2c 7e de 8f af ad 75 ad d5 31 3d af 25 8e ..,~....u..1=.%. ssl_msg.c 3965 0520: ae 2e 61 c9 33 eb e2 0d 31 74 06 f8 f5 06 8d b0 ..a.3...1t...... ssl_msg.c 3965 0530: ac c4 f5 5f 7b c8 5e 4c 7f ed 26 a4 7e c6 d4 23 ..._{.^L..&.~..# ssl_msg.c 3965 0540: 2c 99 d3 b2 a8 a0 68 c0 f9 5d be f8 ef 2c f2 6f ,.....h..]...,.o ssl_msg.c 3965 0550: 8e 21 a6 06 1a ca 81 ef ef 95 5e 29 9d db 02 03 .!........^).... ssl_msg.c 3965 0560: 01 00 01 a3 53 30 51 30 1d 06 03 55 1d 0e 04 16 ....S0Q0...U.... ssl_msg.c 3965 0570: 04 14 94 e0 bc ab b9 f5 8a 65 8a 45 64 d9 83 2e .........e.Ed... ssl_msg.c 3965 0580: 41 ec b0 14 8d 87 30 1f 06 03 55 1d 23 04 18 30 A.....0...U.#..0 ssl_msg.c 3965 0590: 16 80 14 94 e0 bc ab b9 f5 8a 65 8a 45 64 d9 83 ..........e.Ed.. ssl_msg.c 3965 05a0: 2e 41 ec b0 14 8d 87 30 0f 06 03 55 1d 13 01 01 .A.....0...U.... ssl_msg.c 3965 05b0: ff 04 05 30 03 01 01 ff 30 0d 06 09 2a 86 48 86 ...0....0...*.H. ssl_msg.c 3965 05c0: f7 0d 01 01 0b 05 00 03 82 01 01 00 ae 3d e2 42 .............=.B ssl_msg.c 3965 05d0: 91 fe d5 70 a5 28 44 4d 0c 66 78 fc cd 07 89 24 ...p.(DM.fx....$ ssl_msg.c 3965 05e0: 1e 2f a7 55 08 c0 69 9f 2a 37 90 bf 93 da 5e 6a ./.U..i.*7....^j ssl_msg.c 3965 05f0: 75 5e 3f 53 29 e2 13 9c 3a 3e 6a 0a 99 ca 09 51 u^?S)...:>j....Q ssl_msg.c 3965 0600: 91 2a 23 d0 ad df 36 cc e2 e0 e6 0d cb 00 33 57 .*#...6.......3W ssl_msg.c 3965 0610: db b0 a5 70 98 e9 60 1b 91 9e ec c7 64 ad 14 79 ...p..`.....d..y ssl_msg.c 3965 0620: 0e 08 22 ef a8 0e 1a 71 a0 3a 17 04 9f 0c a8 12 .."....q.:...... ssl_msg.c 3965 0630: 26 55 0d 09 09 77 4e 9e 2f cf 1c 34 f8 e8 40 19 &U...wN./..4..@. ssl_msg.c 3965 0640: 19 c2 9d 31 2d c2 a0 a1 fa bd 9b 49 31 c9 dd b9 ...1-......I1... ssl_msg.c 3965 0650: 87 a2 bc 7e 60 e1 b8 88 57 84 d6 11 08 b2 33 94 ...~`...W.....3. ssl_msg.c 3965 0660: bd 19 77 78 df e1 5f e3 c9 aa 05 ad df f7 ac 0f ..wx.._......... ssl_msg.c 3965 0670: 48 06 83 43 51 1d 0c f8 62 c0 4b 78 a1 ff 5e 9a H..CQ...b.Kx..^. ssl_msg.c 3965 0680: f1 e5 a7 bb 85 8f ee b8 3a e0 17 69 5b 0b 49 19 ........:..i[.I. ssl_msg.c 3965 0690: 36 e0 ee 12 0b 63 99 c0 26 71 d7 22 20 9e 30 a1 6....c..&q." .0. ssl_msg.c 3965 06a0: 93 75 69 71 32 65 e6 c4 3f 31 cd 87 f3 b0 0c b0 .uiq2e..?1...... ssl_msg.c 3965 06b0: 5b 05 4d 1c ce a1 45 c2 0b 92 e0 8c 72 cc 99 5d [.M...E.....r..] ssl_msg.c 3965 06c0: 44 27 2b 6b 1e cf 62 03 b4 9c e6 42 D'+k..b....B ssl_msg.c 3234 handshake message: msglen = 1735, type = 11, hslen = 1735 ssl_msg.c 4261 <= read record ssl_tls.c 7887 peer certificate #1: ssl_tls.c 7887 cert. version : 1 ssl_tls.c 7887 serial number : 6D:4F:99:2E:33:C5:10:1E:EA:27:57:74:8F:CF:4D:01:60:54:51:76 ssl_tls.c 7887 issuer name : C=US, ST=CA, L=Somewhere, O=Someone, CN=FoobarCA ssl_tls.c 7887 subject name : C=US, ST=CA, L=Somewhere, O=Someone, CN=Foobar ssl_tls.c 7887 issued on : 2024-04-03 09:35:00 ssl_tls.c 7887 expires on : 2025-04-03 09:35:00 ssl_tls.c 7887 signed using : RSA with SHA-256 ssl_tls.c 7887 RSA key size : 2048 bits ssl_tls.c 7887 value of 'crt->rsa.N' (2048 bits) is: ssl_tls.c 7887 c1 9f d8 d2 15 fe e5 68 e8 fe 65 21 e4 c4 78 ea ssl_tls.c 7887 22 da 31 4d 08 77 df 03 d5 13 03 ec 36 8f d1 d3 ssl_tls.c 7887 c1 5c 15 52 fd 9d c8 27 f2 ca 51 79 18 22 95 d7 ssl_tls.c 7887 6b 09 72 96 79 5a d0 cd cc ac 20 2e f2 05 cb 57 ssl_tls.c 7887 57 f3 91 07 9f 3d d7 2c e7 4e 97 56 31 0a 3c 04 ssl_tls.c 7887 fd 43 9d ee 9f e7 5b d8 b7 41 0e d8 9b 28 8b 82 ssl_tls.c 7887 33 cd ff 7d db 8c c2 3d b6 c0 ff 48 df dd bb 9e ssl_tls.c 7887 d6 d1 84 0a d5 f5 f5 c4 88 cc 7f 2b 82 67 f0 9c ssl_tls.c 7887 47 54 27 00 6a f0 59 0a d6 0f 84 a9 10 8f d2 a5 ssl_tls.c 7887 d3 26 53 3c 28 57 94 01 06 8a 1d ff 90 e2 48 25 ssl_tls.c 7887 55 7e fd 03 cc 2c 6b e4 0e 3e 09 b2 2c 97 23 32 ssl_tls.c 7887 29 b2 55 a4 f1 37 3d 1c f8 d0 a3 4b 6d 78 db 68 ssl_tls.c 7887 2c ac 6e 6b d6 14 2e 86 e6 0f 3d d1 61 38 de ba ssl_tls.c 7887 cb bf 4f d8 d0 af 66 b2 3f 09 0e 51 c5 4b c6 d2 ssl_tls.c 7887 c0 90 8a db 51 98 32 bf a3 9b e9 94 a2 69 9a 0a ssl_tls.c 7887 e1 a1 6e ad 63 59 92 e2 81 4a 29 36 84 36 33 2b ssl_tls.c 7887 value of 'crt->rsa.E' (17 bits) is: ssl_tls.c 7887 01 00 01 ssl_tls.c 7887 peer certificate #2: ssl_tls.c 7887 cert. version : 3 ssl_tls.c 7887 serial number : 22:DF:A0:F5:03:EC:52:A6:04:2E:69:B4:86:56:5F:5C:29:EC:05:E6 ssl_tls.c 7887 issuer name : C=US, ST=CA, L=Somewhere, O=Someone, CN=FoobarCA ssl_tls.c 7887 subject name : C=US, ST=CA, L=Somewhere, O=Someone, CN=FoobarCA ssl_tls.c 7887 issued on : 2024-04-03 09:33:40 ssl_tls.c 7887 expires on : 2025-04-03 09:33:40 ssl_tls.c 7887 signed using : RSA with SHA-256 ssl_tls.c 7887 RSA key size : 2048 bits ssl_tls.c 7887 basic constraints : CA=true ssl_tls.c 7887 value of 'crt->rsa.N' (2048 bits) is: ssl_tls.c 7887 c7 25 6d c2 a1 b4 55 87 c1 90 64 49 5f d0 b4 c3 ssl_tls.c 7887 4a 07 b8 40 d9 ff 10 5b ea 01 fa a2 d7 06 97 af ssl_tls.c 7887 b2 1a 72 0f 81 14 10 18 b2 17 dc f3 70 72 18 90 ssl_tls.c 7887 00 87 0c 04 bb fa 50 8c ee d6 f0 83 1e ea 97 54 ssl_tls.c 7887 cb 37 1f 5e b8 a5 fc b8 90 5d 88 2a b4 7e a8 5f ssl_tls.c 7887 9c dc b7 e5 3c 5b c3 d0 21 0e ed 81 16 a0 81 54 ssl_tls.c 7887 42 17 02 bf 79 3d b2 11 dc 3d 35 e1 36 a1 c4 55 ssl_tls.c 7887 0d 8f c5 31 87 7c be 02 20 6e de 3e aa c5 e5 25 ssl_tls.c 7887 03 37 13 c7 17 18 36 5f 80 bd d4 d7 d3 f7 60 4c ssl_tls.c 7887 0b 04 33 aa a6 c9 49 fa df b4 7c 13 7d 37 67 a7 ssl_tls.c 7887 8c b7 c4 12 45 8a 88 80 f9 80 8f ab df f8 3c 78 ssl_tls.c 7887 e6 2c e1 03 2c 7e de 8f af ad 75 ad d5 31 3d af ssl_tls.c 7887 25 8e ae 2e 61 c9 33 eb e2 0d 31 74 06 f8 f5 06 ssl_tls.c 7887 8d b0 ac c4 f5 5f 7b c8 5e 4c 7f ed 26 a4 7e c6 ssl_tls.c 7887 d4 23 2c 99 d3 b2 a8 a0 68 c0 f9 5d be f8 ef 2c ssl_tls.c 7887 f2 6f 8e 21 a6 06 1a ca 81 ef ef 95 5e 29 9d db ssl_tls.c 7887 value of 'crt->rsa.E' (17 bits) is: ssl_tls.c 7887 01 00 01 ssl_tls.c 7971 Use configuration-specific verification callback ssl_tls.c 8131 Certificate verification flags clear ssl_tls.c 8317 <= parse certificate ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_SERVER_KEY_EXCHANGE ssl_tls12_client.c 2087 => parse server key exchange ssl_msg.c 4189 => read record ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 0, nb_want: 5 ssl_msg.c 2317 in_left: 0, nb_want: 5 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_msg.c 2340 <= fetch input ssl_msg.c 3855 dumping 'input record header' (5 bytes) ssl_msg.c 3855 0000: 16 03 03 01 2c ...., ssl_msg.c 3859 input record: msgtype = 22, version = [0x303], msglen = 300 ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 5, nb_want: 305 ssl_msg.c 2317 in_left: 5, nb_want: 305 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 300 (-0xfffffed4) ssl_msg.c 2340 <= fetch input ssl_msg.c 3965 dumping 'input record from network' (305 bytes) ssl_msg.c 3965 0000: 16 03 03 01 2c 0c 00 01 28 03 00 1d 20 d1 dc 58 ....,...(... ..X ssl_msg.c 3965 0010: 0a 95 f2 2c 9a 5b 5d 6a 96 53 04 07 5e 7c fb 67 ...,.[]j.S..^|.g ssl_msg.c 3965 0020: 80 80 17 6f f6 93 fb 9c 39 8c 36 73 0c 06 01 01 ...o....9.6s.... ssl_msg.c 3965 0030: 00 83 85 1c 02 f2 1f 5a 80 d6 b1 98 0f 70 0a 06 .......Z.....p.. ssl_msg.c 3965 0040: 39 d9 d7 fe 69 75 69 4c 3b 90 7d b9 ec 8a 16 63 9...iuiL;.}....c ssl_msg.c 3965 0050: e8 da de 3b e2 79 24 fc 17 7c 6f 3d a5 c0 4b 4d ...;.y$..|o=..KM ssl_msg.c 3965 0060: e1 5f 6d d5 ac 82 fc 47 a6 b3 3e 6d 4e 48 b3 0d ._m....G..>mNH.. ssl_msg.c 3965 0070: 12 76 9e b0 08 f2 23 56 80 c7 53 30 51 62 6e 64 .v....#V..S0Qbnd ssl_msg.c 3965 0080: 1b b0 b2 35 6f 6c 5b e9 a7 17 59 65 c5 e5 c0 3c ...5ol[...Ye...< ssl_msg.c 3965 0090: b0 6b ed 2b 39 ea b9 a4 06 0f e3 e6 20 24 f5 33 .k.+9....... $.3 ssl_msg.c 3965 00a0: e5 ee 0c 44 90 1a a1 96 53 78 e0 80 d0 ac f8 3e ...D....Sx.....> ssl_msg.c 3965 00b0: 92 4c c7 85 ac ba ab 7d 81 b6 3e d9 18 23 b2 72 .L.....}..>..#.r ssl_msg.c 3965 00c0: e2 39 68 3b 93 a2 d8 e8 cf f5 69 fe 11 49 02 5a .9h;......i..I.Z ssl_msg.c 3965 00d0: 8c 72 41 3f 17 76 b3 8e 13 15 97 b3 fb c5 ca 7f .rA?.v.......... ssl_msg.c 3965 00e0: 74 6e 75 7b 86 e6 02 ee bc 8a 37 47 92 94 a9 89 tnu{......7G.... ssl_msg.c 3965 00f0: d9 05 a6 7c b4 12 a3 6a 78 99 d8 a0 a6 d6 bb 2e ...|...jx....... ssl_msg.c 3965 0100: 21 93 4d 22 e3 2a c8 2c 47 6f 08 06 8b 7d 46 56 !.M".*.,Go...}FV ssl_msg.c 3965 0110: 9f 1c bb d4 63 94 d2 e3 4f e2 1a de 88 86 23 06 ....c...O.....#. ssl_msg.c 3965 0120: 7d 9f e3 34 d6 76 b7 85 4f 2f b1 61 b2 89 72 58 }..4.v..O/.a..rX ssl_msg.c 3965 0130: 82 . ssl_msg.c 3234 handshake message: msglen = 300, type = 12, hslen = 300 ssl_msg.c 4261 <= read record ssl_tls12_client.c 2174 dumping 'server key exchange' (296 bytes) ssl_tls12_client.c 2174 0000: 03 00 1d 20 d1 dc 58 0a 95 f2 2c 9a 5b 5d 6a 96 ... ..X...,.[]j. ssl_tls12_client.c 2174 0010: 53 04 07 5e 7c fb 67 80 80 17 6f f6 93 fb 9c 39 S..^|.g...o....9 ssl_tls12_client.c 2174 0020: 8c 36 73 0c 06 01 01 00 83 85 1c 02 f2 1f 5a 80 .6s...........Z. ssl_tls12_client.c 2174 0030: d6 b1 98 0f 70 0a 06 39 d9 d7 fe 69 75 69 4c 3b ....p..9...iuiL; ssl_tls12_client.c 2174 0040: 90 7d b9 ec 8a 16 63 e8 da de 3b e2 79 24 fc 17 .}....c...;.y$.. ssl_tls12_client.c 2174 0050: 7c 6f 3d a5 c0 4b 4d e1 5f 6d d5 ac 82 fc 47 a6 |o=..KM._m....G. ssl_tls12_client.c 2174 0060: b3 3e 6d 4e 48 b3 0d 12 76 9e b0 08 f2 23 56 80 .>mNH...v....#V. ssl_tls12_client.c 2174 0070: c7 53 30 51 62 6e 64 1b b0 b2 35 6f 6c 5b e9 a7 .S0Qbnd...5ol[.. ssl_tls12_client.c 2174 0080: 17 59 65 c5 e5 c0 3c b0 6b ed 2b 39 ea b9 a4 06 .Ye...<.k.+9.... ssl_tls12_client.c 2174 0090: 0f e3 e6 20 24 f5 33 e5 ee 0c 44 90 1a a1 96 53 ... $.3...D....S ssl_tls12_client.c 2174 00a0: 78 e0 80 d0 ac f8 3e 92 4c c7 85 ac ba ab 7d 81 x.....>.L.....}. ssl_tls12_client.c 2174 00b0: b6 3e d9 18 23 b2 72 e2 39 68 3b 93 a2 d8 e8 cf .>..#.r.9h;..... ssl_tls12_client.c 2174 00c0: f5 69 fe 11 49 02 5a 8c 72 41 3f 17 76 b3 8e 13 .i..I.Z.rA?.v... ssl_tls12_client.c 2174 00d0: 15 97 b3 fb c5 ca 7f 74 6e 75 7b 86 e6 02 ee bc .......tnu{..... ssl_tls12_client.c 2174 00e0: 8a 37 47 92 94 a9 89 d9 05 a6 7c b4 12 a3 6a 78 .7G.......|...jx ssl_tls12_client.c 2174 00f0: 99 d8 a0 a6 d6 bb 2e 21 93 4d 22 e3 2a c8 2c 47 .......!.M".*.,G ssl_tls12_client.c 2174 0100: 6f 08 06 8b 7d 46 56 9f 1c bb d4 63 94 d2 e3 4f o...}FV....c...O ssl_tls12_client.c 2174 0110: e2 1a de 88 86 23 06 7d 9f e3 34 d6 76 b7 85 4f .....#.}..4.v..O ssl_tls12_client.c 2174 0120: 2f b1 61 b2 89 72 58 82 /.a..rX. ssl_tls12_client.c 1804 ECDH curve: x25519 ssl_tls12_client.c 1811 value of 'ECDH: Qp(X)' (252 bits) is: ssl_tls12_client.c 1811 0c 73 36 8c 39 9c fb 93 f6 6f 17 80 80 67 fb 7c ssl_tls12_client.c 1811 5e 07 04 53 96 6a 5d 5b 9a 2c f2 95 0a 58 dc d1 ssl_tls12_client.c 1811 value of 'ECDH: Qp(Y)' (0 bits) is: ssl_tls12_client.c 1811 00 ssl_tls12_client.c 2369 dumping 'signature' (256 bytes) ssl_tls12_client.c 2369 0000: 83 85 1c 02 f2 1f 5a 80 d6 b1 98 0f 70 0a 06 39 ......Z.....p..9 ssl_tls12_client.c 2369 0010: d9 d7 fe 69 75 69 4c 3b 90 7d b9 ec 8a 16 63 e8 ...iuiL;.}....c. ssl_tls12_client.c 2369 0020: da de 3b e2 79 24 fc 17 7c 6f 3d a5 c0 4b 4d e1 ..;.y$..|o=..KM. ssl_tls12_client.c 2369 0030: 5f 6d d5 ac 82 fc 47 a6 b3 3e 6d 4e 48 b3 0d 12 _m....G..>mNH... ssl_tls12_client.c 2369 0040: 76 9e b0 08 f2 23 56 80 c7 53 30 51 62 6e 64 1b v....#V..S0Qbnd. ssl_tls12_client.c 2369 0050: b0 b2 35 6f 6c 5b e9 a7 17 59 65 c5 e5 c0 3c b0 ..5ol[...Ye...<. ssl_tls12_client.c 2369 0060: 6b ed 2b 39 ea b9 a4 06 0f e3 e6 20 24 f5 33 e5 k.+9....... $.3. ssl_tls12_client.c 2369 0070: ee 0c 44 90 1a a1 96 53 78 e0 80 d0 ac f8 3e 92 ..D....Sx.....>. ssl_tls12_client.c 2369 0080: 4c c7 85 ac ba ab 7d 81 b6 3e d9 18 23 b2 72 e2 L.....}..>..#.r. ssl_tls12_client.c 2369 0090: 39 68 3b 93 a2 d8 e8 cf f5 69 fe 11 49 02 5a 8c 9h;......i..I.Z. ssl_tls12_client.c 2369 00a0: 72 41 3f 17 76 b3 8e 13 15 97 b3 fb c5 ca 7f 74 rA?.v..........t ssl_tls12_client.c 2369 00b0: 6e 75 7b 86 e6 02 ee bc 8a 37 47 92 94 a9 89 d9 nu{......7G..... ssl_tls12_client.c 2369 00c0: 05 a6 7c b4 12 a3 6a 78 99 d8 a0 a6 d6 bb 2e 21 ..|...jx.......! ssl_tls12_client.c 2369 00d0: 93 4d 22 e3 2a c8 2c 47 6f 08 06 8b 7d 46 56 9f .M".*.,Go...}FV. ssl_tls12_client.c 2369 00e0: 1c bb d4 63 94 d2 e3 4f e2 1a de 88 86 23 06 7d ...c...O.....#.} ssl_tls12_client.c 2369 00f0: 9f e3 34 d6 76 b7 85 4f 2f b1 61 b2 89 72 58 82 ..4.v..O/.a..rX. ssl_tls.c 9411 Perform mbedtls-based computation of digest of ServerKeyExchange ssl_tls12_client.c 2386 dumping 'parameters hash' (64 bytes) ssl_tls12_client.c 2386 0000: 04 50 e7 cb 0e a3 db f5 c8 ad 2c 78 fe 22 5b 66 .P........,x."[f ssl_tls12_client.c 2386 0010: 9d 11 f8 4f 4a f4 78 0a 2f ce 2e 77 88 69 80 7f ...OJ.x./..w.i.. ssl_tls12_client.c 2386 0020: 6b 7c c8 8e 0b ec f0 c5 b4 c5 1f 4e b6 4a 71 10 k|.........N.Jq. ssl_tls12_client.c 2386 0030: 27 80 74 57 8f 67 56 5c 5f 0e 7b 8b 15 ad da 2e '.tW.gV\_.{..... ssl_tls12_client.c 2457 <= parse server key exchange ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_CERTIFICATE_REQUEST ssl_tls12_client.c 2496 => parse certificate request ssl_msg.c 4189 => read record ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 0, nb_want: 5 ssl_msg.c 2317 in_left: 0, nb_want: 5 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_msg.c 2340 <= fetch input ssl_msg.c 3855 dumping 'input record header' (5 bytes) ssl_msg.c 3855 0000: 16 03 03 00 8b ..... ssl_msg.c 3859 input record: msgtype = 22, version = [0x303], msglen = 139 ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 5, nb_want: 144 ssl_msg.c 2317 in_left: 5, nb_want: 144 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 139 (-0xffffff75) ssl_msg.c 2340 <= fetch input ssl_msg.c 3965 dumping 'input record from network' (144 bytes) ssl_msg.c 3965 0000: 16 03 03 00 8b 0d 00 00 87 03 01 02 40 00 28 04 ............@.(. ssl_msg.c 3965 0010: 03 05 03 06 03 08 07 08 08 08 09 08 0a 08 0b 08 ................ ssl_msg.c 3965 0020: 04 08 05 08 06 04 01 05 01 06 01 03 03 03 01 03 ................ ssl_msg.c 3965 0030: 02 04 02 05 02 06 02 00 57 00 55 30 53 31 0b 30 ........W.U0S1.0 ssl_msg.c 3965 0040: 09 06 03 55 04 06 13 02 55 53 31 0b 30 09 06 03 ...U....US1.0... ssl_msg.c 3965 0050: 55 04 08 0c 02 43 41 31 12 30 10 06 03 55 04 07 U....CA1.0...U.. ssl_msg.c 3965 0060: 0c 09 53 6f 6d 65 77 68 65 72 65 31 10 30 0e 06 ..Somewhere1.0.. ssl_msg.c 3965 0070: 03 55 04 0a 0c 07 53 6f 6d 65 6f 6e 65 31 11 30 .U....Someone1.0 ssl_msg.c 3965 0080: 0f 06 03 55 04 03 0c 08 46 6f 6f 62 61 72 43 41 ...U....FoobarCA ssl_msg.c 3234 handshake message: msglen = 139, type = 13, hslen = 139 ssl_msg.c 4261 <= read record ssl_tls12_client.c 2523 got a certificate request ssl_tls12_client.c 2613 Supported Signature Algorithm found: 04 03 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 05 03 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 06 03 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 08 07 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 08 08 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 08 09 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 08 0a ssl_tls12_client.c 2613 Supported Signature Algorithm found: 08 0b ssl_tls12_client.c 2613 Supported Signature Algorithm found: 08 04 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 08 05 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 08 06 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 04 01 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 05 01 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 06 01 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 03 03 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 03 01 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 03 02 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 04 02 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 05 02 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 06 02 ssl_tls12_client.c 2652 DN hint: C=US, ST=CA, L=Somewhere, O=Someone, CN=FoobarCA ssl_tls12_client.c 2658 <= parse certificate request ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_SERVER_HELLO_DONE ssl_tls12_client.c 2669 => parse server hello done ssl_msg.c 4189 => read record ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 0, nb_want: 5 ssl_msg.c 2317 in_left: 0, nb_want: 5 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_msg.c 2340 <= fetch input ssl_msg.c 3855 dumping 'input record header' (5 bytes) ssl_msg.c 3855 0000: 16 03 03 00 04 ..... ssl_msg.c 3859 input record: msgtype = 22, version = [0x303], msglen = 4 ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 5, nb_want: 9 ssl_msg.c 2317 in_left: 5, nb_want: 9 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 4 (-0xfffffffc) ssl_msg.c 2340 <= fetch input ssl_msg.c 3965 dumping 'input record from network' (9 bytes) ssl_msg.c 3965 0000: 16 03 03 00 04 0e 00 00 00 ......... ssl_msg.c 3234 handshake message: msglen = 4, type = 14, hslen = 4 ssl_msg.c 4261 <= read record ssl_tls12_client.c 2697 <= parse server hello done ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_CLIENT_CERTIFICATE ssl_tls.c 7610 => write certificate ssl_tls.c 7637 own certificate #1: ssl_tls.c 7637 cert. version : 1 ssl_tls.c 7637 serial number : 6D:4F:99:2E:33:C5:10:1E:EA:27:57:74:8F:CF:4D:01:60:54:51:77 ssl_tls.c 7637 issuer name : C=US, ST=CA, L=Somewhere, O=Someone, CN=FoobarCA ssl_tls.c 7637 subject name : C=US, ST=CA, L=Somewhere, O=Someone, CN=Foobar ssl_tls.c 7637 issued on : 2024-04-03 09:36:01 ssl_tls.c 7637 expires on : 2025-04-03 09:36:01 ssl_tls.c 7637 signed using : RSA with SHA-256 ssl_tls.c 7637 RSA key size : 2048 bits ssl_tls.c 7637 value of 'crt->rsa.N' (2048 bits) is: ssl_tls.c 7637 a8 58 0d 38 1a 61 12 1b 16 45 c5 b8 63 6e a8 91 ssl_tls.c 7637 e4 78 c4 48 e6 cc f9 04 09 33 b4 8e d3 2d e8 6d ssl_tls.c 7637 fe 93 d1 c6 d5 82 fe 9f 15 de d1 06 8f ac df 76 ssl_tls.c 7637 ef 7f 4d 8c fe 00 ed 5c fa 5e 74 84 06 c8 2d d1 ssl_tls.c 7637 d7 57 6c 9f 56 3e 5e 09 b0 4c 2d 43 0d b6 ef 26 ssl_tls.c 7637 c9 6f 6b 28 1b 74 bb 4a e8 e9 66 8c de 8f b7 fe ssl_tls.c 7637 6c cc dd 8d ea e7 77 39 9d b5 24 42 5e 4a d7 d1 ssl_tls.c 7637 4a fd f4 81 0f 98 ed 8b 37 d9 3d 5b a8 b4 5b 66 ssl_tls.c 7637 57 2c 01 c0 5c 9c 94 cd 9c 9c 23 58 77 99 7e e5 ssl_tls.c 7637 81 87 51 2c 06 ce 8b 43 bb 2f af 7a ae 49 2a 02 ssl_tls.c 7637 6a 1f dd bb 84 1f 49 bb b3 17 37 46 73 b1 33 b0 ssl_tls.c 7637 73 22 58 26 1b 97 14 9f a6 f4 1a 18 86 51 df a6 ssl_tls.c 7637 df 5a e0 78 6b 48 58 20 d7 ae 8b 6b d5 4d e4 c8 ssl_tls.c 7637 96 73 dc 03 8e 5f 99 52 10 a2 9b a2 22 79 10 e3 ssl_tls.c 7637 38 93 33 b5 46 5a f8 3d 61 9e d5 31 ae 8a 34 d3 ssl_tls.c 7637 0c 64 39 42 ab a9 44 8b bf f6 b9 fb 92 92 14 df ssl_tls.c 7637 value of 'crt->rsa.E' (17 bits) is: ssl_tls.c 7637 01 00 01 ssl_msg.c 2783 => write handshake message ssl_msg.c 2943 => write record ssl_msg.c 3030 output record: msgtype = 22, version = [3:3], msglen = 825 ssl_msg.c 3033 dumping 'output record sent to network' (830 bytes) ssl_msg.c 3033 0000: 16 03 03 03 39 0b 00 03 35 00 03 32 00 03 2f 30 ....9...5..2../0 ssl_msg.c 3033 0010: 82 03 2b 30 82 02 13 02 14 6d 4f 99 2e 33 c5 10 ..+0.....mO..3.. ssl_msg.c 3033 0020: 1e ea 27 57 74 8f cf 4d 01 60 54 51 77 30 0d 06 ..'Wt..M.`TQw0.. ssl_msg.c 3033 0030: 09 2a 86 48 86 f7 0d 01 01 0b 05 00 30 53 31 0b .*.H........0S1. ssl_msg.c 3033 0040: 30 09 06 03 55 04 06 13 02 55 53 31 0b 30 09 06 0...U....US1.0.. ssl_msg.c 3033 0050: 03 55 04 08 0c 02 43 41 31 12 30 10 06 03 55 04 .U....CA1.0...U. ssl_msg.c 3033 0060: 07 0c 09 53 6f 6d 65 77 68 65 72 65 31 10 30 0e ...Somewhere1.0. ssl_msg.c 3033 0070: 06 03 55 04 0a 0c 07 53 6f 6d 65 6f 6e 65 31 11 ..U....Someone1. ssl_msg.c 3033 0080: 30 0f 06 03 55 04 03 0c 08 46 6f 6f 62 61 72 43 0...U....FoobarC ssl_msg.c 3033 0090: 41 30 1e 17 0d 32 34 30 34 30 33 30 39 33 36 30 A0...24040309360 ssl_msg.c 3033 00a0: 31 5a 17 0d 32 35 30 34 30 33 30 39 33 36 30 31 1Z..250403093601 ssl_msg.c 3033 00b0: 5a 30 51 31 0b 30 09 06 03 55 04 06 13 02 55 53 Z0Q1.0...U....US ssl_msg.c 3033 00c0: 31 0b 30 09 06 03 55 04 08 0c 02 43 41 31 12 30 1.0...U....CA1.0 ssl_msg.c 3033 00d0: 10 06 03 55 04 07 0c 09 53 6f 6d 65 77 68 65 72 ...U....Somewher ssl_msg.c 3033 00e0: 65 31 10 30 0e 06 03 55 04 0a 0c 07 53 6f 6d 65 e1.0...U....Some ssl_msg.c 3033 00f0: 6f 6e 65 31 0f 30 0d 06 03 55 04 03 0c 06 46 6f one1.0...U....Fo ssl_msg.c 3033 0100: 6f 62 61 72 30 82 01 22 30 0d 06 09 2a 86 48 86 obar0.."0...*.H. ssl_msg.c 3033 0110: f7 0d 01 01 01 05 00 03 82 01 0f 00 30 82 01 0a ............0... ssl_msg.c 3033 0120: 02 82 01 01 00 a8 58 0d 38 1a 61 12 1b 16 45 c5 ......X.8.a...E. ssl_msg.c 3033 0130: b8 63 6e a8 91 e4 78 c4 48 e6 cc f9 04 09 33 b4 .cn...x.H.....3. ssl_msg.c 3033 0140: 8e d3 2d e8 6d fe 93 d1 c6 d5 82 fe 9f 15 de d1 ..-.m........... ssl_msg.c 3033 0150: 06 8f ac df 76 ef 7f 4d 8c fe 00 ed 5c fa 5e 74 ....v..M....\.^t ssl_msg.c 3033 0160: 84 06 c8 2d d1 d7 57 6c 9f 56 3e 5e 09 b0 4c 2d ...-..Wl.V>^..L- ssl_msg.c 3033 0170: 43 0d b6 ef 26 c9 6f 6b 28 1b 74 bb 4a e8 e9 66 C...&.ok(.t.J..f ssl_msg.c 3033 0180: 8c de 8f b7 fe 6c cc dd 8d ea e7 77 39 9d b5 24 .....l.....w9..$ ssl_msg.c 3033 0190: 42 5e 4a d7 d1 4a fd f4 81 0f 98 ed 8b 37 d9 3d B^J..J.......7.= ssl_msg.c 3033 01a0: 5b a8 b4 5b 66 57 2c 01 c0 5c 9c 94 cd 9c 9c 23 [..[fW,..\.....# ssl_msg.c 3033 01b0: 58 77 99 7e e5 81 87 51 2c 06 ce 8b 43 bb 2f af Xw.~...Q,...C./. ssl_msg.c 3033 01c0: 7a ae 49 2a 02 6a 1f dd bb 84 1f 49 bb b3 17 37 z.I*.j.....I...7 ssl_msg.c 3033 01d0: 46 73 b1 33 b0 73 22 58 26 1b 97 14 9f a6 f4 1a Fs.3.s"X&....... ssl_msg.c 3033 01e0: 18 86 51 df a6 df 5a e0 78 6b 48 58 20 d7 ae 8b ..Q...Z.xkHX ... ssl_msg.c 3033 01f0: 6b d5 4d e4 c8 96 73 dc 03 8e 5f 99 52 10 a2 9b k.M...s..._.R... ssl_msg.c 3033 0200: a2 22 79 10 e3 38 93 33 b5 46 5a f8 3d 61 9e d5 ."y..8.3.FZ.=a.. ssl_msg.c 3033 0210: 31 ae 8a 34 d3 0c 64 39 42 ab a9 44 8b bf f6 b9 1..4..d9B..D.... ssl_msg.c 3033 0220: fb 92 92 14 df 02 03 01 00 01 30 0d 06 09 2a 86 ..........0...*. ssl_msg.c 3033 0230: 48 86 f7 0d 01 01 0b 05 00 03 82 01 01 00 1f db H............... ssl_msg.c 3033 0240: c6 fe 9b 7b 85 92 a4 31 2d 4b e9 bb 7e f9 76 84 ...{...1-K..~.v. ssl_msg.c 3033 0250: 36 4e 86 d2 f1 15 c3 fb cd 1b 0e f9 0f b0 1b 8d 6N.............. ssl_msg.c 3033 0260: 53 4c ba fc 56 a7 23 ef cb 5f bc fe 09 a3 b6 c2 SL..V.#.._...... ssl_msg.c 3033 0270: 0e 36 9b aa 03 48 2b 8b fd df 77 3d ee d2 8c f8 .6...H+...w=.... ssl_msg.c 3033 0280: 8f 0e da 8c 81 47 64 6f 8b 3b 2a e2 50 00 6d a0 .....Gdo.;*.P.m. ssl_msg.c 3033 0290: 4a 9c 36 a6 37 c1 34 c6 84 cf ea 14 d1 5b cb 3c J.6.7.4......[.< ssl_msg.c 3033 02a0: df 01 1e 8c ea 21 2f 73 4d b8 e5 7c 88 bd 47 5e .....!/sM..|..G^ ssl_msg.c 3033 02b0: 46 cd 80 20 09 ca 4d f6 13 0c 20 73 44 a8 3f 00 F.. ..M... sD.?. ssl_msg.c 3033 02c0: 7d 5c 0a fb 40 38 d3 7f 3b 29 b5 28 2b 97 39 16 }\..@8..;).(+.9. ssl_msg.c 3033 02d0: 29 06 15 8a 3d 36 b0 2e 7d f3 06 0a 3c 3a 85 e3 )...=6..}...<:.. ssl_msg.c 3033 02e0: 31 06 a5 fc 62 37 8a 8c 12 c8 a1 f3 5f 02 8f 1e 1...b7......_... ssl_msg.c 3033 02f0: 0b 81 de c3 4c 2d bd b7 66 12 e4 d9 3b 29 f2 c1 ....L-..f...;).. ssl_msg.c 3033 0300: 72 c5 2e 45 a0 bb b7 ee 5b d6 0b 7c fe ea b3 a5 r..E....[..|.... ssl_msg.c 3033 0310: 6e e2 53 8b 7d 68 f7 ae 3f a5 fe f5 66 e4 a1 9f n.S.}h..?...f... ssl_msg.c 3033 0320: 2b e3 d0 a2 00 f0 59 83 1a 32 59 eb 86 e6 e5 d1 +.....Y..2Y..... ssl_msg.c 3033 0330: c1 8e 5b 01 bd 50 d4 20 96 5e fb b4 05 6d ..[..P. .^...m ssl_msg.c 2353 => flush output ssl_msg.c 2369 message length: 830, out_left: 830 ssl_msg.c 2374 ssl->f_send() returned 830 (-0xfffffcc2) ssl_msg.c 2401 <= flush output ssl_msg.c 3080 <= write record ssl_msg.c 2904 <= write handshake message ssl_tls.c 7683 <= write certificate ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_CLIENT_KEY_EXCHANGE ssl_tls12_client.c 2712 => write client key exchange ssl_tls12_client.c 2859 value of 'ECDH: Q(X)' (255 bits) is: ssl_tls12_client.c 2859 53 da 7c ff f7 64 59 09 22 ba fd c9 fa 01 db 9e ssl_tls12_client.c 2859 42 7c 2c 76 b0 c3 0d 26 33 11 d6 06 d2 fc 96 f5 ssl_tls12_client.c 2859 value of 'ECDH: Q(Y)' (0 bits) is: ssl_tls12_client.c 2859 00 ssl_tls12_client.c 2887 value of 'ECDH: z' (252 bits) is: ssl_tls12_client.c 2887 0c 8a 79 16 e0 71 b1 7f 8a 4c 01 5b 07 4b e4 e7 ssl_tls12_client.c 2887 5e 9a e6 99 c8 9f 21 0b d2 26 b0 85 10 1a ba 38 ssl_msg.c 2783 => write handshake message ssl_msg.c 2943 => write record ssl_msg.c 3030 output record: msgtype = 22, version = [3:3], msglen = 37 ssl_msg.c 3033 dumping 'output record sent to network' (42 bytes) ssl_msg.c 3033 0000: 16 03 03 00 25 10 00 00 21 20 f5 96 fc d2 06 d6 ....%...! ...... ssl_msg.c 3033 0010: 11 33 26 0d c3 b0 76 2c 7c 42 9e db 01 fa c9 fd .3&...v,|B...... ssl_msg.c 3033 0020: ba 22 09 59 64 f7 ff 7c da 53 .".Yd..|.S ssl_msg.c 2353 => flush output ssl_msg.c 2369 message length: 42, out_left: 42 ssl_msg.c 2374 ssl->f_send() returned 42 (-0xffffffd6) ssl_msg.c 2401 <= flush output ssl_msg.c 3080 <= write record ssl_msg.c 2904 <= write handshake message ssl_tls12_client.c 3207 <= write client key exchange ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_CERTIFICATE_VERIFY ssl_tls12_client.c 3255 => write certificate verify ssl_tls.c 7224 => derive keys ssl_tls.c 7348 => calc verify ssl_tls.c 7366 dumping 'calculated verify result' (32 bytes) ssl_tls.c 7366 0000: 53 fb cc 8e 39 7b 59 88 b6 4b 7f 97 4c db de 63 S...9{Y..K..L..c ssl_tls.c 7366 0010: 55 1e e4 3e a5 6a ae cc a7 e7 63 42 74 f9 51 2d U..>.j....cBt.Q- ssl_tls.c 7367 <= calc verify ssl_tls.c 7079 dumping 'session hash for extended master secret' (32 bytes) ssl_tls.c 7079 0000: 53 fb cc 8e 39 7b 59 88 b6 4b 7f 97 4c db de 63 S...9{Y..K..L..c ssl_tls.c 7079 0010: 55 1e e4 3e a5 6a ae cc a7 e7 63 42 74 f9 51 2d U..>.j....cBt.Q- ssl_tls.c 7209 dumping 'premaster secret' (32 bytes) ssl_tls.c 7209 0000: 38 ba 1a 10 85 b0 26 d2 0b 21 9f c8 99 e6 9a 5e 8.....&..!.....^ ssl_tls.c 7209 0010: e7 e4 4b 07 5b 01 4c 8a 7f b1 71 e0 16 79 8a 0c ..K.[.L...q..y.. ssl_tls.c 8949 ciphersuite = TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256 ssl_tls.c 8950 dumping 'master secret' (48 bytes) ssl_tls.c 8950 0000: 1b 2a 2f 71 31 f9 ba 6e 88 19 f5 c3 b0 62 2b 21 .*/q1..n.....b+! ssl_tls.c 8950 0010: b3 11 18 c6 61 4b c6 2e 4a 32 96 5d df e8 8c 29 ....aK..J2.]...) ssl_tls.c 8950 0020: c0 be c2 85 93 02 76 b2 8c a0 54 f4 df 14 0d 4c ......v...T....L ssl_tls.c 8951 dumping 'random bytes' (64 bytes) ssl_tls.c 8951 0000: 76 36 49 0c df c5 5f 16 59 fa a0 24 de 4f 91 1d v6I..._.Y..$.O.. ssl_tls.c 8951 0010: 01 18 c4 f4 75 a1 f9 ee 64 aa 85 27 40 09 f4 59 ....u...d..'@..Y ssl_tls.c 8951 0020: 66 31 86 39 78 bc 58 af ec e1 20 b2 82 67 fb 9b f1.9x.X... ..g.. ssl_tls.c 8951 0030: 2f 56 40 0f b1 35 c1 b9 27 f1 e5 06 89 c2 23 69 /V@..5..'.....#i ssl_tls.c 8952 dumping 'key block' (256 bytes) ssl_tls.c 8952 0000: 46 12 65 58 80 e2 42 09 cb 76 d5 77 bd 6d 83 dd F.eX..B..v.w.m.. ssl_tls.c 8952 0010: 54 b4 16 f0 37 3c 3a e0 a6 77 b7 02 ff fd df 37 T...7<:..w.....7 ssl_tls.c 8952 0020: cc 85 4b 59 e3 0b 66 80 44 53 be 3e 39 90 ff f9 ..KY..f.DS.>9... ssl_tls.c 8952 0030: ce 56 97 e4 ea 43 52 34 14 cc b3 b8 58 ce d3 b1 .V...CR4....X... ssl_tls.c 8952 0040: f7 c5 6f 77 7c 10 47 fc ac d6 fe 49 58 eb 63 d1 ..ow|.G....IX.c. ssl_tls.c 8952 0050: d9 6f 5b 0a f1 1d b8 97 bc 9c 12 81 9b ad ed 44 .o[............D ssl_tls.c 8952 0060: dd 85 a8 b3 00 ee 50 5f 84 c3 be 41 d4 17 1a 46 ......P_...A...F ssl_tls.c 8952 0070: ab 81 59 65 bc 77 55 15 72 ab 91 3d 96 f0 a4 e8 ..Ye.wU.r..=.... ssl_tls.c 8952 0080: e7 55 f7 48 98 6d a9 17 c4 cc cc ed 06 bf 2e 75 .U.H.m.........u ssl_tls.c 8952 0090: 19 2a c6 07 42 f2 11 3f 0d 84 e9 ce 1f 2a 22 4f .*..B..?.....*"O ssl_tls.c 8952 00a0: 56 92 33 ad 8e 8b 93 01 1a b0 a1 09 9a 54 35 7f V.3..........T5. ssl_tls.c 8952 00b0: a3 bd 68 ab 82 bf 3c 85 c9 52 a9 86 ec bf 1e 23 ..h...<..R.....# ssl_tls.c 8952 00c0: 31 17 7b 72 75 89 a8 15 52 ec 26 2e 39 88 3e aa 1.{ru...R.&.9.>. ssl_tls.c 8952 00d0: 35 b5 7a 35 8e 71 bb 1b c4 ec 1e c2 5b 5e 3d 8f 5.z5.q......[^=. ssl_tls.c 8952 00e0: 9b 69 d2 ea 24 d8 95 5f 0a 9f 83 32 7d 3a 21 33 .i..$.._...2}:!3 ssl_tls.c 8952 00f0: 71 dd 98 ba e3 db 2f 18 bd 7c 45 18 8b d5 4b 31 q...../..|E...K1 ssl_tls.c 9074 keylen: 32, minlen: 16, ivlen: 12, maclen: 0 ssl_tls.c 7275 <= derive keys ssl_tls.c 7348 => calc verify ssl_tls.c 7366 dumping 'calculated verify result' (32 bytes) ssl_tls.c 7366 0000: 53 fb cc 8e 39 7b 59 88 b6 4b 7f 97 4c db de 63 S...9{Y..K..L..c ssl_tls.c 7366 0010: 55 1e e4 3e a5 6a ae cc a7 e7 63 42 74 f9 51 2d U..>.j....cBt.Q- ssl_tls.c 7367 <= calc verify ssl_msg.c 2783 => write handshake message ssl_msg.c 2943 => write record ssl_msg.c 3030 output record: msgtype = 22, version = [3:3], msglen = 264 ssl_msg.c 3033 dumping 'output record sent to network' (269 bytes) ssl_msg.c 3033 0000: 16 03 03 01 08 0f 00 01 04 04 01 01 00 2d 69 d5 .............-i. ssl_msg.c 3033 0010: e7 fd 6f bb db 81 03 16 f7 be 31 31 1b 84 02 04 ..o.......11.... ssl_msg.c 3033 0020: 0e c8 d1 47 0f 4f 17 14 01 23 ec 23 73 cb 44 fd ...G.O...#.#s.D. ssl_msg.c 3033 0030: 95 fd 99 97 6c e0 4e e7 9c 8f f3 05 2a 0d 2f af ....l.N.....*./. ssl_msg.c 3033 0040: ee e8 03 bc 7f 6d 2e 9d c9 d4 1a a8 e3 9b 23 2f .....m........#/ ssl_msg.c 3033 0050: 7a 84 fa df 38 66 a0 f6 9f f8 88 32 59 c7 fc 7b z...8f.....2Y..{ ssl_msg.c 3033 0060: 0e 7d da ca e4 05 31 4e a5 7d 8c b1 18 df 3c 69 .}....1N.}....<i ssl_msg.c 3033 0070: 38 73 b6 25 66 2f 4a dc 17 db d6 cc 4c 76 d9 99 8s.%f/J.....Lv.. ssl_msg.c 3033 0080: 6e 18 98 83 36 56 08 4f 5a 3b 7b e5 97 c9 f5 e7 n...6V.OZ;{..... ssl_msg.c 3033 0090: ec 3a ed 85 6d 68 82 2f 46 d4 0d dc 34 b8 fc a5 .:..mh./F...4... ssl_msg.c 3033 00a0: b0 b6 b6 9b 52 44 96 57 ef 38 ef aa 3a fc 1d ee ....RD.W.8..:... ssl_msg.c 3033 00b0: 5d 93 71 c1 6a 1d b3 06 eb 7c 36 8d f9 bc 90 b2 ].q.j....|6..... ssl_msg.c 3033 00c0: a0 a6 67 c0 24 e9 1d ff 73 81 7d 78 20 6e 94 12 ..g.$...s.}x n.. ssl_msg.c 3033 00d0: 31 1b df db d7 8e 16 d1 ec 19 15 95 b7 83 fb 21 1..............! ssl_msg.c 3033 00e0: 0e e4 ce 71 0b 4f 4f 54 12 29 29 bb 12 5e 87 86 ...q.OOT.))..^.. ssl_msg.c 3033 00f0: 7f b2 16 21 fe a9 8e ce 05 f4 0a 1f c6 04 24 42 ...!..........$B ssl_msg.c 3033 0100: ca d5 50 e9 bb b9 31 d9 cf 82 98 cf 05 ..P...1...... ssl_msg.c 2353 => flush output ssl_msg.c 2369 message length: 269, out_left: 269 ssl_msg.c 2374 ssl->f_send() returned 269 (-0xfffffef3) ssl_msg.c 2401 <= flush output ssl_msg.c 3080 <= write record ssl_msg.c 2904 <= write handshake message ssl_tls12_client.c 3367 <= write certificate verify ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_CLIENT_CHANGE_CIPHER_SPEC ssl_msg.c 5189 => write change cipher spec ssl_msg.c 2783 => write handshake message ssl_msg.c 2943 => write record ssl_msg.c 3030 output record: msgtype = 20, version = [3:3], msglen = 1 ssl_msg.c 3033 dumping 'output record sent to network' (6 bytes) ssl_msg.c 3033 0000: 14 03 03 00 01 01 ...... ssl_msg.c 2353 => flush output ssl_msg.c 2369 message length: 6, out_left: 6 ssl_msg.c 2374 ssl->f_send() returned 6 (-0xfffffffa) ssl_msg.c 2401 <= flush output ssl_msg.c 3080 <= write record ssl_msg.c 2904 <= write handshake message ssl_msg.c 5202 <= write change cipher spec ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_CLIENT_FINISHED ssl_tls.c 8548 => write finished ssl_tls.c 8382 => calc finished tls ssl_tls.c 8399 dumping 'finished output' (32 bytes) ssl_tls.c 8399 0000: 34 68 9c f8 bf d8 cc 6f 86 ef 29 87 e9 d3 94 18 4h.....o..)..... ssl_tls.c 8399 0010: 26 e3 42 ce fa 88 7e 74 bc b4 14 d4 33 d7 7c 44 &.B...~t....3.|D ssl_tls.c 8409 dumping 'calc finished result' (12 bytes) ssl_tls.c 8409 0000: 5a 27 25 d6 93 d6 c1 09 99 b7 ea b4 Z'%......... ssl_tls.c 8413 <= calc finished ssl_tls.c 8597 switching to new transform spec for outbound data ssl_msg.c 2783 => write handshake message ssl_msg.c 2943 => write record ssl_msg.c 935 => encrypt buf ssl_msg.c 958 dumping 'before encrypt: output payload' (16 bytes) ssl_msg.c 958 0000: 14 00 00 0c 5a 27 25 d6 93 d6 c1 09 99 b7 ea b4 ....Z'%......... ssl_msg.c 1183 dumping 'IV used (internal)' (12 bytes) ssl_msg.c 1183 0000: f7 c5 6f 77 7c 10 47 fc ac d6 fe 49 ..ow|.G....I ssl_msg.c 1186 dumping 'IV used (transmitted)' (0 bytes) ssl_msg.c 1188 dumping 'additional data used for AEAD' (13 bytes) ssl_msg.c 1188 0000: 00 00 00 00 00 00 00 00 16 03 03 00 10 ............. ssl_msg.c 1191 before encrypt: msglen = 16, including 0 bytes of padding ssl_msg.c 1225 dumping 'after encrypt: tag' (16 bytes) ssl_msg.c 1225 0000: 58 dc 74 4a 90 c9 22 6c 0f b9 59 29 86 91 14 34 X.tJ.."l..Y)...4 ssl_msg.c 1474 <= encrypt buf ssl_msg.c 3030 output record: msgtype = 22, version = [3:3], msglen = 32 ssl_msg.c 3033 dumping 'output record sent to network' (37 bytes) ssl_msg.c 3033 0000: 16 03 03 00 20 b4 c7 02 81 65 54 f8 16 cc d1 e4 .... ....eT..... ssl_msg.c 3033 0010: f2 46 f9 08 9b 58 dc 74 4a 90 c9 22 6c 0f b9 59 .F...X.tJ.."l..Y ssl_msg.c 3033 0020: 29 86 91 14 34 )...4 ssl_msg.c 2353 => flush output ssl_msg.c 2369 message length: 37, out_left: 37 ssl_msg.c 2374 ssl->f_send() returned 37 (-0xffffffdb) ssl_msg.c 2401 <= flush output ssl_msg.c 3080 <= write record ssl_msg.c 2904 <= write handshake message ssl_tls.c 8650 <= write finished ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_SERVER_CHANGE_CIPHER_SPEC ssl_msg.c 5211 => parse change cipher spec ssl_msg.c 4189 => read record ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 0, nb_want: 5 ssl_msg.c 2317 in_left: 0, nb_want: 5 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 0 (-0x0000) ssl_msg.c 4861 mbedtls_ssl_fetch_input() returned -29312 (-0x7280) ssl_msg.c 4220 ssl_get_next_record() returned -29312 (-0x7280) ssl_msg.c 5214 mbedtls_ssl_read_record() returned -29312 (-0x7280) ssl_tls.c 4635 <= handshake ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 4622 => handshake ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_HELLO_REQUEST ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_CLIENT_HELLO ssl_client.c 919 => write client hello ssl_client.c 725 client hello, current time: 1714521685 ssl_client.c 487 dumping 'client hello, random bytes' (32 bytes) ssl_client.c 487 0000: 66 31 86 55 1d 06 34 0b ef 5c 46 5e 95 8a ea bb f1.U..4..\F^.... ssl_client.c 487 0010: 34 d5 7d de 77 24 bd 19 1f 7d 09 94 0c a8 01 6c 4.}.w$...}.....l ssl_client.c 512 dumping 'session id' (0 bytes) ssl_client.c 371 client hello, add ciphersuite: cca8, TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256 ssl_client.c 371 client hello, add ciphersuite: cca9, TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256 ssl_client.c 371 client hello, add ciphersuite: ccaa, TLS-DHE-RSA-WITH-CHACHA20-POLY1305-SHA256 ssl_client.c 371 client hello, add ciphersuite: c0ad, TLS-ECDHE-ECDSA-WITH-AES-256-CCM ssl_client.c 371 client hello, add ciphersuite: c09f, TLS-DHE-RSA-WITH-AES-256-CCM ssl_client.c 371 client hello, add ciphersuite: 006b, TLS-DHE-RSA-WITH-AES-256-CBC-SHA256 ssl_client.c 371 client hello, add ciphersuite: c00a, TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: c014, TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: 0039, TLS-DHE-RSA-WITH-AES-256-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: c0af, TLS-ECDHE-ECDSA-WITH-AES-256-CCM-8 ssl_client.c 371 client hello, add ciphersuite: c0a3, TLS-DHE-RSA-WITH-AES-256-CCM-8 ssl_client.c 371 client hello, add ciphersuite: c02b, TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256 ssl_client.c 371 client hello, add ciphersuite: c02f, TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256 ssl_client.c 371 client hello, add ciphersuite: 009e, TLS-DHE-RSA-WITH-AES-128-GCM-SHA256 ssl_client.c 371 client hello, add ciphersuite: c0ac, TLS-ECDHE-ECDSA-WITH-AES-128-CCM ssl_client.c 371 client hello, add ciphersuite: c09e, TLS-DHE-RSA-WITH-AES-128-CCM ssl_client.c 371 client hello, add ciphersuite: c023, TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256 ssl_client.c 371 client hello, add ciphersuite: c027, TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256 ssl_client.c 371 client hello, add ciphersuite: 0067, TLS-DHE-RSA-WITH-AES-128-CBC-SHA256 ssl_client.c 371 client hello, add ciphersuite: c009, TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: c013, TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: 0033, TLS-DHE-RSA-WITH-AES-128-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: c0ae, TLS-ECDHE-ECDSA-WITH-AES-128-CCM-8 ssl_client.c 371 client hello, add ciphersuite: c0a2, TLS-DHE-RSA-WITH-AES-128-CCM-8 ssl_client.c 371 client hello, add ciphersuite: c09d, TLS-RSA-WITH-AES-256-CCM ssl_client.c 371 client hello, add ciphersuite: 003d, TLS-RSA-WITH-AES-256-CBC-SHA256 ssl_client.c 371 client hello, add ciphersuite: 0035, TLS-RSA-WITH-AES-256-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: c0a1, TLS-RSA-WITH-AES-256-CCM-8 ssl_client.c 371 client hello, add ciphersuite: 009c, TLS-RSA-WITH-AES-128-GCM-SHA256 ssl_client.c 371 client hello, add ciphersuite: c09c, TLS-RSA-WITH-AES-128-CCM ssl_client.c 371 client hello, add ciphersuite: 003c, TLS-RSA-WITH-AES-128-CBC-SHA256 ssl_client.c 371 client hello, add ciphersuite: 002f, TLS-RSA-WITH-AES-128-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: c0a0, TLS-RSA-WITH-AES-128-CCM-8 ssl_client.c 387 adding EMPTY_RENEGOTIATION_INFO_SCSV ssl_client.c 398 client hello, got 34 cipher suites ssl_client.c 230 client hello, adding supported_groups extension ssl_client.c 249 got supported group(001d) ssl_client.c 283 NamedGroup: x25519 ( 1d ) ssl_client.c 249 got supported group(0017) ssl_client.c 283 NamedGroup: secp256r1 ( 17 ) ssl_client.c 249 got supported group(0018) ssl_client.c 283 NamedGroup: secp384r1 ( 18 ) ssl_client.c 249 got supported group(001e) ssl_client.c 283 NamedGroup: x448 ( 1e ) ssl_client.c 249 got supported group(0019) ssl_client.c 283 NamedGroup: secp521r1 ( 19 ) ssl_client.c 249 got supported group(001a) ssl_client.c 283 NamedGroup: bp256r1 ( 1a ) ssl_client.c 249 got supported group(001b) ssl_client.c 283 NamedGroup: bp384r1 ( 1b ) ssl_client.c 249 got supported group(001c) ssl_client.c 283 NamedGroup: bp512r1 ( 1c ) ssl_client.c 302 dumping 'Supported groups extension' (18 bytes) ssl_client.c 302 0000: 00 10 00 1d 00 17 00 18 00 1e 00 19 00 1a 00 1b ................ ssl_client.c 302 0010: 00 1c .. ssl_tls.c 9611 adding signature_algorithms extension ssl_tls.c 9633 got signature scheme [603] ecdsa_secp521r1_sha512 ssl_tls.c 9642 sent signature scheme [603] ecdsa_secp521r1_sha512 ssl_tls.c 9633 got signature scheme [806] rsa_pss_rsae_sha512 ssl_tls.c 9633 got signature scheme [601] rsa_pkcs1_sha512 ssl_tls.c 9642 sent signature scheme [601] rsa_pkcs1_sha512 ssl_tls.c 9633 got signature scheme [403] ecdsa_secp256r1_sha256 ssl_tls.c 9642 sent signature scheme [403] ecdsa_secp256r1_sha256 ssl_tls.c 9633 got signature scheme [804] rsa_pss_rsae_sha256 ssl_tls.c 9633 got signature scheme [401] rsa_pkcs1_sha256 ssl_tls.c 9642 sent signature scheme [401] rsa_pkcs1_sha256 ssl_tls12_client.c 106 client hello, adding supported_point_formats extension ssl_tls12_client.c 307 client hello, adding encrypt_then_mac extension ssl_tls12_client.c 339 client hello, adding extended_master_secret extension ssl_tls12_client.c 372 client hello, adding session ticket extension ssl_client.c 689 client hello, total extension length: 54 ssl_client.c 691 dumping 'client hello extensions' (54 bytes) ssl_client.c 691 0000: 00 36 00 0a 00 12 00 10 00 1d 00 17 00 18 00 1e .6.............. ssl_client.c 691 0010: 00 19 00 1a 00 1b 00 1c 00 0d 00 0a 00 08 06 03 ................ ssl_client.c 691 0020: 06 01 04 03 04 01 00 0b 00 02 01 00 00 16 00 00 ................ ssl_client.c 691 0030: 00 17 00 00 00 23 .....# ssl_msg.c 2783 => write handshake message ssl_msg.c 2943 => write record ssl_msg.c 3030 output record: msgtype = 22, version = [3:3], msglen = 167 ssl_msg.c 3033 dumping 'output record sent to network' (172 bytes) ssl_msg.c 3033 0000: 16 03 03 00 a7 01 00 00 a3 03 03 66 31 86 55 1d ...........f1.U. ssl_msg.c 3033 0010: 06 34 0b ef 5c 46 5e 95 8a ea bb 34 d5 7d de 77 .4..\F^....4.}.w ssl_msg.c 3033 0020: 24 bd 19 1f 7d 09 94 0c a8 01 6c 00 00 44 cc a8 $...}.....l..D.. ssl_msg.c 3033 0030: cc a9 cc aa c0 ad c0 9f 00 6b c0 0a c0 14 00 39 .........k.....9 ssl_msg.c 3033 0040: c0 af c0 a3 c0 2b c0 2f 00 9e c0 ac c0 9e c0 23 .....+./.......# ssl_msg.c 3033 0050: c0 27 00 67 c0 09 c0 13 00 33 c0 ae c0 a2 c0 9d .'.g.....3...... ssl_msg.c 3033 0060: 00 3d 00 35 c0 a1 00 9c c0 9c 00 3c 00 2f c0 a0 .=.5.......<./.. ssl_msg.c 3033 0070: 00 ff 01 00 00 36 00 0a 00 12 00 10 00 1d 00 17 .....6.......... ssl_msg.c 3033 0080: 00 18 00 1e 00 19 00 1a 00 1b 00 1c 00 0d 00 0a ................ ssl_msg.c 3033 0090: 00 08 06 03 06 01 04 03 04 01 00 0b 00 02 01 00 ................ ssl_msg.c 3033 00a0: 00 16 00 00 00 17 00 00 00 23 00 00 .........#.. ssl_msg.c 3080 <= write record ssl_msg.c 2904 <= write handshake message ssl_client.c 1012 <= write client hello ssl_msg.c 2353 => flush output ssl_msg.c 2369 message length: 172, out_left: 172 ssl_msg.c 2374 ssl->f_send() returned 172 (-0xffffff54) ssl_msg.c 2401 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_SERVER_HELLO ssl_tls12_client.c 1193 => parse server hello ssl_msg.c 4189 => read record ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 0, nb_want: 5 ssl_msg.c 2317 in_left: 0, nb_want: 5 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_msg.c 2340 <= fetch input ssl_msg.c 3812 unknown record type 176 ssl_msg.c 4220 ssl_get_next_record() returned -29184 (-0x7200) ssl_tls12_client.c 1197 mbedtls_ssl_read_record() returned -29184 (-0x7200) ssl_tls.c 4635 <= handshake ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 4622 => handshake ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_HELLO_REQUEST ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_CLIENT_HELLO ssl_client.c 919 => write client hello ssl_client.c 725 client hello, current time: 1714521687 ssl_client.c 487 dumping 'client hello, random bytes' (32 bytes) ssl_client.c 487 0000: 66 31 86 57 a5 48 94 b1 96 f5 c3 5a 51 0f bd 24 f1.W.H.....ZQ..$ ssl_client.c 487 0010: 29 f9 8c cc 59 61 ea e7 2b 4f 28 d7 13 e1 98 78 )...Ya..+O(....x ssl_client.c 512 dumping 'session id' (0 bytes) ssl_client.c 371 client hello, add ciphersuite: cca8, TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256 ssl_client.c 371 client hello, add ciphersuite: cca9, TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256 ssl_client.c 371 client hello, add ciphersuite: ccaa, TLS-DHE-RSA-WITH-CHACHA20-POLY1305-SHA256 ssl_client.c 371 client hello, add ciphersuite: c0ad, TLS-ECDHE-ECDSA-WITH-AES-256-CCM ssl_client.c 371 client hello, add ciphersuite: c09f, TLS-DHE-RSA-WITH-AES-256-CCM ssl_client.c 371 client hello, add ciphersuite: 006b, TLS-DHE-RSA-WITH-AES-256-CBC-SHA256 ssl_client.c 371 client hello, add ciphersuite: c00a, TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: c014, TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: 0039, TLS-DHE-RSA-WITH-AES-256-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: c0af, TLS-ECDHE-ECDSA-WITH-AES-256-CCM-8 ssl_client.c 371 client hello, add ciphersuite: c0a3, TLS-DHE-RSA-WITH-AES-256-CCM-8 ssl_client.c 371 client hello, add ciphersuite: c02b, TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256 ssl_client.c 371 client hello, add ciphersuite: c02f, TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256 ssl_client.c 371 client hello, add ciphersuite: 009e, TLS-DHE-RSA-WITH-AES-128-GCM-SHA256 ssl_client.c 371 client hello, add ciphersuite: c0ac, TLS-ECDHE-ECDSA-WITH-AES-128-CCM ssl_client.c 371 client hello, add ciphersuite: c09e, TLS-DHE-RSA-WITH-AES-128-CCM ssl_client.c 371 client hello, add ciphersuite: c023, TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256 ssl_client.c 371 client hello, add ciphersuite: c027, TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256 ssl_client.c 371 client hello, add ciphersuite: 0067, TLS-DHE-RSA-WITH-AES-128-CBC-SHA256 ssl_client.c 371 client hello, add ciphersuite: c009, TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: c013, TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: 0033, TLS-DHE-RSA-WITH-AES-128-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: c0ae, TLS-ECDHE-ECDSA-WITH-AES-128-CCM-8 ssl_client.c 371 client hello, add ciphersuite: c0a2, TLS-DHE-RSA-WITH-AES-128-CCM-8 ssl_client.c 371 client hello, add ciphersuite: c09d, TLS-RSA-WITH-AES-256-CCM ssl_client.c 371 client hello, add ciphersuite: 003d, TLS-RSA-WITH-AES-256-CBC-SHA256 ssl_client.c 371 client hello, add ciphersuite: 0035, TLS-RSA-WITH-AES-256-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: c0a1, TLS-RSA-WITH-AES-256-CCM-8 ssl_client.c 371 client hello, add ciphersuite: 009c, TLS-RSA-WITH-AES-128-GCM-SHA256 ssl_client.c 371 client hello, add ciphersuite: c09c, TLS-RSA-WITH-AES-128-CCM ssl_client.c 371 client hello, add ciphersuite: 003c, TLS-RSA-WITH-AES-128-CBC-SHA256 ssl_client.c 371 client hello, add ciphersuite: 002f, TLS-RSA-WITH-AES-128-CBC-SHA ssl_client.c 371 client hello, add ciphersuite: c0a0, TLS-RSA-WITH-AES-128-CCM-8 ssl_client.c 387 adding EMPTY_RENEGOTIATION_INFO_SCSV ssl_client.c 398 client hello, got 34 cipher suites ssl_client.c 230 client hello, adding supported_groups extension ssl_client.c 249 got supported group(001d) ssl_client.c 283 NamedGroup: x25519 ( 1d ) ssl_client.c 249 got supported group(0017) ssl_client.c 283 NamedGroup: secp256r1 ( 17 ) ssl_client.c 249 got supported group(0018) ssl_client.c 283 NamedGroup: secp384r1 ( 18 ) ssl_client.c 249 got supported group(001e) ssl_client.c 283 NamedGroup: x448 ( 1e ) ssl_client.c 249 got supported group(0019) ssl_client.c 283 NamedGroup: secp521r1 ( 19 ) ssl_client.c 249 got supported group(001a) ssl_client.c 283 NamedGroup: bp256r1 ( 1a ) ssl_client.c 249 got supported group(001b) ssl_client.c 283 NamedGroup: bp384r1 ( 1b ) ssl_client.c 249 got supported group(001c) ssl_client.c 283 NamedGroup: bp512r1 ( 1c ) ssl_client.c 302 dumping 'Supported groups extension' (18 bytes) ssl_client.c 302 0000: 00 10 00 1d 00 17 00 18 00 1e 00 19 00 1a 00 1b ................ ssl_client.c 302 0010: 00 1c .. ssl_tls.c 9611 adding signature_algorithms extension ssl_tls.c 9633 got signature scheme [603] ecdsa_secp521r1_sha512 ssl_tls.c 9642 sent signature scheme [603] ecdsa_secp521r1_sha512 ssl_tls.c 9633 got signature scheme [806] rsa_pss_rsae_sha512 ssl_tls.c 9633 got signature scheme [601] rsa_pkcs1_sha512 ssl_tls.c 9642 sent signature scheme [601] rsa_pkcs1_sha512 ssl_tls.c 9633 got signature scheme [403] ecdsa_secp256r1_sha256 ssl_tls.c 9642 sent signature scheme [403] ecdsa_secp256r1_sha256 ssl_tls.c 9633 got signature scheme [804] rsa_pss_rsae_sha256 ssl_tls.c 9633 got signature scheme [401] rsa_pkcs1_sha256 ssl_tls.c 9642 sent signature scheme [401] rsa_pkcs1_sha256 ssl_tls12_client.c 106 client hello, adding supported_point_formats extension ssl_tls12_client.c 307 client hello, adding encrypt_then_mac extension ssl_tls12_client.c 339 client hello, adding extended_master_secret extension ssl_tls12_client.c 372 client hello, adding session ticket extension ssl_client.c 689 client hello, total extension length: 54 ssl_client.c 691 dumping 'client hello extensions' (54 bytes) ssl_client.c 691 0000: 00 36 00 0a 00 12 00 10 00 1d 00 17 00 18 00 1e .6.............. ssl_client.c 691 0010: 00 19 00 1a 00 1b 00 1c 00 0d 00 0a 00 08 06 03 ................ ssl_client.c 691 0020: 06 01 04 03 04 01 00 0b 00 02 01 00 00 16 00 00 ................ ssl_client.c 691 0030: 00 17 00 00 00 23 .....# ssl_msg.c 2783 => write handshake message ssl_msg.c 2943 => write record ssl_msg.c 3030 output record: msgtype = 22, version = [3:3], msglen = 167 ssl_msg.c 3033 dumping 'output record sent to network' (172 bytes) ssl_msg.c 3033 0000: 16 03 03 00 a7 01 00 00 a3 03 03 66 31 86 57 a5 ...........f1.W. ssl_msg.c 3033 0010: 48 94 b1 96 f5 c3 5a 51 0f bd 24 29 f9 8c cc 59 H.....ZQ..$)...Y ssl_msg.c 3033 0020: 61 ea e7 2b 4f 28 d7 13 e1 98 78 00 00 44 cc a8 a..+O(....x..D.. ssl_msg.c 3033 0030: cc a9 cc aa c0 ad c0 9f 00 6b c0 0a c0 14 00 39 .........k.....9 ssl_msg.c 3033 0040: c0 af c0 a3 c0 2b c0 2f 00 9e c0 ac c0 9e c0 23 .....+./.......# ssl_msg.c 3033 0050: c0 27 00 67 c0 09 c0 13 00 33 c0 ae c0 a2 c0 9d .'.g.....3...... ssl_msg.c 3033 0060: 00 3d 00 35 c0 a1 00 9c c0 9c 00 3c 00 2f c0 a0 .=.5.......<./.. ssl_msg.c 3033 0070: 00 ff 01 00 00 36 00 0a 00 12 00 10 00 1d 00 17 .....6.......... ssl_msg.c 3033 0080: 00 18 00 1e 00 19 00 1a 00 1b 00 1c 00 0d 00 0a ................ ssl_msg.c 3033 0090: 00 08 06 03 06 01 04 03 04 01 00 0b 00 02 01 00 ................ ssl_msg.c 3033 00a0: 00 16 00 00 00 17 00 00 00 23 00 00 .........#.. ssl_msg.c 3080 <= write record ssl_msg.c 2904 <= write handshake message ssl_client.c 1012 <= write client hello ssl_msg.c 2353 => flush output ssl_msg.c 2369 message length: 172, out_left: 172 ssl_msg.c 2374 ssl->f_send() returned 172 (-0xffffff54) ssl_msg.c 2401 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_SERVER_HELLO ssl_tls12_client.c 1193 => parse server hello ssl_msg.c 4189 => read record ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 0, nb_want: 5 ssl_msg.c 2317 in_left: 0, nb_want: 5 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 0 (-0x0000) ssl_msg.c 4861 mbedtls_ssl_fetch_input() returned -29312 (-0x7280) ssl_msg.c 4220 ssl_get_next_record() returned -29312 (-0x7280) ssl_tls12_client.c 1197 mbedtls_ssl_read_record() returned -29312 (-0x7280) ssl_tls.c 4635 <= handshake ssl_tls.c 4622 => handshake ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_SERVER_HELLO ssl_tls12_client.c 1193 => parse server hello ssl_msg.c 4189 => read record ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 0, nb_want: 5 ssl_msg.c 2317 in_left: 0, nb_want: 5 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_msg.c 2340 <= fetch input ssl_msg.c 3855 dumping 'input record header' (5 bytes) ssl_msg.c 3855 0000: 16 03 03 00 3d ....= ssl_msg.c 3859 input record: msgtype = 22, version = [0x303], msglen = 61 ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 5, nb_want: 66 ssl_msg.c 2317 in_left: 5, nb_want: 66 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 61 (-0xffffffc3) ssl_msg.c 2340 <= fetch input ssl_msg.c 3965 dumping 'input record from network' (66 bytes) ssl_msg.c 3965 0000: 16 03 03 00 3d 02 00 00 39 03 03 c9 25 99 9a 84 ....=...9...%... ssl_msg.c 3965 0010: 14 6a d9 ff 29 d1 12 43 d7 aa 0e ca 40 f1 18 d0 .j..)..C....@... ssl_msg.c 3965 0020: 0e 19 85 97 d5 26 ab 7b 6c 3f e4 00 cc a8 00 00 .....&.{l?...... ssl_msg.c 3965 0030: 11 ff 01 00 01 00 00 0b 00 04 03 00 01 02 00 17 ................ ssl_msg.c 3965 0040: 00 00 .. ssl_msg.c 3234 handshake message: msglen = 61, type = 2, hslen = 61 ssl_msg.c 4261 <= read record ssl_tls12_client.c 1267 dumping 'server hello, version' (2 bytes) ssl_tls12_client.c 1267 0000: 03 03 .. ssl_tls12_client.c 1292 server hello, current time: 3374684570 ssl_tls12_client.c 1298 dumping 'server hello, random bytes' (32 bytes) ssl_tls12_client.c 1298 0000: c9 25 99 9a 84 14 6a d9 ff 29 d1 12 43 d7 aa 0e .%....j..)..C... ssl_tls12_client.c 1298 0010: ca 40 f1 18 d0 0e 19 85 97 d5 26 ab 7b 6c 3f e4 .@........&.{l?. ssl_tls12_client.c 1360 server hello, session id len.: 0 ssl_tls12_client.c 1361 dumping 'server hello, session id' (0 bytes) ssl_tls12_client.c 1386 no session has been resumed ssl_tls12_client.c 1388 server hello, chosen ciphersuite: cca8 ssl_tls12_client.c 1390 server hello, compress alg.: 0 ssl_tls12_client.c 1425 server hello, chosen ciphersuite: TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256 ssl_tls12_client.c 1447 server hello, total extension length: 17 ssl_tls12_client.c 1463 found renegotiation extension ssl_tls12_client.c 1543 found supported_point_formats extension ssl_tls12_client.c 841 point format selected: 0 ssl_tls12_client.c 1516 found extended_master_secret extension ssl_tls12_client.c 1659 <= parse server hello ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_SERVER_CERTIFICATE ssl_tls.c 8204 => parse certificate ssl_msg.c 4189 => read record ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 0, nb_want: 5 ssl_msg.c 2317 in_left: 0, nb_want: 5 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_msg.c 2340 <= fetch input ssl_msg.c 3855 dumping 'input record header' (5 bytes) ssl_msg.c 3855 0000: 16 03 03 06 c7 ..... ssl_msg.c 3859 input record: msgtype = 22, version = [0x303], msglen = 1735 ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 5, nb_want: 1740 ssl_msg.c 2317 in_left: 5, nb_want: 1740 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 1735 (-0xfffff939) ssl_msg.c 2340 <= fetch input ssl_msg.c 3965 dumping 'input record from network' (1740 bytes) ssl_msg.c 3965 0000: 16 03 03 06 c7 0b 00 06 c3 00 06 c0 00 03 2f 30 ............../0 ssl_msg.c 3965 0010: 82 03 2b 30 82 02 13 02 14 6d 4f 99 2e 33 c5 10 ..+0.....mO..3.. ssl_msg.c 3965 0020: 1e ea 27 57 74 8f cf 4d 01 60 54 51 76 30 0d 06 ..'Wt..M.`TQv0.. ssl_msg.c 3965 0030: 09 2a 86 48 86 f7 0d 01 01 0b 05 00 30 53 31 0b .*.H........0S1. ssl_msg.c 3965 0040: 30 09 06 03 55 04 06 13 02 55 53 31 0b 30 09 06 0...U....US1.0.. ssl_msg.c 3965 0050: 03 55 04 08 0c 02 43 41 31 12 30 10 06 03 55 04 .U....CA1.0...U. ssl_msg.c 3965 0060: 07 0c 09 53 6f 6d 65 77 68 65 72 65 31 10 30 0e ...Somewhere1.0. ssl_msg.c 3965 0070: 06 03 55 04 0a 0c 07 53 6f 6d 65 6f 6e 65 31 11 ..U....Someone1. ssl_msg.c 3965 0080: 30 0f 06 03 55 04 03 0c 08 46 6f 6f 62 61 72 43 0...U....FoobarC ssl_msg.c 3965 0090: 41 30 1e 17 0d 32 34 30 34 30 33 30 39 33 35 30 A0...24040309350 ssl_msg.c 3965 00a0: 30 5a 17 0d 32 35 30 34 30 33 30 39 33 35 30 30 0Z..250403093500 ssl_msg.c 3965 00b0: 5a 30 51 31 0b 30 09 06 03 55 04 06 13 02 55 53 Z0Q1.0...U....US ssl_msg.c 3965 00c0: 31 0b 30 09 06 03 55 04 08 0c 02 43 41 31 12 30 1.0...U....CA1.0 ssl_msg.c 3965 00d0: 10 06 03 55 04 07 0c 09 53 6f 6d 65 77 68 65 72 ...U....Somewher ssl_msg.c 3965 00e0: 65 31 10 30 0e 06 03 55 04 0a 0c 07 53 6f 6d 65 e1.0...U....Some ssl_msg.c 3965 00f0: 6f 6e 65 31 0f 30 0d 06 03 55 04 03 0c 06 46 6f one1.0...U....Fo ssl_msg.c 3965 0100: 6f 62 61 72 30 82 01 22 30 0d 06 09 2a 86 48 86 obar0.."0...*.H. ssl_msg.c 3965 0110: f7 0d 01 01 01 05 00 03 82 01 0f 00 30 82 01 0a ............0... ssl_msg.c 3965 0120: 02 82 01 01 00 c1 9f d8 d2 15 fe e5 68 e8 fe 65 ............h..e ssl_msg.c 3965 0130: 21 e4 c4 78 ea 22 da 31 4d 08 77 df 03 d5 13 03 !..x.".1M.w..... ssl_msg.c 3965 0140: ec 36 8f d1 d3 c1 5c 15 52 fd 9d c8 27 f2 ca 51 .6....\.R...'..Q ssl_msg.c 3965 0150: 79 18 22 95 d7 6b 09 72 96 79 5a d0 cd cc ac 20 y."..k.r.yZ.... ssl_msg.c 3965 0160: 2e f2 05 cb 57 57 f3 91 07 9f 3d d7 2c e7 4e 97 ....WW....=.,.N. ssl_msg.c 3965 0170: 56 31 0a 3c 04 fd 43 9d ee 9f e7 5b d8 b7 41 0e V1.<..C....[..A. ssl_msg.c 3965 0180: d8 9b 28 8b 82 33 cd ff 7d db 8c c2 3d b6 c0 ff ..(..3..}...=... ssl_msg.c 3965 0190: 48 df dd bb 9e d6 d1 84 0a d5 f5 f5 c4 88 cc 7f H............... ssl_msg.c 3965 01a0: 2b 82 67 f0 9c 47 54 27 00 6a f0 59 0a d6 0f 84 +.g..GT'.j.Y.... ssl_msg.c 3965 01b0: a9 10 8f d2 a5 d3 26 53 3c 28 57 94 01 06 8a 1d ......&S<(W..... ssl_msg.c 3965 01c0: ff 90 e2 48 25 55 7e fd 03 cc 2c 6b e4 0e 3e 09 ...H%U~...,k..>. ssl_msg.c 3965 01d0: b2 2c 97 23 32 29 b2 55 a4 f1 37 3d 1c f8 d0 a3 .,.#2).U..7=.... ssl_msg.c 3965 01e0: 4b 6d 78 db 68 2c ac 6e 6b d6 14 2e 86 e6 0f 3d Kmx.h,.nk......= ssl_msg.c 3965 01f0: d1 61 38 de ba cb bf 4f d8 d0 af 66 b2 3f 09 0e .a8....O...f.?.. ssl_msg.c 3965 0200: 51 c5 4b c6 d2 c0 90 8a db 51 98 32 bf a3 9b e9 Q.K......Q.2.... ssl_msg.c 3965 0210: 94 a2 69 9a 0a e1 a1 6e ad 63 59 92 e2 81 4a 29 ..i....n.cY...J) ssl_msg.c 3965 0220: 36 84 36 33 2b 02 03 01 00 01 30 0d 06 09 2a 86 6.63+.....0...*. ssl_msg.c 3965 0230: 48 86 f7 0d 01 01 0b 05 00 03 82 01 01 00 1d eb H............... ssl_msg.c 3965 0240: c0 c7 45 0b 99 54 89 c9 9c 6b 18 c7 22 bf d8 a1 ..E..T...k.."... ssl_msg.c 3965 0250: 30 b6 09 ca b1 8e b4 fc a1 a7 f9 27 f8 12 ff b0 0..........'.... ssl_msg.c 3965 0260: fb c8 44 b1 d8 52 40 71 05 7d 8e 1d c1 69 0f ff ..D..R@q.}...i.. ssl_msg.c 3965 0270: f4 d2 a3 8b df e1 0b f0 8c de fb 60 e1 81 87 bc ...........`.... ssl_msg.c 3965 0280: 0f 46 84 0e db 64 dd cc c0 eb 7b bd 35 ac 5d 33 .F...d....{.5.]3 ssl_msg.c 3965 0290: 9c f7 96 24 05 4d 45 27 37 6d 0c 9f 92 ea 7d fe ...$.ME'7m....}. ssl_msg.c 3965 02a0: 4a 9b c9 54 3b 91 0f 87 7c f4 46 64 b0 3d 54 c4 J..T;...|.Fd.=T. ssl_msg.c 3965 02b0: 5f 17 bd 88 a5 07 85 24 71 44 6c be 3b 3a f8 a4 _......$qDl.;:.. ssl_msg.c 3965 02c0: 7a 2b 67 5e 3d bd 5a 12 8d 2e bd 47 8d 6f 0d 02 z+g^=.Z....G.o.. ssl_msg.c 3965 02d0: 90 af fe 8b a9 ef a8 12 73 77 29 ce fe ef 79 51 ........sw)...yQ ssl_msg.c 3965 02e0: 68 6b 2f 18 fd da f8 1e 52 eb e9 eb 38 c0 ee ee hk/.....R...8... ssl_msg.c 3965 02f0: 45 de 8f 5f 3f c4 d8 9e c4 12 87 83 5c 48 0b c9 E.._?.......\H.. ssl_msg.c 3965 0300: 5a 28 6a ec e4 28 f1 07 5b 27 7d 75 d5 2b c2 dd Z(j..(..['}u.+.. ssl_msg.c 3965 0310: ff 88 08 e3 89 14 36 6d 8b ce e3 27 d7 ef 90 bd ......6m...'.... ssl_msg.c 3965 0320: 4e da 78 f6 bf 99 4d f7 95 bf d9 d5 e8 52 f1 c8 N.x...M......R.. ssl_msg.c 3965 0330: df 5c e1 c3 fd 8e 10 0f ae cf ef bb 94 2f 00 03 .\.........../.. ssl_msg.c 3965 0340: 8b 30 82 03 87 30 82 02 6f a0 03 02 01 02 02 14 .0...0..o....... ssl_msg.c 3965 0350: 22 df a0 f5 03 ec 52 a6 04 2e 69 b4 86 56 5f 5c ".....R...i..V_\ ssl_msg.c 3965 0360: 29 ec 05 e6 30 0d 06 09 2a 86 48 86 f7 0d 01 01 )...0...*.H..... ssl_msg.c 3965 0370: 0b 05 00 30 53 31 0b 30 09 06 03 55 04 06 13 02 ...0S1.0...U.... ssl_msg.c 3965 0380: 55 53 31 0b 30 09 06 03 55 04 08 0c 02 43 41 31 US1.0...U....CA1 ssl_msg.c 3965 0390: 12 30 10 06 03 55 04 07 0c 09 53 6f 6d 65 77 68 .0...U....Somewh ssl_msg.c 3965 03a0: 65 72 65 31 10 30 0e 06 03 55 04 0a 0c 07 53 6f ere1.0...U....So ssl_msg.c 3965 03b0: 6d 65 6f 6e 65 31 11 30 0f 06 03 55 04 03 0c 08 meone1.0...U.... ssl_msg.c 3965 03c0: 46 6f 6f 62 61 72 43 41 30 1e 17 0d 32 34 30 34 FoobarCA0...2404 ssl_msg.c 3965 03d0: 30 33 30 39 33 33 34 30 5a 17 0d 32 35 30 34 30 03093340Z..25040 ssl_msg.c 3965 03e0: 33 30 39 33 33 34 30 5a 30 53 31 0b 30 09 06 03 3093340Z0S1.0... ssl_msg.c 3965 03f0: 55 04 06 13 02 55 53 31 0b 30 09 06 03 55 04 08 U....US1.0...U.. ssl_msg.c 3965 0400: 0c 02 43 41 31 12 30 10 06 03 55 04 07 0c 09 53 ..CA1.0...U....S ssl_msg.c 3965 0410: 6f 6d 65 77 68 65 72 65 31 10 30 0e 06 03 55 04 omewhere1.0...U. ssl_msg.c 3965 0420: 0a 0c 07 53 6f 6d 65 6f 6e 65 31 11 30 0f 06 03 ...Someone1.0... ssl_msg.c 3965 0430: 55 04 03 0c 08 46 6f 6f 62 61 72 43 41 30 82 01 U....FoobarCA0.. ssl_msg.c 3965 0440: 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 "0...*.H........ ssl_msg.c 3965 0450: 03 82 01 0f 00 30 82 01 0a 02 82 01 01 00 c7 25 .....0.........% ssl_msg.c 3965 0460: 6d c2 a1 b4 55 87 c1 90 64 49 5f d0 b4 c3 4a 07 m...U...dI_...J. ssl_msg.c 3965 0470: b8 40 d9 ff 10 5b ea 01 fa a2 d7 06 97 af b2 1a .@...[.......... ssl_msg.c 3965 0480: 72 0f 81 14 10 18 b2 17 dc f3 70 72 18 90 00 87 r.........pr.... ssl_msg.c 3965 0490: 0c 04 bb fa 50 8c ee d6 f0 83 1e ea 97 54 cb 37 ....P........T.7 ssl_msg.c 3965 04a0: 1f 5e b8 a5 fc b8 90 5d 88 2a b4 7e a8 5f 9c dc .^.....].*.~._.. ssl_msg.c 3965 04b0: b7 e5 3c 5b c3 d0 21 0e ed 81 16 a0 81 54 42 17 ..<[..!......TB. ssl_msg.c 3965 04c0: 02 bf 79 3d b2 11 dc 3d 35 e1 36 a1 c4 55 0d 8f ..y=...=5.6..U.. ssl_msg.c 3965 04d0: c5 31 87 7c be 02 20 6e de 3e aa c5 e5 25 03 37 .1.|.. n.>...%.7 ssl_msg.c 3965 04e0: 13 c7 17 18 36 5f 80 bd d4 d7 d3 f7 60 4c 0b 04 ....6_......`L.. ssl_msg.c 3965 04f0: 33 aa a6 c9 49 fa df b4 7c 13 7d 37 67 a7 8c b7 3...I...|.}7g... ssl_msg.c 3965 0500: c4 12 45 8a 88 80 f9 80 8f ab df f8 3c 78 e6 2c ..E.........<x., ssl_msg.c 3965 0510: e1 03 2c 7e de 8f af ad 75 ad d5 31 3d af 25 8e ..,~....u..1=.%. ssl_msg.c 3965 0520: ae 2e 61 c9 33 eb e2 0d 31 74 06 f8 f5 06 8d b0 ..a.3...1t...... ssl_msg.c 3965 0530: ac c4 f5 5f 7b c8 5e 4c 7f ed 26 a4 7e c6 d4 23 ..._{.^L..&.~..# ssl_msg.c 3965 0540: 2c 99 d3 b2 a8 a0 68 c0 f9 5d be f8 ef 2c f2 6f ,.....h..]...,.o ssl_msg.c 3965 0550: 8e 21 a6 06 1a ca 81 ef ef 95 5e 29 9d db 02 03 .!........^).... ssl_msg.c 3965 0560: 01 00 01 a3 53 30 51 30 1d 06 03 55 1d 0e 04 16 ....S0Q0...U.... ssl_msg.c 3965 0570: 04 14 94 e0 bc ab b9 f5 8a 65 8a 45 64 d9 83 2e .........e.Ed... ssl_msg.c 3965 0580: 41 ec b0 14 8d 87 30 1f 06 03 55 1d 23 04 18 30 A.....0...U.#..0 ssl_msg.c 3965 0590: 16 80 14 94 e0 bc ab b9 f5 8a 65 8a 45 64 d9 83 ..........e.Ed.. ssl_msg.c 3965 05a0: 2e 41 ec b0 14 8d 87 30 0f 06 03 55 1d 13 01 01 .A.....0...U.... ssl_msg.c 3965 05b0: ff 04 05 30 03 01 01 ff 30 0d 06 09 2a 86 48 86 ...0....0...*.H. ssl_msg.c 3965 05c0: f7 0d 01 01 0b 05 00 03 82 01 01 00 ae 3d e2 42 .............=.B ssl_msg.c 3965 05d0: 91 fe d5 70 a5 28 44 4d 0c 66 78 fc cd 07 89 24 ...p.(DM.fx....$ ssl_msg.c 3965 05e0: 1e 2f a7 55 08 c0 69 9f 2a 37 90 bf 93 da 5e 6a ./.U..i.*7....^j ssl_msg.c 3965 05f0: 75 5e 3f 53 29 e2 13 9c 3a 3e 6a 0a 99 ca 09 51 u^?S)...:>j....Q ssl_msg.c 3965 0600: 91 2a 23 d0 ad df 36 cc e2 e0 e6 0d cb 00 33 57 .*#...6.......3W ssl_msg.c 3965 0610: db b0 a5 70 98 e9 60 1b 91 9e ec c7 64 ad 14 79 ...p..`.....d..y ssl_msg.c 3965 0620: 0e 08 22 ef a8 0e 1a 71 a0 3a 17 04 9f 0c a8 12 .."....q.:...... ssl_msg.c 3965 0630: 26 55 0d 09 09 77 4e 9e 2f cf 1c 34 f8 e8 40 19 &U...wN./..4..@. ssl_msg.c 3965 0640: 19 c2 9d 31 2d c2 a0 a1 fa bd 9b 49 31 c9 dd b9 ...1-......I1... ssl_msg.c 3965 0650: 87 a2 bc 7e 60 e1 b8 88 57 84 d6 11 08 b2 33 94 ...~`...W.....3. ssl_msg.c 3965 0660: bd 19 77 78 df e1 5f e3 c9 aa 05 ad df f7 ac 0f ..wx.._......... ssl_msg.c 3965 0670: 48 06 83 43 51 1d 0c f8 62 c0 4b 78 a1 ff 5e 9a H..CQ...b.Kx..^. ssl_msg.c 3965 0680: f1 e5 a7 bb 85 8f ee b8 3a e0 17 69 5b 0b 49 19 ........:..i[.I. ssl_msg.c 3965 0690: 36 e0 ee 12 0b 63 99 c0 26 71 d7 22 20 9e 30 a1 6....c..&q." .0. ssl_msg.c 3965 06a0: 93 75 69 71 32 65 e6 c4 3f 31 cd 87 f3 b0 0c b0 .uiq2e..?1...... ssl_msg.c 3965 06b0: 5b 05 4d 1c ce a1 45 c2 0b 92 e0 8c 72 cc 99 5d [.M...E.....r..] ssl_msg.c 3965 06c0: 44 27 2b 6b 1e cf 62 03 b4 9c e6 42 D'+k..b....B ssl_msg.c 3234 handshake message: msglen = 1735, type = 11, hslen = 1735 ssl_msg.c 4261 <= read record ssl_tls.c 7887 peer certificate #1: ssl_tls.c 7887 cert. version : 1 ssl_tls.c 7887 serial number : 6D:4F:99:2E:33:C5:10:1E:EA:27:57:74:8F:CF:4D:01:60:54:51:76 ssl_tls.c 7887 issuer name : C=US, ST=CA, L=Somewhere, O=Someone, CN=FoobarCA ssl_tls.c 7887 subject name : C=US, ST=CA, L=Somewhere, O=Someone, CN=Foobar ssl_tls.c 7887 issued on : 2024-04-03 09:35:00 ssl_tls.c 7887 expires on : 2025-04-03 09:35:00 ssl_tls.c 7887 signed using : RSA with SHA-256 ssl_tls.c 7887 RSA key size : 2048 bits ssl_tls.c 7887 value of 'crt->rsa.N' (2048 bits) is: ssl_tls.c 7887 c1 9f d8 d2 15 fe e5 68 e8 fe 65 21 e4 c4 78 ea ssl_tls.c 7887 22 da 31 4d 08 77 df 03 d5 13 03 ec 36 8f d1 d3 ssl_tls.c 7887 c1 5c 15 52 fd 9d c8 27 f2 ca 51 79 18 22 95 d7 ssl_tls.c 7887 6b 09 72 96 79 5a d0 cd cc ac 20 2e f2 05 cb 57 ssl_tls.c 7887 57 f3 91 07 9f 3d d7 2c e7 4e 97 56 31 0a 3c 04 ssl_tls.c 7887 fd 43 9d ee 9f e7 5b d8 b7 41 0e d8 9b 28 8b 82 ssl_tls.c 7887 33 cd ff 7d db 8c c2 3d b6 c0 ff 48 df dd bb 9e ssl_tls.c 7887 d6 d1 84 0a d5 f5 f5 c4 88 cc 7f 2b 82 67 f0 9c ssl_tls.c 7887 47 54 27 00 6a f0 59 0a d6 0f 84 a9 10 8f d2 a5 ssl_tls.c 7887 d3 26 53 3c 28 57 94 01 06 8a 1d ff 90 e2 48 25 ssl_tls.c 7887 55 7e fd 03 cc 2c 6b e4 0e 3e 09 b2 2c 97 23 32 ssl_tls.c 7887 29 b2 55 a4 f1 37 3d 1c f8 d0 a3 4b 6d 78 db 68 ssl_tls.c 7887 2c ac 6e 6b d6 14 2e 86 e6 0f 3d d1 61 38 de ba ssl_tls.c 7887 cb bf 4f d8 d0 af 66 b2 3f 09 0e 51 c5 4b c6 d2 ssl_tls.c 7887 c0 90 8a db 51 98 32 bf a3 9b e9 94 a2 69 9a 0a ssl_tls.c 7887 e1 a1 6e ad 63 59 92 e2 81 4a 29 36 84 36 33 2b ssl_tls.c 7887 value of 'crt->rsa.E' (17 bits) is: ssl_tls.c 7887 01 00 01 ssl_tls.c 7887 peer certificate #2: ssl_tls.c 7887 cert. version : 3 ssl_tls.c 7887 serial number : 22:DF:A0:F5:03:EC:52:A6:04:2E:69:B4:86:56:5F:5C:29:EC:05:E6 ssl_tls.c 7887 issuer name : C=US, ST=CA, L=Somewhere, O=Someone, CN=FoobarCA ssl_tls.c 7887 subject name : C=US, ST=CA, L=Somewhere, O=Someone, CN=FoobarCA ssl_tls.c 7887 issued on : 2024-04-03 09:33:40 ssl_tls.c 7887 expires on : 2025-04-03 09:33:40 ssl_tls.c 7887 signed using : RSA with SHA-256 ssl_tls.c 7887 RSA key size : 2048 bits ssl_tls.c 7887 basic constraints : CA=true ssl_tls.c 7887 value of 'crt->rsa.N' (2048 bits) is: ssl_tls.c 7887 c7 25 6d c2 a1 b4 55 87 c1 90 64 49 5f d0 b4 c3 ssl_tls.c 7887 4a 07 b8 40 d9 ff 10 5b ea 01 fa a2 d7 06 97 af ssl_tls.c 7887 b2 1a 72 0f 81 14 10 18 b2 17 dc f3 70 72 18 90 ssl_tls.c 7887 00 87 0c 04 bb fa 50 8c ee d6 f0 83 1e ea 97 54 ssl_tls.c 7887 cb 37 1f 5e b8 a5 fc b8 90 5d 88 2a b4 7e a8 5f ssl_tls.c 7887 9c dc b7 e5 3c 5b c3 d0 21 0e ed 81 16 a0 81 54 ssl_tls.c 7887 42 17 02 bf 79 3d b2 11 dc 3d 35 e1 36 a1 c4 55 ssl_tls.c 7887 0d 8f c5 31 87 7c be 02 20 6e de 3e aa c5 e5 25 ssl_tls.c 7887 03 37 13 c7 17 18 36 5f 80 bd d4 d7 d3 f7 60 4c ssl_tls.c 7887 0b 04 33 aa a6 c9 49 fa df b4 7c 13 7d 37 67 a7 ssl_tls.c 7887 8c b7 c4 12 45 8a 88 80 f9 80 8f ab df f8 3c 78 ssl_tls.c 7887 e6 2c e1 03 2c 7e de 8f af ad 75 ad d5 31 3d af ssl_tls.c 7887 25 8e ae 2e 61 c9 33 eb e2 0d 31 74 06 f8 f5 06 ssl_tls.c 7887 8d b0 ac c4 f5 5f 7b c8 5e 4c 7f ed 26 a4 7e c6 ssl_tls.c 7887 d4 23 2c 99 d3 b2 a8 a0 68 c0 f9 5d be f8 ef 2c ssl_tls.c 7887 f2 6f 8e 21 a6 06 1a ca 81 ef ef 95 5e 29 9d db ssl_tls.c 7887 value of 'crt->rsa.E' (17 bits) is: ssl_tls.c 7887 01 00 01 ssl_tls.c 7971 Use configuration-specific verification callback ssl_tls.c 8131 Certificate verification flags clear ssl_tls.c 8317 <= parse certificate ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_SERVER_KEY_EXCHANGE ssl_tls12_client.c 2087 => parse server key exchange ssl_msg.c 4189 => read record ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 0, nb_want: 5 ssl_msg.c 2317 in_left: 0, nb_want: 5 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_msg.c 2340 <= fetch input ssl_msg.c 3855 dumping 'input record header' (5 bytes) ssl_msg.c 3855 0000: 16 03 03 01 2c ...., ssl_msg.c 3859 input record: msgtype = 22, version = [0x303], msglen = 300 ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 5, nb_want: 305 ssl_msg.c 2317 in_left: 5, nb_want: 305 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 300 (-0xfffffed4) ssl_msg.c 2340 <= fetch input ssl_msg.c 3965 dumping 'input record from network' (305 bytes) ssl_msg.c 3965 0000: 16 03 03 01 2c 0c 00 01 28 03 00 1d 20 53 6a e9 ....,...(... Sj. ssl_msg.c 3965 0010: ce 2a e4 fa 6e 56 44 c3 6d d2 f0 e8 76 83 a2 a3 .*..nVD.m...v... ssl_msg.c 3965 0020: c4 b7 90 5b f4 da f8 13 dd 93 4f f0 4e 06 01 01 ...[......O.N... ssl_msg.c 3965 0030: 00 51 3b 75 f1 c2 d9 65 c2 e4 1d c6 8b 32 45 63 .Q;u...e.....2Ec ssl_msg.c 3965 0040: 36 d9 5b 0e 11 fb 17 46 25 d3 2d 1d 26 fe 4c d9 6.[....F%.-.&.L. ssl_msg.c 3965 0050: 32 69 14 b0 4a 6e ff 40 08 30 0f 15 06 87 a5 98 2i..Jn.@.0...... ssl_msg.c 3965 0060: aa 12 19 e9 2b c4 31 dc 67 4d 93 d7 0f 1c b7 4f ....+.1.gM.....O ssl_msg.c 3965 0070: 69 e6 67 3a d3 ca 65 81 6f 56 82 aa 2b 97 18 7b i.g:..e.oV..+..{ ssl_msg.c 3965 0080: 14 f8 0f 4d eb c5 ab d4 79 52 6d db c3 62 de da ...M....yRm..b.. ssl_msg.c 3965 0090: f9 24 66 3c 70 1a 51 f1 7c 03 de 53 8e d4 52 8c .$f<p.Q.|..S..R. ssl_msg.c 3965 00a0: 45 b0 2e 96 05 3d 09 0e 93 16 bc 94 61 f6 bd 7e E....=......a..~ ssl_msg.c 3965 00b0: 7b 54 bc 33 2e 54 cc 12 cb 69 cb 77 38 39 1d 39 {T.3.T...i.w89.9 ssl_msg.c 3965 00c0: 0f 70 cf 18 5b c0 f5 6d 98 ef 8a 1c 76 15 8c 99 .p..[..m....v... ssl_msg.c 3965 00d0: 41 f7 43 40 41 31 1b e9 5f c0 dc b9 71 f7 16 3c A.C@A1.._...q..< ssl_msg.c 3965 00e0: 4b ac d6 8b 52 4f 52 af e3 b5 a7 73 7d 94 51 f9 K...ROR....s}.Q. ssl_msg.c 3965 00f0: 40 1f 4a f6 8a 95 7b 1b 16 51 bc 31 fd 08 1c cf @.J...{..Q.1.... ssl_msg.c 3965 0100: 18 32 73 c2 e2 62 15 d9 dd 81 c4 2e 7b 96 64 f2 .2s..b......{.d. ssl_msg.c 3965 0110: cb a0 9e c2 f9 32 bb ff 59 ea 6e 8b f7 87 81 2e .....2..Y.n..... ssl_msg.c 3965 0120: f3 02 e0 d3 3d a0 49 10 28 df 42 8a de 8f 19 5c ....=.I.(.B....\ ssl_msg.c 3965 0130: 3e > ssl_msg.c 3234 handshake message: msglen = 300, type = 12, hslen = 300 ssl_msg.c 4261 <= read record ssl_tls12_client.c 2174 dumping 'server key exchange' (296 bytes) ssl_tls12_client.c 2174 0000: 03 00 1d 20 53 6a e9 ce 2a e4 fa 6e 56 44 c3 6d ... Sj..*..nVD.m ssl_tls12_client.c 2174 0010: d2 f0 e8 76 83 a2 a3 c4 b7 90 5b f4 da f8 13 dd ...v......[..... ssl_tls12_client.c 2174 0020: 93 4f f0 4e 06 01 01 00 51 3b 75 f1 c2 d9 65 c2 .O.N....Q;u...e. ssl_tls12_client.c 2174 0030: e4 1d c6 8b 32 45 63 36 d9 5b 0e 11 fb 17 46 25 ....2Ec6.[....F% ssl_tls12_client.c 2174 0040: d3 2d 1d 26 fe 4c d9 32 69 14 b0 4a 6e ff 40 08 .-.&.L.2i..Jn.@. ssl_tls12_client.c 2174 0050: 30 0f 15 06 87 a5 98 aa 12 19 e9 2b c4 31 dc 67 0..........+.1.g ssl_tls12_client.c 2174 0060: 4d 93 d7 0f 1c b7 4f 69 e6 67 3a d3 ca 65 81 6f M.....Oi.g:..e.o ssl_tls12_client.c 2174 0070: 56 82 aa 2b 97 18 7b 14 f8 0f 4d eb c5 ab d4 79 V..+..{...M....y ssl_tls12_client.c 2174 0080: 52 6d db c3 62 de da f9 24 66 3c 70 1a 51 f1 7c Rm..b...$f<p.Q.| ssl_tls12_client.c 2174 0090: 03 de 53 8e d4 52 8c 45 b0 2e 96 05 3d 09 0e 93 ..S..R.E....=... ssl_tls12_client.c 2174 00a0: 16 bc 94 61 f6 bd 7e 7b 54 bc 33 2e 54 cc 12 cb ...a..~{T.3.T... ssl_tls12_client.c 2174 00b0: 69 cb 77 38 39 1d 39 0f 70 cf 18 5b c0 f5 6d 98 i.w89.9.p..[..m. ssl_tls12_client.c 2174 00c0: ef 8a 1c 76 15 8c 99 41 f7 43 40 41 31 1b e9 5f ...v...A.C@A1.._ ssl_tls12_client.c 2174 00d0: c0 dc b9 71 f7 16 3c 4b ac d6 8b 52 4f 52 af e3 ...q..<K...ROR.. ssl_tls12_client.c 2174 00e0: b5 a7 73 7d 94 51 f9 40 1f 4a f6 8a 95 7b 1b 16 ..s}.Q.@.J...{.. ssl_tls12_client.c 2174 00f0: 51 bc 31 fd 08 1c cf 18 32 73 c2 e2 62 15 d9 dd Q.1.....2s..b... ssl_tls12_client.c 2174 0100: 81 c4 2e 7b 96 64 f2 cb a0 9e c2 f9 32 bb ff 59 ...{.d......2..Y ssl_tls12_client.c 2174 0110: ea 6e 8b f7 87 81 2e f3 02 e0 d3 3d a0 49 10 28 .n.........=.I.( ssl_tls12_client.c 2174 0120: df 42 8a de 8f 19 5c 3e .B....\> ssl_tls12_client.c 1804 ECDH curve: x25519 ssl_tls12_client.c 1811 value of 'ECDH: Qp(X)' (255 bits) is: ssl_tls12_client.c 1811 4e f0 4f 93 dd 13 f8 da f4 5b 90 b7 c4 a3 a2 83 ssl_tls12_client.c 1811 76 e8 f0 d2 6d c3 44 56 6e fa e4 2a ce e9 6a 53 ssl_tls12_client.c 1811 value of 'ECDH: Qp(Y)' (0 bits) is: ssl_tls12_client.c 1811 00 ssl_tls12_client.c 2369 dumping 'signature' (256 bytes) ssl_tls12_client.c 2369 0000: 51 3b 75 f1 c2 d9 65 c2 e4 1d c6 8b 32 45 63 36 Q;u...e.....2Ec6 ssl_tls12_client.c 2369 0010: d9 5b 0e 11 fb 17 46 25 d3 2d 1d 26 fe 4c d9 32 .[....F%.-.&.L.2 ssl_tls12_client.c 2369 0020: 69 14 b0 4a 6e ff 40 08 30 0f 15 06 87 a5 98 aa i..Jn.@.0....... ssl_tls12_client.c 2369 0030: 12 19 e9 2b c4 31 dc 67 4d 93 d7 0f 1c b7 4f 69 ...+.1.gM.....Oi ssl_tls12_client.c 2369 0040: e6 67 3a d3 ca 65 81 6f 56 82 aa 2b 97 18 7b 14 .g:..e.oV..+..{. ssl_tls12_client.c 2369 0050: f8 0f 4d eb c5 ab d4 79 52 6d db c3 62 de da f9 ..M....yRm..b... ssl_tls12_client.c 2369 0060: 24 66 3c 70 1a 51 f1 7c 03 de 53 8e d4 52 8c 45 $f<p.Q.|..S..R.E ssl_tls12_client.c 2369 0070: b0 2e 96 05 3d 09 0e 93 16 bc 94 61 f6 bd 7e 7b ....=......a..~{ ssl_tls12_client.c 2369 0080: 54 bc 33 2e 54 cc 12 cb 69 cb 77 38 39 1d 39 0f T.3.T...i.w89.9. ssl_tls12_client.c 2369 0090: 70 cf 18 5b c0 f5 6d 98 ef 8a 1c 76 15 8c 99 41 p..[..m....v...A ssl_tls12_client.c 2369 00a0: f7 43 40 41 31 1b e9 5f c0 dc b9 71 f7 16 3c 4b .C@A1.._...q..<K ssl_tls12_client.c 2369 00b0: ac d6 8b 52 4f 52 af e3 b5 a7 73 7d 94 51 f9 40 ...ROR....s}.Q.@ ssl_tls12_client.c 2369 00c0: 1f 4a f6 8a 95 7b 1b 16 51 bc 31 fd 08 1c cf 18 .J...{..Q.1..... ssl_tls12_client.c 2369 00d0: 32 73 c2 e2 62 15 d9 dd 81 c4 2e 7b 96 64 f2 cb 2s..b......{.d.. ssl_tls12_client.c 2369 00e0: a0 9e c2 f9 32 bb ff 59 ea 6e 8b f7 87 81 2e f3 ....2..Y.n...... ssl_tls12_client.c 2369 00f0: 02 e0 d3 3d a0 49 10 28 df 42 8a de 8f 19 5c 3e ...=.I.(.B....\> ssl_tls.c 9411 Perform mbedtls-based computation of digest of ServerKeyExchange ssl_tls12_client.c 2386 dumping 'parameters hash' (64 bytes) ssl_tls12_client.c 2386 0000: a6 c8 2d 2a ab 3c d1 9d 86 bb 5a 08 3c 57 0c 1d ..-*.<....Z.<W.. ssl_tls12_client.c 2386 0010: 67 37 f6 ac b3 df b2 ce e2 db e7 4c 4b 36 8c 96 g7.........LK6.. ssl_tls12_client.c 2386 0020: 98 11 99 d3 6a 3f 63 c0 38 23 ba 56 86 55 ff a8 ....j?c.8#.V.U.. ssl_tls12_client.c 2386 0030: 45 2e 3a 7b 7a b7 73 e8 c8 c2 8f d7 0e 7f 35 e0 E.:{z.s.......5. ssl_tls12_client.c 2457 <= parse server key exchange ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_CERTIFICATE_REQUEST ssl_tls12_client.c 2496 => parse certificate request ssl_msg.c 4189 => read record ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 0, nb_want: 5 ssl_msg.c 2317 in_left: 0, nb_want: 5 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_msg.c 2340 <= fetch input ssl_msg.c 3855 dumping 'input record header' (5 bytes) ssl_msg.c 3855 0000: 16 03 03 00 8b ..... ssl_msg.c 3859 input record: msgtype = 22, version = [0x303], msglen = 139 ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 5, nb_want: 144 ssl_msg.c 2317 in_left: 5, nb_want: 144 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 139 (-0xffffff75) ssl_msg.c 2340 <= fetch input ssl_msg.c 3965 dumping 'input record from network' (144 bytes) ssl_msg.c 3965 0000: 16 03 03 00 8b 0d 00 00 87 03 01 02 40 00 28 04 ............@.(. ssl_msg.c 3965 0010: 03 05 03 06 03 08 07 08 08 08 09 08 0a 08 0b 08 ................ ssl_msg.c 3965 0020: 04 08 05 08 06 04 01 05 01 06 01 03 03 03 01 03 ................ ssl_msg.c 3965 0030: 02 04 02 05 02 06 02 00 57 00 55 30 53 31 0b 30 ........W.U0S1.0 ssl_msg.c 3965 0040: 09 06 03 55 04 06 13 02 55 53 31 0b 30 09 06 03 ...U....US1.0... ssl_msg.c 3965 0050: 55 04 08 0c 02 43 41 31 12 30 10 06 03 55 04 07 U....CA1.0...U.. ssl_msg.c 3965 0060: 0c 09 53 6f 6d 65 77 68 65 72 65 31 10 30 0e 06 ..Somewhere1.0.. ssl_msg.c 3965 0070: 03 55 04 0a 0c 07 53 6f 6d 65 6f 6e 65 31 11 30 .U....Someone1.0 ssl_msg.c 3965 0080: 0f 06 03 55 04 03 0c 08 46 6f 6f 62 61 72 43 41 ...U....FoobarCA ssl_msg.c 3234 handshake message: msglen = 139, type = 13, hslen = 139 ssl_msg.c 4261 <= read record ssl_tls12_client.c 2523 got a certificate request ssl_tls12_client.c 2613 Supported Signature Algorithm found: 04 03 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 05 03 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 06 03 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 08 07 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 08 08 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 08 09 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 08 0a ssl_tls12_client.c 2613 Supported Signature Algorithm found: 08 0b ssl_tls12_client.c 2613 Supported Signature Algorithm found: 08 04 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 08 05 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 08 06 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 04 01 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 05 01 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 06 01 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 03 03 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 03 01 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 03 02 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 04 02 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 05 02 ssl_tls12_client.c 2613 Supported Signature Algorithm found: 06 02 ssl_tls12_client.c 2652 DN hint: C=US, ST=CA, L=Somewhere, O=Someone, CN=FoobarCA ssl_tls12_client.c 2658 <= parse certificate request ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_SERVER_HELLO_DONE ssl_tls12_client.c 2669 => parse server hello done ssl_msg.c 4189 => read record ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 0, nb_want: 5 ssl_msg.c 2317 in_left: 0, nb_want: 5 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_msg.c 2340 <= fetch input ssl_msg.c 3855 dumping 'input record header' (5 bytes) ssl_msg.c 3855 0000: 16 03 03 00 04 ..... ssl_msg.c 3859 input record: msgtype = 22, version = [0x303], msglen = 4 ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 5, nb_want: 9 ssl_msg.c 2317 in_left: 5, nb_want: 9 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 4 (-0xfffffffc) ssl_msg.c 2340 <= fetch input ssl_msg.c 3965 dumping 'input record from network' (9 bytes) ssl_msg.c 3965 0000: 16 03 03 00 04 0e 00 00 00 ......... ssl_msg.c 3234 handshake message: msglen = 4, type = 14, hslen = 4 ssl_msg.c 4261 <= read record ssl_tls12_client.c 2697 <= parse server hello done ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_CLIENT_CERTIFICATE ssl_tls.c 7610 => write certificate ssl_tls.c 7637 own certificate #1: ssl_tls.c 7637 cert. version : 1 ssl_tls.c 7637 serial number : 6D:4F:99:2E:33:C5:10:1E:EA:27:57:74:8F:CF:4D:01:60:54:51:77 ssl_tls.c 7637 issuer name : C=US, ST=CA, L=Somewhere, O=Someone, CN=FoobarCA ssl_tls.c 7637 subject name : C=US, ST=CA, L=Somewhere, O=Someone, CN=Foobar ssl_tls.c 7637 issued on : 2024-04-03 09:36:01 ssl_tls.c 7637 expires on : 2025-04-03 09:36:01 ssl_tls.c 7637 signed using : RSA with SHA-256 ssl_tls.c 7637 RSA key size : 2048 bits ssl_tls.c 7637 value of 'crt->rsa.N' (2048 bits) is: ssl_tls.c 7637 a8 58 0d 38 1a 61 12 1b 16 45 c5 b8 63 6e a8 91 ssl_tls.c 7637 e4 78 c4 48 e6 cc f9 04 09 33 b4 8e d3 2d e8 6d ssl_tls.c 7637 fe 93 d1 c6 d5 82 fe 9f 15 de d1 06 8f ac df 76 ssl_tls.c 7637 ef 7f 4d 8c fe 00 ed 5c fa 5e 74 84 06 c8 2d d1 ssl_tls.c 7637 d7 57 6c 9f 56 3e 5e 09 b0 4c 2d 43 0d b6 ef 26 ssl_tls.c 7637 c9 6f 6b 28 1b 74 bb 4a e8 e9 66 8c de 8f b7 fe ssl_tls.c 7637 6c cc dd 8d ea e7 77 39 9d b5 24 42 5e 4a d7 d1 ssl_tls.c 7637 4a fd f4 81 0f 98 ed 8b 37 d9 3d 5b a8 b4 5b 66 ssl_tls.c 7637 57 2c 01 c0 5c 9c 94 cd 9c 9c 23 58 77 99 7e e5 ssl_tls.c 7637 81 87 51 2c 06 ce 8b 43 bb 2f af 7a ae 49 2a 02 ssl_tls.c 7637 6a 1f dd bb 84 1f 49 bb b3 17 37 46 73 b1 33 b0 ssl_tls.c 7637 73 22 58 26 1b 97 14 9f a6 f4 1a 18 86 51 df a6 ssl_tls.c 7637 df 5a e0 78 6b 48 58 20 d7 ae 8b 6b d5 4d e4 c8 ssl_tls.c 7637 96 73 dc 03 8e 5f 99 52 10 a2 9b a2 22 79 10 e3 ssl_tls.c 7637 38 93 33 b5 46 5a f8 3d 61 9e d5 31 ae 8a 34 d3 ssl_tls.c 7637 0c 64 39 42 ab a9 44 8b bf f6 b9 fb 92 92 14 df ssl_tls.c 7637 value of 'crt->rsa.E' (17 bits) is: ssl_tls.c 7637 01 00 01 ssl_msg.c 2783 => write handshake message ssl_msg.c 2943 => write record ssl_msg.c 3030 output record: msgtype = 22, version = [3:3], msglen = 825 ssl_msg.c 3033 dumping 'output record sent to network' (830 bytes) ssl_msg.c 3033 0000: 16 03 03 03 39 0b 00 03 35 00 03 32 00 03 2f 30 ....9...5..2../0 ssl_msg.c 3033 0010: 82 03 2b 30 82 02 13 02 14 6d 4f 99 2e 33 c5 10 ..+0.....mO..3.. ssl_msg.c 3033 0020: 1e ea 27 57 74 8f cf 4d 01 60 54 51 77 30 0d 06 ..'Wt..M.`TQw0.. ssl_msg.c 3033 0030: 09 2a 86 48 86 f7 0d 01 01 0b 05 00 30 53 31 0b .*.H........0S1. ssl_msg.c 3033 0040: 30 09 06 03 55 04 06 13 02 55 53 31 0b 30 09 06 0...U....US1.0.. ssl_msg.c 3033 0050: 03 55 04 08 0c 02 43 41 31 12 30 10 06 03 55 04 .U....CA1.0...U. ssl_msg.c 3033 0060: 07 0c 09 53 6f 6d 65 77 68 65 72 65 31 10 30 0e ...Somewhere1.0. ssl_msg.c 3033 0070: 06 03 55 04 0a 0c 07 53 6f 6d 65 6f 6e 65 31 11 ..U....Someone1. ssl_msg.c 3033 0080: 30 0f 06 03 55 04 03 0c 08 46 6f 6f 62 61 72 43 0...U....FoobarC ssl_msg.c 3033 0090: 41 30 1e 17 0d 32 34 30 34 30 33 30 39 33 36 30 A0...24040309360 ssl_msg.c 3033 00a0: 31 5a 17 0d 32 35 30 34 30 33 30 39 33 36 30 31 1Z..250403093601 ssl_msg.c 3033 00b0: 5a 30 51 31 0b 30 09 06 03 55 04 06 13 02 55 53 Z0Q1.0...U....US ssl_msg.c 3033 00c0: 31 0b 30 09 06 03 55 04 08 0c 02 43 41 31 12 30 1.0...U....CA1.0 ssl_msg.c 3033 00d0: 10 06 03 55 04 07 0c 09 53 6f 6d 65 77 68 65 72 ...U....Somewher ssl_msg.c 3033 00e0: 65 31 10 30 0e 06 03 55 04 0a 0c 07 53 6f 6d 65 e1.0...U....Some ssl_msg.c 3033 00f0: 6f 6e 65 31 0f 30 0d 06 03 55 04 03 0c 06 46 6f one1.0...U....Fo ssl_msg.c 3033 0100: 6f 62 61 72 30 82 01 22 30 0d 06 09 2a 86 48 86 obar0.."0...*.H. ssl_msg.c 3033 0110: f7 0d 01 01 01 05 00 03 82 01 0f 00 30 82 01 0a ............0... ssl_msg.c 3033 0120: 02 82 01 01 00 a8 58 0d 38 1a 61 12 1b 16 45 c5 ......X.8.a...E. ssl_msg.c 3033 0130: b8 63 6e a8 91 e4 78 c4 48 e6 cc f9 04 09 33 b4 .cn...x.H.....3. ssl_msg.c 3033 0140: 8e d3 2d e8 6d fe 93 d1 c6 d5 82 fe 9f 15 de d1 ..-.m........... ssl_msg.c 3033 0150: 06 8f ac df 76 ef 7f 4d 8c fe 00 ed 5c fa 5e 74 ....v..M....\.^t ssl_msg.c 3033 0160: 84 06 c8 2d d1 d7 57 6c 9f 56 3e 5e 09 b0 4c 2d ...-..Wl.V>^..L- ssl_msg.c 3033 0170: 43 0d b6 ef 26 c9 6f 6b 28 1b 74 bb 4a e8 e9 66 C...&.ok(.t.J..f ssl_msg.c 3033 0180: 8c de 8f b7 fe 6c cc dd 8d ea e7 77 39 9d b5 24 .....l.....w9..$ ssl_msg.c 3033 0190: 42 5e 4a d7 d1 4a fd f4 81 0f 98 ed 8b 37 d9 3d B^J..J.......7.= ssl_msg.c 3033 01a0: 5b a8 b4 5b 66 57 2c 01 c0 5c 9c 94 cd 9c 9c 23 [..[fW,..\.....# ssl_msg.c 3033 01b0: 58 77 99 7e e5 81 87 51 2c 06 ce 8b 43 bb 2f af Xw.~...Q,...C./. ssl_msg.c 3033 01c0: 7a ae 49 2a 02 6a 1f dd bb 84 1f 49 bb b3 17 37 z.I*.j.....I...7 ssl_msg.c 3033 01d0: 46 73 b1 33 b0 73 22 58 26 1b 97 14 9f a6 f4 1a Fs.3.s"X&....... ssl_msg.c 3033 01e0: 18 86 51 df a6 df 5a e0 78 6b 48 58 20 d7 ae 8b ..Q...Z.xkHX ... ssl_msg.c 3033 01f0: 6b d5 4d e4 c8 96 73 dc 03 8e 5f 99 52 10 a2 9b k.M...s..._.R... ssl_msg.c 3033 0200: a2 22 79 10 e3 38 93 33 b5 46 5a f8 3d 61 9e d5 ."y..8.3.FZ.=a.. ssl_msg.c 3033 0210: 31 ae 8a 34 d3 0c 64 39 42 ab a9 44 8b bf f6 b9 1..4..d9B..D.... ssl_msg.c 3033 0220: fb 92 92 14 df 02 03 01 00 01 30 0d 06 09 2a 86 ..........0...*. ssl_msg.c 3033 0230: 48 86 f7 0d 01 01 0b 05 00 03 82 01 01 00 1f db H............... ssl_msg.c 3033 0240: c6 fe 9b 7b 85 92 a4 31 2d 4b e9 bb 7e f9 76 84 ...{...1-K..~.v. ssl_msg.c 3033 0250: 36 4e 86 d2 f1 15 c3 fb cd 1b 0e f9 0f b0 1b 8d 6N.............. ssl_msg.c 3033 0260: 53 4c ba fc 56 a7 23 ef cb 5f bc fe 09 a3 b6 c2 SL..V.#.._...... ssl_msg.c 3033 0270: 0e 36 9b aa 03 48 2b 8b fd df 77 3d ee d2 8c f8 .6...H+...w=.... ssl_msg.c 3033 0280: 8f 0e da 8c 81 47 64 6f 8b 3b 2a e2 50 00 6d a0 .....Gdo.;*.P.m. ssl_msg.c 3033 0290: 4a 9c 36 a6 37 c1 34 c6 84 cf ea 14 d1 5b cb 3c J.6.7.4......[.< ssl_msg.c 3033 02a0: df 01 1e 8c ea 21 2f 73 4d b8 e5 7c 88 bd 47 5e .....!/sM..|..G^ ssl_msg.c 3033 02b0: 46 cd 80 20 09 ca 4d f6 13 0c 20 73 44 a8 3f 00 F.. ..M... sD.?. ssl_msg.c 3033 02c0: 7d 5c 0a fb 40 38 d3 7f 3b 29 b5 28 2b 97 39 16 }\..@8..;).(+.9. ssl_msg.c 3033 02d0: 29 06 15 8a 3d 36 b0 2e 7d f3 06 0a 3c 3a 85 e3 )...=6..}...<:.. ssl_msg.c 3033 02e0: 31 06 a5 fc 62 37 8a 8c 12 c8 a1 f3 5f 02 8f 1e 1...b7......_... ssl_msg.c 3033 02f0: 0b 81 de c3 4c 2d bd b7 66 12 e4 d9 3b 29 f2 c1 ....L-..f...;).. ssl_msg.c 3033 0300: 72 c5 2e 45 a0 bb b7 ee 5b d6 0b 7c fe ea b3 a5 r..E....[..|.... ssl_msg.c 3033 0310: 6e e2 53 8b 7d 68 f7 ae 3f a5 fe f5 66 e4 a1 9f n.S.}h..?...f... ssl_msg.c 3033 0320: 2b e3 d0 a2 00 f0 59 83 1a 32 59 eb 86 e6 e5 d1 +.....Y..2Y..... ssl_msg.c 3033 0330: c1 8e 5b 01 bd 50 d4 20 96 5e fb b4 05 6d ..[..P. .^...m ssl_msg.c 2353 => flush output ssl_msg.c 2369 message length: 830, out_left: 830 ssl_msg.c 2374 ssl->f_send() returned 830 (-0xfffffcc2) ssl_msg.c 2401 <= flush output ssl_msg.c 3080 <= write record ssl_msg.c 2904 <= write handshake message ssl_tls.c 7683 <= write certificate ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_CLIENT_KEY_EXCHANGE ssl_tls12_client.c 2712 => write client key exchange ssl_tls12_client.c 2859 value of 'ECDH: Q(X)' (252 bits) is: ssl_tls12_client.c 2859 0c f5 09 54 e3 9c 8a cd 75 94 c7 a0 8a 63 c8 f2 ssl_tls12_client.c 2859 86 c4 94 9c ad e3 2d d6 0b 22 f7 16 81 6a 8c a9 ssl_tls12_client.c 2859 value of 'ECDH: Q(Y)' (0 bits) is: ssl_tls12_client.c 2859 00 ssl_tls12_client.c 2887 value of 'ECDH: z' (254 bits) is: ssl_tls12_client.c 2887 3e 62 49 d8 e2 26 45 1b a0 3d a5 06 fb d4 df f6 ssl_tls12_client.c 2887 5c ee 6d 6a d0 5c b0 0e b6 b4 3e 10 78 01 72 50 ssl_msg.c 2783 => write handshake message ssl_msg.c 2943 => write record ssl_msg.c 3030 output record: msgtype = 22, version = [3:3], msglen = 37 ssl_msg.c 3033 dumping 'output record sent to network' (42 bytes) ssl_msg.c 3033 0000: 16 03 03 00 25 10 00 00 21 20 a9 8c 6a 81 16 f7 ....%...! ..j... ssl_msg.c 3033 0010: 22 0b d6 2d e3 ad 9c 94 c4 86 f2 c8 63 8a a0 c7 "..-........c... ssl_msg.c 3033 0020: 94 75 cd 8a 9c e3 54 09 f5 0c .u....T... ssl_msg.c 2353 => flush output ssl_msg.c 2369 message length: 42, out_left: 42 ssl_msg.c 2374 ssl->f_send() returned 42 (-0xffffffd6) ssl_msg.c 2401 <= flush output ssl_msg.c 3080 <= write record ssl_msg.c 2904 <= write handshake message ssl_tls12_client.c 3207 <= write client key exchange ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_CERTIFICATE_VERIFY ssl_tls12_client.c 3255 => write certificate verify ssl_tls.c 7224 => derive keys ssl_tls.c 7348 => calc verify ssl_tls.c 7366 dumping 'calculated verify result' (32 bytes) ssl_tls.c 7366 0000: e4 75 2d 0a c7 33 ac 38 91 8d e5 1a a2 e3 e3 b7 .u-..3.8........ ssl_tls.c 7366 0010: 65 77 be 74 9e fd df e6 ae e7 43 a1 1f 8d 5c d0 ew.t......C...\. ssl_tls.c 7367 <= calc verify ssl_tls.c 7079 dumping 'session hash for extended master secret' (32 bytes) ssl_tls.c 7079 0000: e4 75 2d 0a c7 33 ac 38 91 8d e5 1a a2 e3 e3 b7 .u-..3.8........ ssl_tls.c 7079 0010: 65 77 be 74 9e fd df e6 ae e7 43 a1 1f 8d 5c d0 ew.t......C...\. ssl_tls.c 7209 dumping 'premaster secret' (32 bytes) ssl_tls.c 7209 0000: 50 72 01 78 10 3e b4 b6 0e b0 5c d0 6a 6d ee 5c Pr.x.>....\.jm.\ ssl_tls.c 7209 0010: f6 df d4 fb 06 a5 3d a0 1b 45 26 e2 d8 49 62 3e ......=..E&..Ib> ssl_tls.c 8949 ciphersuite = TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256 ssl_tls.c 8950 dumping 'master secret' (48 bytes) ssl_tls.c 8950 0000: 0e c2 39 6f e0 c1 50 42 3c 6b 7f 2f 72 e2 3d c9 ..9o..PB<k./r.=. ssl_tls.c 8950 0010: ed df c9 0d 5b c2 96 aa cb 47 e5 df 3e c5 e9 ca ....[....G..>... ssl_tls.c 8950 0020: cd c0 97 c9 bd 58 9c bf 90 cc 6c 3c b8 c6 34 50 .....X....l<..4P ssl_tls.c 8951 dumping 'random bytes' (64 bytes) ssl_tls.c 8951 0000: c9 25 99 9a 84 14 6a d9 ff 29 d1 12 43 d7 aa 0e .%....j..)..C... ssl_tls.c 8951 0010: ca 40 f1 18 d0 0e 19 85 97 d5 26 ab 7b 6c 3f e4 .@........&.{l?. ssl_tls.c 8951 0020: 66 31 86 57 a5 48 94 b1 96 f5 c3 5a 51 0f bd 24 f1.W.H.....ZQ..$ ssl_tls.c 8951 0030: 29 f9 8c cc 59 61 ea e7 2b 4f 28 d7 13 e1 98 78 )...Ya..+O(....x ssl_tls.c 8952 dumping 'key block' (256 bytes) ssl_tls.c 8952 0000: 60 ae a8 06 fd ac 00 65 f9 47 d9 c3 13 a1 87 8d `......e.G...... ssl_tls.c 8952 0010: 7e 45 bc 0b ac 57 f3 de 29 be fb b4 3e f3 ec 89 ~E...W..)...>... ssl_tls.c 8952 0020: 81 9a 32 ec 41 58 ea ae 18 9e 8b 56 71 e2 38 9a ..2.AX.....Vq.8. ssl_tls.c 8952 0030: d6 5d 60 7a 5c 98 48 bc 6a 06 06 a0 b4 9d 70 1e .]`z\.H.j.....p. ssl_tls.c 8952 0040: 16 9d a5 b1 03 85 cc d8 c7 4d 4a f3 61 6c 09 20 .........MJ.al. ssl_tls.c 8952 0050: a8 46 d2 f9 70 de 80 7a 98 f2 11 83 77 e9 fe ef .F..p..z....w... ssl_tls.c 8952 0060: c3 37 1a 5b 32 a0 6d 65 7c 89 4f c9 39 f4 6d 52 .7.[2.me|.O.9.mR ssl_tls.c 8952 0070: 54 6b e0 a7 ea 6a 89 aa b1 66 fa e8 2c 77 96 21 Tk...j...f..,w.! ssl_tls.c 8952 0080: ba b2 ec 2c 52 60 07 e3 1a 72 3b a5 a6 a5 ee b4 ...,R`...r;..... ssl_tls.c 8952 0090: 4c e5 fc 59 14 a8 08 a0 9a d3 5b 4e 97 f2 30 f1 L..Y......[N..0. ssl_tls.c 8952 00a0: ba c9 71 c0 5a 9f 15 81 08 56 b2 f4 e1 ae 46 f0 ..q.Z....V....F. ssl_tls.c 8952 00b0: cc 14 62 d4 f5 1c c2 45 00 44 30 e6 62 9a 93 c6 ..b....E.D0.b... ssl_tls.c 8952 00c0: ce 83 84 84 a9 7e e5 05 ce 8c 21 e2 01 4e 33 bb .....~....!..N3. ssl_tls.c 8952 00d0: 61 3a 0d 81 ba d5 16 97 b9 69 79 31 94 d6 23 f5 a:.......iy1..#. ssl_tls.c 8952 00e0: 71 de 2e 32 7a c8 2e c5 26 fb b3 09 13 7b 99 fd q..2z...&....{.. ssl_tls.c 8952 00f0: 4b 5b fb 25 07 39 83 77 a5 7e 11 ef 6a 13 b0 e5 K[.%.9.w.~..j... ssl_tls.c 9074 keylen: 32, minlen: 16, ivlen: 12, maclen: 0 ssl_tls.c 7275 <= derive keys ssl_tls.c 7348 => calc verify ssl_tls.c 7366 dumping 'calculated verify result' (32 bytes) ssl_tls.c 7366 0000: e4 75 2d 0a c7 33 ac 38 91 8d e5 1a a2 e3 e3 b7 .u-..3.8........ ssl_tls.c 7366 0010: 65 77 be 74 9e fd df e6 ae e7 43 a1 1f 8d 5c d0 ew.t......C...\. ssl_tls.c 7367 <= calc verify ssl_msg.c 2783 => write handshake message ssl_msg.c 2943 => write record ssl_msg.c 3030 output record: msgtype = 22, version = [3:3], msglen = 264 ssl_msg.c 3033 dumping 'output record sent to network' (269 bytes) ssl_msg.c 3033 0000: 16 03 03 01 08 0f 00 01 04 04 01 01 00 90 58 ac ..............X. ssl_msg.c 3033 0010: 69 fe 5a f1 80 9e 24 4e c6 f0 f5 d3 84 82 14 7e i.Z...$N.......~ ssl_msg.c 3033 0020: 5c 62 6a 7a 23 88 6c 1f 6f 05 82 89 6c 6c 91 e5 \bjz#.l.o...ll.. ssl_msg.c 3033 0030: 3d ce 14 6c 93 6d f9 6e 78 2f 55 38 a0 99 43 f5 =..l.m.nx/U8..C. ssl_msg.c 3033 0040: 46 0e eb 29 89 13 fc 33 4d 9f 7c a3 19 65 f3 a7 F..)...3M.|..e.. ssl_msg.c 3033 0050: 22 48 bf 40 48 5e 3a 66 d5 0e d9 78 01 08 9a ea "H.@H^:f...x.... ssl_msg.c 3033 0060: 41 37 9f 73 45 b1 5f a1 d9 aa e7 1a c3 41 92 90 A7.sE._......A.. ssl_msg.c 3033 0070: fb ce 82 a4 3d d3 f8 e3 47 ad c5 8d 2c dd e5 d3 ....=...G...,... ssl_msg.c 3033 0080: ed 1b ec 13 fa f0 c7 8a c5 6e ad 9c 2a 92 f6 93 .........n..*... ssl_msg.c 3033 0090: 3f 13 4f 61 ad 2f 1d 4d 60 23 0b 4d 17 f7 02 e9 ?.Oa./.M`#.M.... ssl_msg.c 3033 00a0: 16 9a e5 d7 cf 7e 14 da cd 73 0e 75 6d 37 56 65 .....~...s.um7Ve ssl_msg.c 3033 00b0: 29 37 7c be ab b5 de 61 aa 7c 68 3c d1 84 d0 d6 )7|....a.|h<.... ssl_msg.c 3033 00c0: 27 19 4c 24 5b 83 02 17 55 48 e5 7a c0 a1 32 c0 '.L$[...UH.z..2. ssl_msg.c 3033 00d0: c6 3b db e8 50 c1 51 5b 60 2b f9 9f ab 15 22 3e .;..P.Q[`+...."> ssl_msg.c 3033 00e0: 47 0d be e7 14 a0 97 23 0d b3 8a 95 87 b0 b4 63 G......#.......c ssl_msg.c 3033 00f0: 9d 9a 1c 85 c6 0a d7 6e d8 28 3c b3 7c 11 75 27 .......n.(<.|.u' ssl_msg.c 3033 0100: 6b ab 97 7c 43 13 79 2e 13 61 9a 2e c4 k..|C.y..a... ssl_msg.c 2353 => flush output ssl_msg.c 2369 message length: 269, out_left: 269 ssl_msg.c 2374 ssl->f_send() returned 269 (-0xfffffef3) ssl_msg.c 2401 <= flush output ssl_msg.c 3080 <= write record ssl_msg.c 2904 <= write handshake message ssl_tls12_client.c 3367 <= write certificate verify ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_CLIENT_CHANGE_CIPHER_SPEC ssl_msg.c 5189 => write change cipher spec ssl_msg.c 2783 => write handshake message ssl_msg.c 2943 => write record ssl_msg.c 3030 output record: msgtype = 20, version = [3:3], msglen = 1 ssl_msg.c 3033 dumping 'output record sent to network' (6 bytes) ssl_msg.c 3033 0000: 14 03 03 00 01 01 ...... ssl_msg.c 2353 => flush output ssl_msg.c 2369 message length: 6, out_left: 6 ssl_msg.c 2374 ssl->f_send() returned 6 (-0xfffffffa) ssl_msg.c 2401 <= flush output ssl_msg.c 3080 <= write record ssl_msg.c 2904 <= write handshake message ssl_msg.c 5202 <= write change cipher spec ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_CLIENT_FINISHED ssl_tls.c 8548 => write finished ssl_tls.c 8382 => calc finished tls ssl_tls.c 8399 dumping 'finished output' (32 bytes) ssl_tls.c 8399 0000: 86 94 2e 46 e8 0a 1a 3a 82 00 c8 b7 f5 22 12 a6 ...F...:.....".. ssl_tls.c 8399 0010: d2 6e 3e 82 28 dd 6e 19 38 ed c8 a6 2f 03 10 f7 .n>.(.n.8.../... ssl_tls.c 8409 dumping 'calc finished result' (12 bytes) ssl_tls.c 8409 0000: 1d 6b 0a 9c 0f f7 11 2e 38 f4 61 0c .k......8.a. ssl_tls.c 8413 <= calc finished ssl_tls.c 8597 switching to new transform spec for outbound data ssl_msg.c 2783 => write handshake message ssl_msg.c 2943 => write record ssl_msg.c 935 => encrypt buf ssl_msg.c 958 dumping 'before encrypt: output payload' (16 bytes) ssl_msg.c 958 0000: 14 00 00 0c 1d 6b 0a 9c 0f f7 11 2e 38 f4 61 0c .....k......8.a. ssl_msg.c 1183 dumping 'IV used (internal)' (12 bytes) ssl_msg.c 1183 0000: 16 9d a5 b1 03 85 cc d8 c7 4d 4a f3 .........MJ. ssl_msg.c 1186 dumping 'IV used (transmitted)' (0 bytes) ssl_msg.c 1188 dumping 'additional data used for AEAD' (13 bytes) ssl_msg.c 1188 0000: 00 00 00 00 00 00 00 00 16 03 03 00 10 ............. ssl_msg.c 1191 before encrypt: msglen = 16, including 0 bytes of padding ssl_msg.c 1225 dumping 'after encrypt: tag' (16 bytes) ssl_msg.c 1225 0000: 9f 23 b8 d7 cf f6 65 bf e3 75 da 74 a5 a6 8f d0 .#....e..u.t.... ssl_msg.c 1474 <= encrypt buf ssl_msg.c 3030 output record: msgtype = 22, version = [3:3], msglen = 32 ssl_msg.c 3033 dumping 'output record sent to network' (37 bytes) ssl_msg.c 3033 0000: 16 03 03 00 20 5d 68 b0 d2 b5 ac 0c 40 52 ed 95 .... ]h.....@R.. ssl_msg.c 3033 0010: 14 43 3e 6b 6d 9f 23 b8 d7 cf f6 65 bf e3 75 da .C>km.#....e..u. ssl_msg.c 3033 0020: 74 a5 a6 8f d0 t.... ssl_msg.c 2353 => flush output ssl_msg.c 2369 message length: 37, out_left: 37 ssl_msg.c 2374 ssl->f_send() returned 37 (-0xffffffdb) ssl_msg.c 2401 <= flush output ssl_msg.c 3080 <= write record ssl_msg.c 2904 <= write handshake message ssl_tls.c 8650 <= write finished ssl_msg.c 2353 => flush output ssl_msg.c 2362 <= flush output ssl_tls.c 4529 client state: MBEDTLS_SSL_SERVER_CHANGE_CIPHER_SPEC ssl_msg.c 5211 => parse change cipher spec ssl_msg.c 4189 => read record ssl_msg.c 2155 => fetch input ssl_msg.c 2297 in_left: 0, nb_want: 5 ssl_msg.c 2317 in_left: 0, nb_want: 5 ssl_msg.c 2318 ssl->f_recv(_timeout)() returned 0 (-0x0000) ssl_msg.c 4861 mbedtls_ssl_fetch_input() returned -29312 (-0x7280) ssl_msg.c 4220 ssl_get_next_record() returned -29312 (-0x7280) ssl_msg.c 5214 mbedtls_ssl_read_record() returned -29312 (-0x7280) ssl_tls.c 4635 <= handshake ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed M1 -28928 ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 1327 The SSL configuration is tls12 only. ssl_tls.c 1420 alloc(16701 bytes) failed ssl_tls.c 5539 => free ssl_tls.c 5601 <= free

1 year

1
1
0 0

Reminder: TrustedFirmware Discord Channel

by Don Harbin

Hi All, This is going out to all the primary TF maillists. It's a gentle reminder that a TF Discord channel has been created for all chat communications in the TF ecosystem. All TF participants are encouraged to join. Instructions on how to join can be found here: https://www.trustedfirmware.org/faq/ <https://www.trustedfirmware.org/faq/> [image: Screenshot 2024-04-17 at 7.08.01 AM.png] Please let me know if you have any questions, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

1 year

1
0
0 0

TLS 1.3: two question about ticket session

by Michał Antoniak

Hello, I am trying to add TLS 1.3 support to a curl project (https://github.com/MAntoniak/curl). As a result, it has two questions. The first refers to the error code MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET. This suggests an error receiving a new session ticket. I couldn't find anything else in the documentation. However, in the ssl_cllient2.c example application (line 2638), this code is used as a message to the application about a new session ticket. This makes me unsure whether it would be correct to continue receiving application data normally. The second question relates to the receipt of tickets. The curl project does not store session tickets, so it uses the MBEDTLS_SSL_SESSION_TICKETS_DISABLED flag. If this is the case, why do we nevertheless receive a new ticket from the server? Thank you for your reply. Michał Antoniak

1 year

1
0
0 0

Appending a cert to mbedtls_x509_crt

by Roman Janota

Hello, I have an implementation in OpenSSL and am trying to recreate it using MbedTLS. One of the differences in these two I have yet to overcome is the following: Is there a way to treat mbedtls_x509_crt simply as a certificate store? Say I have some PEM data, parse it into a temporary mbedtls_x509_crt and then I would like to append this certificate to said mbedtls_x509_crt certificate store. The following is stated in the docs of mbedtls_x509_crt: > struct mbedtls_x509_crt *next Next certificate in the linked list that constitutes the CA chain. NULL indicates the end of the list. Do not modify this field directly. Is there a way to achieve this if it's advised not to modify the field directly? Thank you in advance, Roman.

1 year

4
4
0 0

mbedtls_ecp_gen_key vs mbedtls_ecdsa_genkey

by Tom Work

Hey All, I am trying to generate ECDSA public-private key pair for self-signed certificate, and came across these examples In gen_key.c <https://github.com/Mbed-TLS/mbedtls/blob/bee96566dac936e7fdfa7aa18b6a1f6767…>, "mbedtls_ecp_gen_key()" is used In ecdsa.c <https://github.com/Mbed-TLS/mbedtls/blob/bee96566dac936e7fdfa7aa18b6a1f6767…>, "mbedtls_ecdsa_genkey()" is used. My questions are: - Which function should be used? (It seems mbedtls_ecdsa_genkey() is just a wrapper of mbedtls_ecp_gen_key()?) - If using mbedtls_ecdsa_genkey(), what are the steps to write the public key into PEM format? (My understanding is that I define a mbedtls_pk_context, and convert its address into mbedtls_ecdsa_context *, and pass the pointer into mbedtls_ecdsa_genkey, and then call mbedtls_ecdsa_genkey(), is this correct?) Thanks, Tom

1 year

1
0
0 0

Re: CA Unknown Certificate

by Janos Follath

Hi Satya, Is this issue related to the one described in your previous email “[mbed-tls] EAP TLS - TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Unknown CA)”? Kind regards, Janos From: Satya Prakash Prasad <satyaprakash.developer.unix(a)gmail.com> Date: Friday, 12 April 2024 at 16:27 To: Janos Follath <Janos.Follath(a)arm.com> Subject: Re: [mbed-tls] CA Unknown Certificate Hi Janos, Kindly note that I have already provided the same in my initial email. Please refer the same for your reference: Please note that we need to give CN value different for Root and Server / Client (since I am trying got mutual trusted certificate. You can also verify the same in below way: First console : # openssl s_server -cert crt1/server.crt -key crt1/server.key -WWW -port 12345 -CAfile crt1/trusted_ca.eap.pem -verify_return_err or -Verify 1 verify depth is 1, must return a certificate Using default temp DH parameters ACCEPT Second Console: #touch test.txt # openssl s_server -cert crt1/server.crt -key crt1/server.key -WWW -port 12345 -CAfile crt1/trusted_ca.eap.pem -verify_return_err or -Verify 1 verify depth is 1, must return a certificate Using default temp DH parameters ACCEPT On First Console we receive: # openssl s_server -cert crt1/server.crt -key crt1/server.key -WWW -port 12345 -CAfile crt1/trusted_ca.eap.pem -verify_return_err or -Verify 1 verify depth is 1, must return a certificate Using default temp DH parameters ACCEPT depth=1 C = US, ST = CA, L = Somewhere, O = Someone, CN = FoobarCA verify return:1 depth=0 C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar verify return:1 FILE:test.txt Root CA Key # openssl genrsa -des3 -out ca.key.pem 2048 Generating RSA private key, 2048 bit long modulus (2 primes) ..+++++ ....+++++ e is 65537 (0x010001) Enter pass phrase for ca.key.pem:^1234^ Verifying - Enter pass phrase for ca.key.pem:^1234^ Server Private Key # openssl genrsa -out server.key.pem 2048 Generating RSA private key, 2048 bit long modulus (2 primes) ........................................+++++ .................................................................................................+++++ e is 65537 (0x010001) Client Private Key # openssl genrsa -out client.key.pem 2048 Generating RSA private key, 2048 bit long modulus (2 primes) ...............................+++++ ..........................+++++ e is 65537 (0x010001) Root CA Certificate from Root CA Key # openssl req -x509 -new -nodes -key ca.key.pem -sha256 -days 365 -out ca.cert.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=FoobarCA Enter pass phrase for ca.key.pem:^1234^ Server CSR & Certificate from Server Private Key # openssl req -new -sha256 -key server.key.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar -out server.csr # openssl x509 -req -in server.csr -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -out server.cert.pem -days 365 -sha256 Signature ok subject=C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar Getting CA Private Key Enter pass phrase for ca.key.pem:^1234^ Client CSR & Certificate from Client Private Key # openssl req -new -sha256 -key client.key.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar -out client.csr # openssl x509 -req -in client.csr -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -out client.cert.pem -days 365 -sha256 Signature ok subject=C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar Getting CA Private Key Enter pass phrase for ca.key.pem:^1234^ Regards, Prakash On Fri, Apr 12, 2024 at 5:55 PM Janos Follath <Janos.Follath(a)arm.com<mailto:Janos.Follath@arm.com>> wrote: Hi Prakash, Thank you for sharing the details about how you generated the certificates. Could you please share the command line for the server and the client as well? Kind regards, Janos From: Satya Prakash Prasad via mbed-tls <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> Date: Friday, 12 April 2024 at 05:03 To: mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> Subject: [mbed-tls] CA Unknown Certificate Hi, Please note that while using MBedTLS 3.6.0, when we are trying to verify server / client connection using self-signed mutually trusted certificates we are always getting a CA Unknown Certificate error code 46 alert message. Root CA Key # openssl genrsa -des3 -out ca.key.pem 2048 Generating RSA private key, 2048 bit long modulus (2 primes) ..+++++ ....+++++ e is 65537 (0x010001) Enter pass phrase for ca.key.pem:^1234^ Verifying - Enter pass phrase for ca.key.pem:^1234^ Server Private Key # openssl genrsa -out server.key.pem 2048 Generating RSA private key, 2048 bit long modulus (2 primes) ........................................+++++ .................................................................................................+++++ e is 65537 (0x010001) Client Private Key # openssl genrsa -out client.key.pem 2048 Generating RSA private key, 2048 bit long modulus (2 primes) ...............................+++++ ..........................+++++ e is 65537 (0x010001) Root CA Certificate # openssl req -x509 -new -nodes -key ca.key.pem -sha256 -days 365 -out ca.cert.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=FoobarCA Enter pass phrase for ca.key.pem:^1234^ Server CSR & Certificate # openssl req -new -sha256 -key server.key.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar -out server.csr # openssl x509 -req -in server.csr -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -out server.cert.pem -days 365 -sha256 Signature ok subject=C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar Getting CA Private Key Enter pass phrase for ca.key.pem:^1234^ Client CSR & Certificate # openssl req -new -sha256 -key client.key.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar -out client.csr # openssl x509 -req -in client.csr -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -out client.cert.pem -days 365 -sha256 Signature ok subject=C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar Getting CA Private Key Enter pass phrase for ca.key.pem:^1234^ So we have used Root CA Certificatet as trusted certificate but during handshake steps we see client reporting "Certificate Unknown'' alert error message 46? TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Certificate Unknown) Description: Certificate Unknown (46) Can you please let us know the issue we are doing in creating the certificates or it can also be some wrong steps / configuration while compiling the 3.6.0 release? Regards, Prakash -- mbed-tls mailing list -- mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> To unsubscribe send an email to mbed-tls-leave(a)lists.trustedfirmware.org<mailto:mbed-tls-leave@lists.trustedfirmware.org> 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.

1 year

2
1
0 0

CA Unknown Certificate

by Satya Prakash Prasad

Hi, Please note that while using MBedTLS 3.6.0, when we are trying to verify server / client connection using self-signed mutually trusted certificates we are always getting a CA Unknown Certificate error code 46 alert message. Root CA Key # openssl genrsa -des3 -out ca.key.pem 2048 Generating RSA private key, 2048 bit long modulus (2 primes) ..+++++ ....+++++ e is 65537 (0x010001) Enter pass phrase for ca.key.pem:^1234^ Verifying - Enter pass phrase for ca.key.pem:^1234^ Server Private Key # openssl genrsa -out server.key.pem 2048 Generating RSA private key, 2048 bit long modulus (2 primes) ........................................+++++ .................................................................................................+++++ e is 65537 (0x010001) Client Private Key # openssl genrsa -out client.key.pem 2048 Generating RSA private key, 2048 bit long modulus (2 primes) ...............................+++++ ..........................+++++ e is 65537 (0x010001) Root CA Certificate # openssl req -x509 -new -nodes -key ca.key.pem -sha256 -days 365 -out ca.cert.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=FoobarCA Enter pass phrase for ca.key.pem:^1234^ Server CSR & Certificate # openssl req -new -sha256 -key server.key.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar -out server.csr # openssl x509 -req -in server.csr -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -out server.cert.pem -days 365 -sha256 Signature ok subject=C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar Getting CA Private Key Enter pass phrase for ca.key.pem:^1234^ Client CSR & Certificate # openssl req -new -sha256 -key client.key.pem -subj /C=US/ST=CA/L=Somewhere/O=Someone/CN=Foobar -out client.csr # openssl x509 -req -in client.csr -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -out client.cert.pem -days 365 -sha256 Signature ok subject=C = US, ST = CA, L = Somewhere, O = Someone, CN = Foobar Getting CA Private Key Enter pass phrase for ca.key.pem:^1234^ So we have used Root CA Certificatet as trusted certificate but during handshake steps we see client reporting "Certificate Unknown'' alert error message 46? TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Certificate Unknown) Description: Certificate Unknown (46) Can you please let us know the issue we are doing in creating the certificates or it can also be some wrong steps / configuration while compiling the 3.6.0 release? Regards, Prakash

1 year

1
0
0 0

Public key from certificate?

by Christian Huitema

Public key operations like "psa_verify_message" use a "key-id" argument to represent the public key. Is there a simple way to obtain or register that key-id using the "cert->pk" member of a parsed certificate? -- Christian Huitema

1 year

2
1
0 0

Use of auto-generation approach for mbedtls/mbed-crypto driver psa_crypto_driver_wrappers..h file

by Ruchika Gupta

Hi All, Apologies for the long email. I am adding all the 3 projects (TF-M, mbedTLS and Zephyr) to the mail chain because the issues I discuss below are inter-connected and affect all the three projects. From mbedtls 3.5.0 version, the mbedtls project has migrated to auto-generated psa_crypto_driver_wrappers.h file. https://github.com/Mbed-TLS/mbedtls/blob/development/docs/psa-driver-exampl… https://github.com/Mbed-TLS/mbedtls/blob/development/docs/proposed/psa-driv… On TF-M, mbed-crypto, there are 2 patches for the drivers given below which are still hardcoding their changes and not following the above approach. 1. PSA_CRYPTO_DRIVER_TFM_BUILTIN_KEY_LOADER (0001-Add-TF-M-Builtin-Key-Loader-driver-entry-points.patch) 2. PSA_CRYPTO_DRIVER_CC3XX (0005-Hardcode-CC3XX-entry-points.patch) We at NXP, have migrated our psa crypto wrappers to the above approach using auto-generation. We want to maintain same code base for mbedtls for our SDK's, TFM mbed-crypto as well as align mbedTLS fork in Zephyr. We are increasingly finding it difficult to migrate to newer versions of mbedtls because of hardcoding of above drivers. The problem is specially on the Zephyr front, where in the mbedTLS fork in zephyr these patches from tfm are applied by default. I have queries for all the 3 projects listed below : TF-M --> Can you please let us know what are the plans to migrate these 2 drivers in tfm to the auto-generation approach. If these patches can be migrated to make changes in jinja files rather than hardcoding in psa_crypto_driver_wrappers , things would be much easier to integrate. Is somebody already working on it ? Are you open to accept patches for this change ? mbedTLS --> What is the long term strategy from mbedTLS on this auto-generation ? We still have a lot of hard-coding in .jinja file rather than using drivers.json. Would mbedTLS/new PSA crypto repository start accepting patches for psa wrappers from platforms ? Can the patches which TF-M project maintains be merged in the mbedTLS ? Zephyr --> On Zephyr front, what are the plans to align to this auto-generation approach ? Regards, Ruchika

1 year

2
2
0 0

Why is mbedtls 3.x faster than 2.x?

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!

1 year

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

1 year

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

1 year

1
0
0 0