- mbed-tls - lists.trustedfirmware.org

by Fatima, Fariya

Hi, I do not quite have enough knowledge on DTLS session resumption .. nevertheless here's my question: a) Difference between the features: MBEDTLS_SSL_COOKIE_C and MBEDTLS_SSL_SESSION_TICKETS? b) Enabling the feature MBEDTLS_SSL_SESSION_TICKETS would be sufficient to resume an earlier established DTLS session quickly (i.e avoid the whole TLS handshake done the last time)? c) How do I test this - i.e initiate connection from client and server, break the connection and then make the client connect to the server again? Not sure what additional steps are required on client side. Any callbacks to be registered in the code? Regards, Fariya

4 years, 11 months

1
0
0 0

Re: [mbed-tls] SSH client sample (Gilles Peskine)

by Christie Su

Hi Gilles, I checked one you recommended and looks like it is very complicated. Do you have any sample project(SSH client) based on MbedTLS+LWIP? Thanks, Christie -----Original Message----- From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of mbed-tls-request(a)lists.trustedfirmware.org Sent: July-22-20 11:35 AM To: mbed-tls(a)lists.trustedfirmware.org Subject: mbed-tls Digest, Vol 5, Issue 15 Send mbed-tls mailing list submissions to mbed-tls(a)lists.trustedfirmware.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls or, via email, send a message with subject or body 'help' to mbed-tls-request(a)lists.trustedfirmware.org You can reach the person managing the list at mbed-tls-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of mbed-tls digest..." Today's Topics: 1. Problem with decrypt aes 128 in ecb mode. HELP ME! (dany_banik2000(a)yahoo.com) 2. Re: SSH client sample (Gilles Peskine) 3. Re: patches for low memory (Gilles Peskine) ---------------------------------------------------------------------- Message: 1 Date: Wed, 22 Jul 2020 14:42:33 +0000 (UTC) From: "dany_banik2000(a)yahoo.com" <dany_banik2000(a)yahoo.com> To: mbed-tls(a)lists.trustedfirmware.org Subject: [mbed-tls] Problem with decrypt aes 128 in ecb mode. HELP ME! Message-ID: <1371131400.5486983.1595428953399(a)mail.yahoo.com> Content-Type: text/plain; charset="utf-8" I developed a server application that obtains the data from a dht11 sensor, I encrypt it with aes 128 and publish it on the server. The client application makes a request to the server, and I would like to decrypt the answer. When I want to display decrypted message, it shows garbage The message retrieved from the server is in hex. I think that must to convert hex in binary, but i don’t know how can do it… -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.trustedfirmware.org/pipermail/mbed-tls/attachments/20200722/a5…> ------------------------------ Message: 2 Date: Wed, 22 Jul 2020 17:10:18 +0200 From: Gilles Peskine <gilles.peskine(a)arm.com> To: mbed-tls(a)lists.trustedfirmware.org Subject: Re: [mbed-tls] SSH client sample Message-ID: <4a7265ac-7b3e-33ef-7222-4cd29c3cda08(a)arm.com> Content-Type: text/plain; charset=windows-1252 Hi Christie, Libssh2 (https://github.com/libssh2/libssh2) supports Mbed TLS. I've never used it or investigated it, so I can't vouch for it, I just know that it's there. -- Gilles Peskine Mbed TLS developer On 21/07/2020 18:40, Christie Su via mbed-tls wrote: > > Hi, > > ï¿½ > > I am using FRDM-K64F with LWIP+mbedTLS for our control system. Now, I > want to develop the SSH client(or telnet 22) to access my SSH server. > > ï¿½ > > Could you give me some indications how to do it? Or do you have any > sample project? > > ï¿½ > > Thanks, > > ï¿½ > > Christie > > ------------------------------ Message: 3 Date: Wed, 22 Jul 2020 17:34:44 +0200 From: Gilles Peskine <gilles.peskine(a)arm.com> To: mbed-tls(a)lists.trustedfirmware.org Subject: Re: [mbed-tls] patches for low memory Message-ID: <152f6571-6972-8262-c38d-d200dcc7c0b7(a)arm.com> Content-Type: text/plain; charset=utf-8 Hi Nick, A TLS stack in 6kB of RAM sounds impressive, congratulations! We'd certainly be interested in all the improvements you can contribute. The process is documented in CONTRIBUTING.md (https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md). I just need to warn you that the limiting factor is reviewers' time. For a significant contribution, it may take a while before the Mbed TLS team can look at it in detail. Small patches are usually easier than large ones: if something only takes half an hour to review, someone will probably do it when they're stuck on some other task. If a review takes several days, it needs to be scheduled. It would probably be better to discuss the general nature of the changes on this mailing list first. Is a new compilation option needed? Is an API change needed? What is the risk that the change might break existing code? How is the new code tested? etc. Which version of Mbed TLS have you been using? We've made a few changes that are of interest to low-memory platforms recently, such as the option MBEDTLS_SSL_VARIABLE_BUFFER_LENGTH to resize SSL buffers after the handshake (new in 2.22). I don't know what the issue with the incoming SSL packet header length could be. If you could give precise steps to reproduce the issue, this would be very helpful. Eventually we'd want to construct a test in tests/ssl-opt.sh for this. -- Gilles Peskine Mbed TLS developer On 17/07/2020 21:00, Nick Setzer via mbed-tls wrote: > > Hi, I have been working with Mbed TLS for the last 6 months in an > extremely low memory use case. This library has been an absolute joy > to work with because of how flexible it is. I have an interesting use > case with how little RAM I have to work with (around 6kb on one > microprocessor) and I have made some changes that I thought would be > of interest. I'm not sure if I should submit them as a single > changeset or a set of changes. I'll describe the changes and if there > is interest I can clean them up for submission. > > The first change that I made was for a scenario with two > microprocessors communicating over a UART. I was already using TLS > offloading so that the private key was on one processor (with only 6kb > of RAM free) and the SSL context stored on the other. I required > generating a CSR and thus made some changes to the CSR code to be able > to generate the CSR using a similar private key offloading strategy. > > I found an issue with downloading firmware for OTA from openssl web > servers. This is a little tricky to describe. The server was not > responsive to requests for reducing the max fragment length, which > forced me to use MBEDTLS_SSL_MAX_CONTENT_LEN set to 16384. But I > needed to have multiple ssl sessions open for other activities and did > not have enough RAM to hold multiple large buffers. I have made a set > of changes to allow setting the content length when the ssl context is > initialized, as well as setting different IN and OUT content lengths > to save memory. This change allowed me to set up one session with 16kb > for the IN content length, and then 4kb for OUT content length, while > a second session could use 2kb for a total of 24kb instead of 64kb. > > Related to the openssl issue, I found that the incoming ssl packet > header length can sometimes be 8 or 16 bytes larger than expected > depending on which AES method is selected. I'm not actually sure what > the best way to solve this is. One way may be to change > MBEDTLS_SSL_HEADER_LEN from 13 to 29 bytes. However I ended up solving > it by adding 16 to both MBEDTLS_SSL_IN_BUFFER_LEN and > MBEDTLS_SSL_OUT_BUFFER_LEN. This way I could handle the larger ssl > header as well as receive the content body. > > If these three changes sound interesting I can start work on cleaning > up the code to be less specific to my company and then submit the > changes. Also I would like to know if there is any process I should be > following when submitting these changes. > > Thanks, > > Nick Setzer > SimpliSafe, Inc. > 294 Washington Street, 9th Floor > Boston, MA 02108 > ------------------------------ Subject: Digest Footer mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls ------------------------------ End of mbed-tls Digest, Vol 5, Issue 15 ***************************************

