- mbed-tls - lists.trustedfirmware.org

Re: [mbed-tls] Mutual Authentication in TLS handshake - No client certificate passed

by Abhilash Iyer

Hi Gopi, Thank you very much for your feedback. I double checked all the recommended configuration that you mentioned but it did not help. I really suspect if I have hit a mbedTLS limitation here. Following our conversation, I tried connecting to the server using openSSL. Server: https://preview.auth.edgeai.azure.net/api/v1/device/auth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpreview.a…> OpenSSL commands: OpenSSL> s_client -connect preview.auth.edgeai.azure.net:443 -showcerts -debug -msg -state -tls1_2 -cert certificate1.pem -key privateKey1.pem GET /api/v1/device/auth HTTP/1.1 HOST:preview.auth.edgeai.azure.net With the above commands, I am able to send the client certificate to the server. I have attached the openSSL logs to show the flow of TLS activity. As per the logs attached, this is the flow of activity: 1. In the first TLS handshake there is no certificate request and no client certificate sent. I see ClientHello, ServerHello, ServerCertificate, ServerKeyExchange, Server Done, ClientKeyExchange, Change cipher spec, Certificate chain information and Server Cert. Till here, I do see: No client certificate CA names sent. 2. Now when I do a Get call & pass the HOST, client writes that call to the server and in turn the server returns me a "HelloRequest" which is encrypted. Now, this chain of handshake has a CertificateRequest, ClientCertificate, CertificateVerify etc. I see that 1009 bytes of data been written on the server under the name of client certificate. There is no way to see this certificate because the channel is encrypted now. 3. Lastly, we get HTTP/1.1 200 OK. Now when I do the same thing using the mbedTLS client on windows 10 PC, I see that the client gets reset during the renegotiation process. Note that the client cert was supposed to be exchanged in the renegotiation period, not the initial handshake. I have attached the logs for mbedTLS client as well and here are the commands that I use to communicate using mbedTLS client. ssl_client2.exe server_name=preview.auth.edgeai.azure.net server_port=443 debug_level=5 auth_mode=required renegotiate=1 reconnect=1 request_page=/api/v1/device/auth crt_file=certificate1.pem key_file=privateKey1.pem ca_file=server_prev1.pem I am wondering if this type of exchange of certs is not supported by mbedTLS at all. But it doesn't work with the remote server since this server looks for the client cert in the renegotiation phase to retain client certificate privacy. Can you confirm that this is a MBEDTLS limitation and have to move to a different library? Thanks, Abhilash From: Subramanian Gopi Krishnan <gopikrishnan.subramanian(a)kone.com> Sent: Sunday, June 28, 2020 8:58 PM To: Abhilash Iyer <Abhilash.Iyer(a)microsoft.com> Subject: [EXTERNAL] RE: [mbed-tls] Mutual Authentication in TLS handshake - No client certificate passed Hi Abilash, Few things to verify 1. On server side - make sure the authentication mode is set to required instead of optional. * Test with browser, does Handshake is succeeding if cancelling to select Certificate. * If the above were success, then proceed to modify auth_mode on server as below and test once again. * mbedtls_ssl_conf_authmode( &conf, MBEDTLS_SSL_VERIFY_REQUIRED ); - insisting Server to Request Certificate. 2. On client side - check does it has a valid Certificate & Key set to TLS Configuration * mbedtls_ssl_conf_own_cert( &conf, &clicert, &pkey ); Thanks, Gopi Krishnan From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org<mailto:mbed-tls-bounces@lists.trustedfirmware.org>> On Behalf Of Abhilash Iyer via mbed-tls Sent: Monday, June 22, 2020 2:00 PM To: mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> Subject: [mbed-tls] Mutual Authentication in TLS handshake - No client certificate passed This message is from an external sender. Be cautious, especially with links and attachments. Hello, I am trying to incorporate Mutual Authentication TLS in my hardware. For testing the mutual authentication in TLS, I setup a demo service which would request a client certificate in the TLS handshake. I used MS Edge, Google Chrome to test whether the service requests a client certificate during the TLS 1.2 handshake. When I ping the website, I do receive a request for a client certificate as shown in the image below. On selecting a certificate, I am able to access the website. Link to the demo service: https://serviceforsomsecurity.azurewebsites.net/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fservicefo…> [A screenshot of a cell phone Description automatically generated] The above validates that the service requires the client to provide the client certificate during the TLS handshake. Now, when I test this with the sample mbedTLS ssl_client2.c program: https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_client…<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>, the client does not send a certificate at all. The following are the steps that I carry out to test the TLS connection with my service with the sample mbedTLS ssl_client2.exe : 1. Open the mbedTLS.sln and build the ssl_client2 project. This creates a ssl_client2.exe under the Debug folder. 2. ssl_client2.exe server_name=serviceforsomsecurity.azurewebsites.net server_port=443 debug_level=3 auth_mode=required reconnect=1 crt_file=cert.pem key_file=key.pem ca_file=Digicert.cer force_version=tls1_2 The above command to test whether the client sends the client certificate during handshake. Here's the log: [A screenshot of a computer Description automatically generated] As you can see, in 3025 client receives: got no certificate request and then followed by server hello done at 3157. And then at 2080 & 2094, client skips writing certificate; during this handshake. 3. Then I tried including renegotiation flag: ssl_client2.exe server_name=serviceforsomsecurity.azurewebsites.net server_port=443 debug_level=3 auth_mode=required reconnect=1 crt_file=cert.pem key_file=key.pem ca_file=Digicert.cer force_version=tls1_2 renegotiate=1 Even in this case, the client does not get the certificate and abruptly ends during renegotiation due to timeout. I have included both the log files below for complete handshake review. [ssl_client_without_renegotiation.txt and ssl_client_with_renegotiation.txt] Can you please let me know how to debug this client certificate problem? It will be really a great help! Million thanks in advance. Regards, Abhilash