4 years, 11 months

1
0
0 0

Re: [mbed-tls] [Mbed-tls-announce] Force push on the master branch

by Gilles Peskine

On 20/07/2020 12:21, Scott Branden via mbed-tls wrote: > Although this particular change doesn't affect me - rewriting history is a > bad idea. > > Why not simply commit a revert back to a cleaner point on "master" branch > and then commit the new changes you want from there? > > Then history is not lost on master branch. Mbed TLS used to follow the Git Flow model: day-to-day work happens on the 'development' branch, and there's a 'master' branch which always points to the latest commit on master that's a tagged release. A release is done by tagging a commit on 'development' and fast-forwarding 'master' to it. But after the 2.16 LTS release, we made 'master' follow the 2.16 LTS branch rather than 'development'. I think this was a mistake, but it's too late to change this, the question is what we do now with the existing situation. A force-push on 'master' would not erase history from the face of the world. The history is still there in 'mbedtls-2.16'. It is no longer possible to fast-forward 'master' to any commit on 'development'. No amount of revert or merge commits on 'master' will make it be the same commit as some a release made from 'development'. Without a force-push, all we can hope is to have 'master' have the same content as a release. This means that getting the same release would give you the same content, but different history, depending on whether tyou get it from 'master' or 'development'. This would also mean a more complicated release process. Another solution would be to do a merge of 'master' into 'development', ignoring all changes from the 'master' side. But this would mess up the history on 'development'. Is this more complicated release process, or this messy history, worth it, just to avoid a force-push? > Or, with the BLM movement some repos are stopping use of master branch. > github seems to be encourage it going forware: > https://www.zdnet.com/article/github-to-replace-master-with-alternative-ter… > > So another option: stop using "master" branch. You could even create a > tag/rename and then delete the branch name to avoid any confusions. History > won't be rewritten then, just a little "hidden". > And start using a new "main" branch. You can push you entire commit series > there without revering anything on master branch. Sure, we can create a new branch name. But then we'd still have to keep a branch with the old name, for the sake of existing setups that pull from 'master'. Or else we should make a commit on 'master' that removes every file and instead adds a README that says "pull from 'main' instead". -- Gilles Peskine Mbed TLS developer

4 years, 11 months

1
0
0 0

Re: [mbed-tls] patches for low memory

by Gilles Peskine

On 22/07/2020 17:35, Gilles Peskine via mbed-tls wrote: > I just need to warn you that the limiting factor is reviewers' time. For a > significant contribution, it may take a while before the Mbed TLS team > can look at it in detail. Small patches are usually easier than large > ones: if something only takes half an hour to review, someone will > probably do it when they're stuck on some other task. If a review takes > several days, it needs to be scheduled. As an aside, Mbed TLS is under the governance of TrustedFirmware. Currently, only Arm employees are consider trusted reviewers, but this is not by policy, it's only due to the history of the project (until a few months ago, Mbed TLS was governed by Arm). We (as in, the Arm employees working on Mbed TLS) welcome design and code reviews from everyone. We don't yet have a formal process for becoming a “trusted” reviewer, beyond the general principles of TrustedFirmware. But a required part of that process will undoubtedly be to have done some reviews before. As every project, there is an informal, unwritten culture. If there's interest, we can try to document our review culture in writing. If I had to sum it up in one sentence, I'd say that if a reviewer should reject code that they don't understand: it's the job of the patch author to convince reviewers that the patch is good. “I don't see anything wrong” is not a good enough standard. -- Gilles Peskine Mbed TLS developer

4 years, 11 months

1
0
0 0

Re: [mbed-tls] patches for low memory

by Gilles Peskine