6 years, 1 month

1
0
0 0

[Mbed-tls-announce] Mbed TLS: Security Advisory and Release of Mbed TLS 2.23.0, 2.16.7 and 2.7.16

by Janos Follath via Mbed-tls-announce

An Mbed TLS Security Advisory has been issued to accompany the release of Mbed TLS versions 2.23.0, 2.16.7 and 2.7.16, which have just been released. These releases of Mbed TLS address several security issues, provide bug fixes, and bring other minor changes. Full details are available in the release notes Mbed TLS 2.23.0<https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.23.0>, Mbed TLS 2.16.7<https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.16.7>, Mbed TLS 2.7.16<https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.7.16> and in the 2020-07 security advisory<https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advi…>. We recommend all users to consider whether they are impacted, and to upgrade appropriately. -- Mbed-tls-announce mailing list Mbed-tls-announce(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls-announce

6 years, 1 month

1
0
0 0

[Mbed-tls-announce] Welcome to Mbed TLS Announce @ TrustedFirmware.org

by Janos Follath via Mbed-tls-announce

Welcome to the Mbed TLS Announcement list @ TrustedFirmware.org! This mailing list is the primary channel for announcements about upcoming Mbed TLS releases and security advisories. This mailing list includes all members of the higher traffic developer mailing list<https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls>. Therefore all announcements will also appear on the developer mailing list and there is no need to subscribe to both. Thanks and regards Janos (on behalf of the Mbed TLS maintainer 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 https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls-announce

6 years, 1 month

1
0
0 0

New TrustedFirmware.org security incident process is now live

by Dan Handley

Hi all The new TrustedFirmware.org security incident process is now live. This process is described here: https://developer.trustedfirmware.org/w/collaboration/security_center/repor… Initially the process will be used for the following projects: TF-A, TF-M, OP-TEE and Mbed TLS. The security documentation for each project will be updated soon to reflect this change. If you are part of an organization that believes it should receive security vulnerability information before it is made public then please ask your relevant colleagues to register as Trusted Stakeholders as described here: https://developer.trustedfirmware.org/w/collaboration/security_center/trust… Note we prefer individuals in each organization to coordinate their registration requests with each other and to provide us with an email alias managed by your organization instead of us managing a long list of individual addresses. Best regards Dan. (on behalf of the TrustedFirmware.org security team)

6 years, 1 month

1
0
0 0

Re: [mbed-tls] Choosing a cipher

by Gilles Peskine

The TLS protocol has many options. A TLS connection starts with a handshake whose role is mostly for the client and the server to agree on these options. The ciphersuite is one of these options. It determines which cryptographic primitives will be used for the various security properties (data confidentiality, data integrity, server authentication, etc.). A ciphersuite mismatch, or more generally a mismatch of some option of the protocol, or a certificate mismatch, would normally result in the dissatisfied party closing the connection. For a ciphersuite mismatch, the server should send an alert "handshake failure". For a certificate mismatch, there are several alerts ("bad certificate", "certificate expired", etc.). The first tool to turn to when debugging a TLS connection is Wireshark. Compare a failing connection with a successful connection with similar settings (preferably to the same server). Keep in mind that there can be many legitimate differences, so the first difference might not be the source of the problem. You can try connecting with programs/ssl/ssl_client2 from the mbedtls source tree with different sets of options. For some background on how a TLS connection should work, I suggest starting with Wikipedia, then https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work and https://tls.ulfheim.net/ (The Illustrated TLS Connection — note that while it's a very good explanation, it's for a specific choice of ciphersuite and other options). -- Gilles Peskine Mbed TLS developer On 29/06/2020 03:02, Thompson, Jeff via mbed-tls wrote: > Another baby step in discovering what's happening. The last message > from the server tells the client to change ciphersuites. I don't even > know what a ciohersuite actually is—something like RSA, AES, or > DES?—never mind how to change mine, though I have seen the list; my, > what a lot of conditionals it has. > > So, am I still dealing with a certificate issue? Where do I go from here? > > Get Outlook for Android <https://aka.ms/ghei36> > > ------------------------------------------------------------------------ > *From:* mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on > behalf of Thompson, Jeff via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> > *Sent:* Friday, June 26, 2020 12:52:27 PM > *To:* mbed-tls(a)lists.trustedfirmware.org > <mbed-tls(a)lists.trustedfirmware.org> > *Subject:* Re: [mbed-tls] Choosing a cipher > > > A little progress. I figured out where—ssl_encrypt_buf() in > ssl_tls.c—to output the name of the offending ciphersuite, which is > included in all 3 of the preconfigure Google Cloud SSL policies. > > > > So what’s going on here? Why should the mbedTLS client wait forever > for 5 bytes it will never get, stalling the connection, instead timing > out or otherwise detecting an error it could return? > > > > I’m totally at a loss for what to do with this, other than looking for > a commercially supported alternative, which I don’t think would be > received very well by my manager. > > > > *Jeff Thompson* | Senior Electrical Engineer-Firmware > +1 704 752 6513 x1394 > www.invue.com > > > > *From:* Thompson, Jeff > *Sent:* Friday, June 26, 2020 09:40 > *To:* mbed-tls(a)lists.trustedfirmware.org > *Subject:* Choosing a cipher > > > > The TLS handshake between my device and ghs.googlehosted.com gets > stalled when the server sends the device a Change Cipher Spec > message—the device waits forever, wanting 5 more bytes. From what I > Google’d, I need to change the cipher suite I’m using. How do I know > which cipher the server doesn’t like (so I can avoid that in future), > and which one I should be using—there are scores of these available in > the config file, though some of them clearly should not be used, as > they are commented that way.. > > > > *Jeff Thompson* | Senior Electrical Engineer-Firmware > +1 704 752 6513 x1394 > www.invue.com > > > >

6 years, 1 month

1
0
0 0

Re: [mbed-tls] Choosing a cipher

by Janos Follath

Hi Jeff, There is a specification document for the TLS 1.2 handshake (RFC 5246: https://tools.ietf.org/html/rfc5246) that I think might help finding out what is going on. There is a graph depicting the handshake on page 37 which I think can be particularly useful. Regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of "Thompson, Jeff via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org> Reply to: "Thompson, Jeff" <JeffThompson(a)invue.com> Date: Monday, 29 June 2020 at 02:02 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] Choosing a cipher Another baby step in discovering what's happening. The last message from the server tells the client to change ciphersuites. I don't even know what a ciohersuite actually is—something like RSA, AES, or DES?—never mind how to change mine, though I have seen the list; my, what a lot of conditionals it has. So, am I still dealing with a certificate issue? Where do I go from here? Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Thompson, Jeff via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Friday, June 26, 2020 12:52:27 PM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] Choosing a cipher A little progress. I figured out where—ssl_encrypt_buf() in ssl_tls.c—to output the name of the offending ciphersuite, which is included in all 3 of the preconfigure Google Cloud SSL policies. So what’s going on here? Why should the mbedTLS client wait forever for 5 bytes it will never get, stalling the connection, instead timing out or otherwise detecting an error it could return? I’m totally at a loss for what to do with this, other than looking for a commercially supported alternative, which I don’t think would be received very well by my manager. Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D64DFD.447A03C0] From: Thompson, Jeff Sent: Friday, June 26, 2020 09:40 To: mbed-tls(a)lists.trustedfirmware.org Subject: Choosing a cipher The TLS handshake between my device and ghs.googlehosted.com gets stalled when the server sends the device a Change Cipher Spec message—the device waits forever, wanting 5 more bytes. From what I Google’d, I need to change the cipher suite I’m using. How do I know which cipher the server doesn’t like (so I can avoid that in future), and which one I should be using—there are scores of these available in the config file, though some of them clearly should not be used, as they are commented that way.. Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D64DFD.447A03C0]

6 years, 1 month

1
0
0 0

Re: [mbed-tls] Choosing a cipher

by Thompson, Jeff

Another baby step in discovering what's happening. The last message from the server tells the client to change ciphersuites. I don't even know what a ciohersuite actually is—something like RSA, AES, or DES?—never mind how to change mine, though I have seen the list; my, what a lot of conditionals it has. So, am I still dealing with a certificate issue? Where do I go from here? Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Thompson, Jeff via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Friday, June 26, 2020 12:52:27 PM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] Choosing a cipher A little progress. I figured out where—ssl_encrypt_buf() in ssl_tls.c—to output the name of the offending ciphersuite, which is included in all 3 of the preconfigure Google Cloud SSL policies. So what’s going on here? Why should the mbedTLS client wait forever for 5 bytes it will never get, stalling the connection, instead timing out or otherwise detecting an error it could return? I’m totally at a loss for what to do with this, other than looking for a commercially supported alternative, which I don’t think would be received very well by my manager. Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D64BB6.03781220] From: Thompson, Jeff Sent: Friday, June 26, 2020 09:40 To: mbed-tls(a)lists.trustedfirmware.org Subject: Choosing a cipher The TLS handshake between my device and ghs.googlehosted.com gets stalled when the server sends the device a Change Cipher Spec message—the device waits forever, wanting 5 more bytes. From what I Google’d, I need to change the cipher suite I’m using. How do I know which cipher the server doesn’t like (so I can avoid that in future), and which one I should be using—there are scores of these available in the config file, though some of them clearly should not be used, as they are commented that way.. Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D64BB6.03781220]

6 years, 1 month

1
0
0 0

Choosing a cipher

by Thompson, Jeff

The TLS handshake between my device and ghs.googlehosted.com gets stalled when the server sends the device a Change Cipher Spec message-the device waits forever, wanting 5 more bytes. From what I Google'd, I need to change the cipher suite I'm using. How do I know which cipher the server doesn't like (so I can avoid that in future), and which one I should be using-there are scores of these available in the config file, though some of them clearly should not be used, as they are commented that way.. Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D64B9D.863E3220]

6 years, 1 month

1
1
0 0

SSL/TLS Handshake Failure

by Thompson, Jeff

Much thanks to Manuel and Gilles for helping me get this far! I'm trying to connect to endpoint hosted by Google for IoT devices. The handshake appears to progress through certificate verification and key exchange, encrypts a payload and then times out waiting for 5 expected bytes. I've attached the last part of the mbedTLS output generated with DEBUG_LEVEL 5 (the entrie thing is too big to include here). I'm sure the problem is either my code, network configuration, or somewhere else on my end. Can anyone give me a clue as to what might be wrong? The starting point for attempting the connection is https_client_tls_xchg(), found in the attached snippet from the example httpsclient.c file as I've modified it. FWIW, I'm using mbedTLS 2.13.1 running on an MIMXRT1062DVJ6A with MCUXpresso SDK 2.6.2. My HTTPS client is based on NXPs example project lwip_httpscli_mbedtls_freertos. Thanks, Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D64AE1.D6CB8F10]