Hi Nick, A TLS stack in 6kB of RAM sounds impressive, congratulations! We'd certainly be interested in all the improvements you can contribute. The process is documented in CONTRIBUTING.md (https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md). I just need to warn you that the limiting factor is reviewers' time. For a significant contribution, it may take a while before the Mbed TLS team can look at it in detail. Small patches are usually easier than large ones: if something only takes half an hour to review, someone will probably do it when they're stuck on some other task. If a review takes several days, it needs to be scheduled. It would probably be better to discuss the general nature of the changes on this mailing list first. Is a new compilation option needed? Is an API change needed? What is the risk that the change might break existing code? How is the new code tested? etc. Which version of Mbed TLS have you been using? We've made a few changes that are of interest to low-memory platforms recently, such as the option MBEDTLS_SSL_VARIABLE_BUFFER_LENGTH to resize SSL buffers after the handshake (new in 2.22). I don't know what the issue with the incoming SSL packet header length could be. If you could give precise steps to reproduce the issue, this would be very helpful. Eventually we'd want to construct a test in tests/ssl-opt.sh for this. -- Gilles Peskine Mbed TLS developer On 17/07/2020 21:00, Nick Setzer via mbed-tls wrote: > > Hi, I have been working with Mbed TLS for the last 6 months in an > extremely low memory use case. This library has been an absolute joy > to work with because of how flexible it is. I have an interesting use > case with how little RAM I have to work with (around 6kb on one > microprocessor) and I have made some changes that I thought would be > of interest. I'm not sure if I should submit them as a single > changeset or a set of changes. I'll describe the changes and if there > is interest I can clean them up for submission. > > The first change that I made was for a scenario with two > microprocessors communicating over a UART. I was already using TLS > offloading so that the private key was on one processor (with only 6kb > of RAM free) and the SSL context stored on the other. I required > generating a CSR and thus made some changes to the CSR code to be able > to generate the CSR using a similar private key offloading strategy. > > I found an issue with downloading firmware for OTA from openssl web > servers. This is a little tricky to describe. The server was not > responsive to requests for reducing the max fragment length, which > forced me to use MBEDTLS_SSL_MAX_CONTENT_LEN set to 16384. But I > needed to have multiple ssl sessions open for other activities and did > not have enough RAM to hold multiple large buffers. I have made a set > of changes to allow setting the content length when the ssl context is > initialized, as well as setting different IN and OUT content lengths > to save memory. This change allowed me to set up one session with 16kb > for the IN content length, and then 4kb for OUT content length, while > a second session could use 2kb for a total of 24kb instead of 64kb. > > Related to the openssl issue, I found that the incoming ssl packet > header length can sometimes be 8 or 16 bytes larger than expected > depending on which AES method is selected. I'm not actually sure what > the best way to solve this is. One way may be to change > MBEDTLS_SSL_HEADER_LEN from 13 to 29 bytes. However I ended up solving > it by adding 16 to both MBEDTLS_SSL_IN_BUFFER_LEN and > MBEDTLS_SSL_OUT_BUFFER_LEN. This way I could handle the larger ssl > header as well as receive the content body. > > If these three changes sound interesting I can start work on cleaning > up the code to be less specific to my company and then submit the > changes. Also I would like to know if there is any process I should be > following when submitting these changes. > > Thanks, > > Nick Setzer > SimpliSafe, Inc. > 294 Washington Street, 9th Floor > Boston, MA 02108 >

4 years, 11 months

1
0
0 0

Re: [mbed-tls] SSH client sample

by Gilles Peskine

Hi Christie, Libssh2 (https://github.com/libssh2/libssh2) supports Mbed TLS. I've never used it or investigated it, so I can't vouch for it, I just know that it's there. -- Gilles Peskine Mbed TLS developer On 21/07/2020 18:40, Christie Su via mbed-tls wrote: > > Hi, > > ï¿½ > > I am using FRDM-K64F with LWIP+mbedTLS for our control system. Now, I > want to develop the SSH client(or telnet 22) to access my SSH server. > > ï¿½ > > Could you give me some indications how to do it? Or do you have any > sample project? > > ï¿½ > > Thanks, > > ï¿½ > > Christie > >

4 years, 11 months

1
0
0 0

Problem with decrypt aes 128 in ecb mode. HELP ME!

by dany_banik2000＠yahoo.com

I developed a server application that obtains the data from a dht11 sensor, I encrypt it with aes 128 and publish it on the server. The client application makes a request to the server, and I would like to decrypt the answer. When I want to display decrypted message, it shows garbage The message retrieved from the server is in hex. I think that must to convert hex in binary, but i don’t know how can do it…

4 years, 11 months

1
0
0 0

SSH client sample

by Christie Su

Hi, I am using FRDM-K64F with LWIP+mbedTLS for our control system. Now, I want to develop the SSH client(or telnet 22) to access my SSH server. Could you give me some indications how to do it? Or do you have any sample project? Thanks, Christie

4 years, 11 months

1
0
0 0

patches for low memory

by Nick Setzer

Hi, I have been working with Mbed TLS for the last 6 months in an extremely low memory use case. This library has been an absolute joy to work with because of how flexible it is. I have an interesting use case with how little RAM I have to work with (around 6kb on one microprocessor) and I have made some changes that I thought would be of interest. I'm not sure if I should submit them as a single changeset or a set of changes. I'll describe the changes and if there is interest I can clean them up for submission. The first change that I made was for a scenario with two microprocessors communicating over a UART. I was already using TLS offloading so that the private key was on one processor (with only 6kb of RAM free) and the SSL context stored on the other. I required generating a CSR and thus made some changes to the CSR code to be able to generate the CSR using a similar private key offloading strategy. I found an issue with downloading firmware for OTA from openssl web servers. This is a little tricky to describe. The server was not responsive to requests for reducing the max fragment length, which forced me to use MBEDTLS_SSL_MAX_CONTENT_LEN set to 16384. But I needed to have multiple ssl sessions open for other activities and did not have enough RAM to hold multiple large buffers. I have made a set of changes to allow setting the content length when the ssl context is initialized, as well as setting different IN and OUT content lengths to save memory. This change allowed me to set up one session with 16kb for the IN content length, and then 4kb for OUT content length, while a second session could use 2kb for a total of 24kb instead of 64kb. Related to the openssl issue, I found that the incoming ssl packet header length can sometimes be 8 or 16 bytes larger than expected depending on which AES method is selected. I'm not actually sure what the best way to solve this is. One way may be to change MBEDTLS_SSL_HEADER_LEN from 13 to 29 bytes. However I ended up solving it by adding 16 to both MBEDTLS_SSL_IN_BUFFER_LEN and MBEDTLS_SSL_OUT_BUFFER_LEN. This way I could handle the larger ssl header as well as receive the content body. If these three changes sound interesting I can start work on cleaning up the code to be less specific to my company and then submit the changes. Also I would like to know if there is any process I should be following when submitting these changes. Thanks, Nick Setzer SimpliSafe, Inc. 294 Washington Street, 9th Floor Boston, MA 02108

4 years, 12 months

1
0
0 0

Re: [mbed-tls] [Mbed-tls-announce] Force push on the master branch

by Scott Branden

Although this particular change doesn't affect me - rewriting history is a bad idea. Why not simply commit a revert back to a cleaner point on "master" branch and then commit the new changes you want from there? Then history is not lost on master branch. Or, with the BLM movement some repos are stopping use of master branch. github seems to be encourage it going forware: https://www.zdnet.com/article/github-to-replace-master-with-alternative-ter… So another option: stop using "master" branch. You could even create a tag/rename and then delete the branch name to avoid any confusions. History won't be rewritten then, just a little "hidden". And start using a new "main" branch. You can push you entire commit series there without revering anything on master branch. Regards, Scott -----Original Message----- From: Mbed-tls-announce [mailto:mbed-tls-announce-bounces@lists.trustedfirmware.org] On Behalf Of Janos Follath via Mbed-tls-announce Sent: Thursday, July 16, 2020 4:09 AM To: mbed-tls-announce(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [Mbed-tls-announce] Force push on the master branch Hi All, The master branch used to track the latest development release. This changed in early 2019 after the 2.16 LTS branch was released. Around this time the cryptography library of Mbed TLS was moved to a separate repository and since then it was used as a submodule. This was one of the main reasons behind the decision to keep master pointing to the 2.16 LTS releases. Recently we have merged the cryptography library back into Mbed TLS. We don't have any reasons any more to keep master tracking the 2.16 LTS release. Therefore we intend to update master to the latest development release. This will happen on 3rd August. The update will involve a force push, which can be disruptive to those users who take Mbed TLS from master. We would like to give such users enough time to adapt to this change. If you are relying on the master branch in a way that this force push affects you, please let us know on the developer mailing list<https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls> and we will do our best to accommodate your needs. Thanks and regards, Janos (on behalf of the Mbed TLS maintainer team) -- Mbed-tls-announce mailing list Mbed-tls-announce(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls-announce

4 years, 12 months

1
0
0 0

[Mbed-tls-announce] Force push on the master branch

by Janos Follath via Mbed-tls-announce

Hi All, The master branch used to track the latest development release. This changed in early 2019 after the 2.16 LTS branch was released. Around this time the cryptography library of Mbed TLS was moved to a separate repository and since then it was used as a submodule. This was one of the main reasons behind the decision to keep master pointing to the 2.16 LTS releases. Recently we have merged the cryptography library back into Mbed TLS. We don't have any reasons any more to keep master tracking the 2.16 LTS release. Therefore we intend to update master to the latest development release. This will happen on 3rd August. The update will involve a force push, which can be disruptive to those users who take Mbed TLS from master. We would like to give such users enough time to adapt to this change. If you are relying on the master branch in a way that this force push affects you, please let us know on the developer mailing list<https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls> and we will do our best to accommodate your needs. Thanks and regards, Janos (on behalf of the Mbed TLS maintainer team) -- Mbed-tls-announce mailing list Mbed-tls-announce(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls-announce

4 years, 12 months

1
0
0 0

Re: [mbed-tls] Upgrading from 2.13.1.to ??.??.??

by Manuel Pegourie-Gonnard

Hi Jeff, > Given the age of the version of mbedTLS I’m using, which is 2.13.1, plus the recent security alert, I think I need to upgrade the version of mbedTLS we have. The question is, which version to use? Indeed upgrading to a maintained branch is very recommended! There are currently two actively maintained branches you could use: * 2.16.x, which is our latest LTS branch, currently at 2.16.7. As an LTS branch, it only receives bug fixes and security updates, so it's pretty stable. In particular, since it doesn't receive any new feature, its footprint (code size) should remain mostly stable as well. * 2.x.y, released from the development branch, currently at 2.23.0. This is the branch where new features land. Both of these have full API compatibility with 2.13.1. We take great care not to break API compatibility between major releases - we haven't broken it since Mbed TLS 2.0.0 (release 2015-07-13), and the next release to break API compatibility with be 3.0.0 (now planned for early 2021). Until then, upgrading should be a simple matter of replacing the mbedtls directory in your source tree with the version of your choice, then rebuilding your project. (Moreover in the LTS branches we actually try maintain ABI compatibility as far as possible - that is, unless there's a security issue that can only be fixed by changing the ABI.) Mbed TLS is designed bo be quite modular an integrate with the OS and networking stack via user-provided hooks and compile-time configuration (`include/mbedtls/config.h`). I'm not sure how the integration with LwIP and FreeRTOS was done by your MCU vendor, but I suggest you check: * is the mbedtls directory in your source tree identical to our upstream release? If yes, you should be able to just replace it with the release of your choice and things should work. * otherwise, what's the nature of the differences: are filed shuffled to a different directory structure? is the build system different? has the `mbedtls/config.h` file been modified? have other files been modified (which ideally really shouldn't be necessary)? In that case, you'll probably need to apply the same changes to the upgraded version of Mbed TLS. Hopefully the differences if any will be small, and otherwise perhaps you MCU vendor can provide documentation about it. So I can't really say for this specific integration, but in principle upgrading Mbed TLS should be really painless - precisely so that people can upgrade easily in case of security fixes. Hope this helps, and let us know how it went! Regards, Manuel. ________________________________ 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: 14 July 2020 22:11 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Upgrading from 2.13.1.to ??.??.?? Given the age of the version of mbedTLS I’m using, which is 2.13.1, plus the recent security alert, I think I need to upgrade the version of mbedTLS we have. The question is, which version to use? Because we got mbedTLS as example code from the MCU vendor, it was already integrated with lwIP and FreeRTOS. I’m sure this will not be a trivial effort, but I do need to present my management with some idea of the time it could take. Does anyone have a rough estimate of what to expect? I’m thinking on the order of 2 to 4 weeks for someone who is an experienced C programmer, but unfamiliar with either mbedTLS or lwIP. Or is that a pipe dream, with the actual time being closer to 3 or 4 months? Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D659E2.BE6C0700]

5 years

1
0
0 0

Upgrading from 2.13.1.to ??.??.??

by Thompson, Jeff

Given the age of the version of mbedTLS I'm using, which is 2.13.1, plus the recent security alert, I think I need to upgrade the version of mbedTLS we have. The question is, which version to use? Because we got mbedTLS as example code from the MCU vendor, it was already integrated with lwIP and FreeRTOS. I'm sure this will not be a trivial effort, but I do need to present my management with some idea of the time it could take. Does anyone have a rough estimate of what to expect? I'm thinking on the order of 2 to 4 weeks for someone who is an experienced C programmer, but unfamiliar with either mbedTLS or lwIP. Or is that a pipe dream, with the actual time being closer to 3 or 4 months? Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D659E2.BE6C0700]

5 years

1
0
0 0

Re: [mbed-tls] mbed-tls canonical repository (trustedfirmware.org git empty)

by Shebu Varghese Kuriakose

Hi Matt. You are right - https://git.trustedfirmware.org/tls/mbed-tls.git seem to be empty. As part of Mbed TLS transitioning to trustedfirmware.org community project in March’20, a mirror of https://github.com/ARMmbed/mbedtls.git was created in the above trustedfirmware.org git. Yes, all the development is still carrying on in https://github.com/ARMmbed/mbedtls.git and the plan is to move the development of MbedTLS to trustedfirmware.org repository itself a bit later on. The trustedfirmware.org Mbed TLS mirror repository seem to have moved to https://git.trustedfirmware.org/mirror/mbed-tls.git/. Regards, Shebu From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of Matt Walker via mbed-tls Sent: Wednesday, July 8, 2020 8:34 PM To: mbed-tls(a)lists.trustedfirmware.org Subject: [mbed-tls] mbed-tls canonical repository (trustedfirmware.org git empty) Hi; For a while I've had a couple of projects pulling in mbed-tls from the trustedfirmware.org<http://trustedfirmware.org> git repository at https://git.trustedfirmware.org/tls/mbed-tls.git However, I just attempted to clone from that repository again only to discover it's now empty! I've searched around and I can't find any messaging on why this would be the case, so it's either an accident or my search foo is failing me. It looks like the majority of development for mbed-tls is still happening on github at https://github.com/ARMmbed/mbedtls.git but I'd rather point my upstream to the canonical location. Is this a temporary outage, or should github be considered the origin of all things mbed-tls? Thanks, Matt Walker

5 years

2
1
0 0

Mbed TLS: Security Advisory and Release of Mbed TLS 2.23.0, 2.16.7 and 2.7.16

by Janos Follath

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.

5 years

1
0
0 0

mbed-tls canonical repository (trustedfirmware.org git empty)

by Matt Walker

Hi; For a while I've had a couple of projects pulling in mbed-tls from the trustedfirmware.org git repository at https://git.trustedfirmware.org/tls/mbed-tls.git However, I just attempted to clone from that repository again only to discover it's now empty! I've searched around and I can't find any messaging on why this would be the case, so it's either an accident or my search foo is failing me. It looks like the majority of development for mbed-tls is still happening on github at https://github.com/ARMmbed/mbedtls.git but I'd rather point my upstream to the canonical location. Is this a temporary outage, or should github be considered the origin of all things mbed-tls? Thanks, Matt Walker

5 years

1
0
0 0

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

by Hannes Tschofenig

Hi all, I have been using Mbed TLS with mutual certificate-based authentication all the time. Here is the configuration: [cid:image004.jpg@01D65150.65DFD610] Here is a link to a webinar where I talk about certificate-based authentication and show-case mutual authentication with a Keil development board: https://www.youtube.com/watch?v=iH4v-aXQ2zQ<https://www.youtube.com/watch?v=iH4v-aXQ2zQ&feature=emb_logo> Slides are here: http://www2.keil.com/docs/default-source/default-document-library/keil_mbed… >From what I can tell (trying to connect to your test server myself) you haven't configured the auth_mode=required on the server side. Without it the TLS server will not send a CertificateRequest message. Ciao Hannes From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of Abhilash Iyer via mbed-tls Sent: Friday, July 3, 2020 2:56 PM To: Subramanian Gopi Krishnan <gopikrishnan.subramanian(a)kone.com> Cc: mbed-tls(a)lists.trustedfirmware.org Subject: Re: [mbed-tls] Mutual Authentication in TLS handshake - No client certificate passed 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<mailto:gopikrishnan.subramanian@kone.com>> Sent: Sunday, June 28, 2020 8:58 PM To: Abhilash Iyer <Abhilash.Iyer(a)microsoft.com<mailto:Abhilash.Iyer@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

5 years

2
3
0 0

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

5 years

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

5 years

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

5 years

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)

5 years

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 > > > >

5 years

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]

5 years

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]

5 years

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]

5 years

1
1
0 0

2025

2024

2023

2022

2021

2020

mbed-tls