6 years, 1 month

1
0
0 0

Re: [mbed-tls] Working with a PEM file

by Gilles Peskine

[I assume you meant to reply to the list.] If you don't have a filesystem, call mbedtls_x509_crt_parse instead of mbedtls_x509_crt_parse_file. To save static data size, you may want to store the data in binary form instead of base64. To do this: 1. Split the PEM file into individual certificates. 2. Convert each file to DER (you can use programs/util/pem2der, but you need to split the file first, because it only converts the first PEM chunk). 3. Convert each binary file to a C unsigned char array literal. 4. In your code, call mbedtls_x509_crt_parse_der in a loop over the array. Your code might look something like this: const uint8_t cert1_der[] = {0x30, …}; const uint8_t cert2_der[] = {0x30, …}; … const struct {const uint8_t *data; size_t size;} root_certs_der = { {cert1_der, sizeof(cert1_der)}, … }; … mbedtls_x509_crt roots; mbedtls_x509_crt_init(&roots); for (i = 0; i < sizeof(root_certs_der)/sizeof(root_certs_der[0]); i++) mbedtls_x509_crt_parse_der(&roots, root_certs_der[i].data, root_certs_der[i].size); Best regards, -- Gilles Peskine Mbed TLS developer On 23/06/2020 23:31, Thompson, Jeff wrote: > I did see that function, but it assumes a file system, doesn't it? I'm not using one, and that would be a really big change to make this late in the development cycle, if I can avoid it. I can program the PEM file into flash memory, where it can be addressed, for reading only, just like ROM. Is there a way to use it like that? > > Jeff Thompson | Senior Electrical Engineer-Firmware > +1 704 752 6513 x1394 > www.invue.com > -----Original Message----- > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of Gilles Peskine via mbed-tls > Sent: Tuesday, June 23, 2020 4:38 PM > To: mbed-tls(a)lists.trustedfirmware.org > Subject: Re: [mbed-tls] Working with a PEM file > > Hi Jeff, > > Don't modify or use the certificates in certs.c. The certificates in the certs module are only intended for testing and they will be moved from the library to the test code soon. They are never used automatically and should never be used outside of tests. > > The easiest way to set these root certificates is to pass the file to mbedtls_x509_crt_parse_file(). This gives you an object that represents the certificates and you can use those as the trusted CAs for certificate verification through the X.509 or TLS API. > > Your code might look like this (error checking and rest of the code > omitted): > > mbedtls_x509_crt roots; // head of the list of trusted CAs mbedtls_x509_crt_init(&roots); mbedtls_x509_crt_parse_file(&roots, "roots.pem"); … // Verify that there is a chain of trust from a certificate to one of the trusted CAs mbedtls_x509_crt_verify(&crt_to_verify, &roots, NULL, NULL, &flags, NULL, NULL); … // Use the trusted CAs for a TLS connection mbedtls_ssl_conf_ca_chain(&ssl_config, roots, NULL); … // Once the certificates are no longer used anywhere mbedtls_x509_crt_free(&roots); > > > Best regards, > > -- > Gilles Peskine > Mbed TLS developer > > On 23/06/2020 21:38, Thompson, Jeff via mbed-tls wrote: >> I’ve downloaded https://pki.goog/roots.pem and want to use the >> certificates in it with mbedTLS. Is there some documentation that >> tells me how to do this? >> >> >> >> The certs.c file only contains only a handful of certs, while the PEM >> file has nearly 40. How do I know which one to use for what purpose? >> The certs.c file has these certificate char[]’s: >> >> >> >> mbedtls_test_ca_crt_ec >> >> mbedtls_test_srv_crt_ec >> >> mbedtls_test_cli_crt_ec >> >> mbedtls_test_ca_crt_rsa >> >> mbedtls_test_ca_crt_rsa >> >> mbedtls_test_srv_crt_rsa >> >> mbedtls_test_cli_crt_rsa >> >> >> >> I’m reasonably sure I don’t need to replace mbedtls_test_cli_crt_ec >> and mbedtls_test_cli_crt_rsa, since I am not using a client >> certificate. But I’m not at all sure about whether I need to replace >> the 3 **_ca_crt_** certs, the 2 **_srv_crt_** certs, or all 5. And, if >> so, using which certs from the PEM file to replace which certs in >> certs.c?. How do I figure out what to do here? I’ve never dealt with >> cloud communication like this before, so please pardon my ignorance; >> I’m eager to learn, but overwhelmed by so much that is new to me. >> >> >> >> Thanks, >> >> >> >> *Jeff Thompson* | Senior Electrical Engineer-Firmware >> +1 704 752 6513 x1394 >> www.invue.com >> >> >> >> > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

6 years, 1 month

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls