- mbed-tls - lists.trustedfirmware.org

Invitation: Mbed TLS Virtual Workshop @ Tue Nov 3, 2020 7am - 11am (MST) (mbed-tls@lists.trustedfirmware.org)

by Don Harbin

You have been invited to the following event. Title: Mbed TLS Virtual Workshop Hi,Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discussThe future direction of the project andWays to improve community collaborationHere is the agenda for the workshop.Topic                                                                         Time (in GMT)Welcome                                                                   2.00 - 2.10pmConstant-time code                                                2.10 – 2.30pmProcesses - how does work get scheduled?      2.30 – 2.50pmPSA Crypto APIs                                                     2.50 – 3.20pmPSA Crypto for Silicon Labs Wireless         MCUs - Why, What, Where and When          3.20 – 3.50pmBreak                                                                          Roadmap, TLS1.3 Update                                      4.10 – 4.30pmMbed TLS 3.0 Plans, Scope                                   4.30 – 5.00pmHow do I contribute my first review         and be an effective Mbed TLS reviewer      5.00 – 5.30pmRegards,Don Harbin Trusted Firmware Community Manager==============Zoom details below:====================Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: Mbed TLS Virtual WorkshopTime: Nov 3, 2020 02:00 PM Greenwich Mean TimeJoin Zoom Meetinghttps://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT09Meeting ID: 953 1520 0315Passcode: 143755One tap mobile+16699009128,,95315200315# US (San Jose)+12532158782,,95315200315# US (Tacoma)Dial by your location        +1 669 900 9128 US (San Jose)        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 646 558 8656 US (New York)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        888 788 0099 US Toll-free        877 853 5247 US Toll-freeMeeting ID: 953 1520 0315Find your local number: https://linaro-org.zoom.us/u/apL3hgti4 When: Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin - creator * shebu.varghesekuriakose(a)arm.com * mbed-tls(a)lists.trustedfirmware.org * psa-crypto(a)lists.trustedfirmware.org * dave.rodgman(a)arm.com Event details: https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years, 11 months

1
0
0 0

Availability of GPLv2 releases in the future

by Fabian Keil

Hi, tls.mbed.org currently sends mixed signals regarding the license of future MbedTLS releases. Quoting https://tls.mbed.org/download: | In packaged form, mbed TLS 2.1.0 to mbed TLS 2.16 are | available in both an Apache 2.0 licensed version (our | primary open source license) and in a GPL 2.0 licensed version. | | Newer versions will be available under the Apache 2.0 license. Quoting https://tls.mbed.org/how-to-get: | All the current versions of the mbed TLS library are distributed | under the Apache 2.0 license and available from our Download area. | In addition there are packaged versions of the mbed TLS library | that are distributed with the GNU Public License Version 2.0 (GPL v2.0). | | The Apache-licensed and GPL-licensed versions of mbed TLS are | identical in source code (with the exception of the license | headers at the top of files). | | We plan to keep both licensed versions around. Can anyone estimate when "newer releases" will no longer be dual licensed? We recently added MbedTLS support for Privoxy and a MbedTLS license switch from dual license to Apache 2.0 complicates the license terms. Thanks Fabian

4 years, 11 months

1
0
0 0

Fwd: Working on TLS handshake record fragmentation (#1840)

by Omer Shapira

Hi Dave, Thanks for your reply. The particular reasons for bringing up 2.7 and 2.16 first is that my employer is currently using 2.7 and would prefer using a small increment. Having said that, if adding features to LTS is not advisable (especially given that 2.7 has less than 6 months of projected life), I think I can present the arguments against using the 2.7. Additional consideration is the timing. My employer needs fragmentation support as soon as possible, with the intent of running it on a desktop environment. Historically, when the engineers are able to provide my employer with what is needed now, they are allowed more time for incremental improvements. The third consideration involves the MPS project by Hanno Becker. I've been collaborating with Hanno, and with Hannes Tschofenig and Thomas Fosetti on the project of adding QUIC support to mbedTLS. This goal depends on TLS 1.3 support (Hannes has written a prototype, which I was able to add QUIC in an internal version), and on MPS. I would like to avoid putting a duplicate effort into non-MPS fragmentation support. Unfortunately, if I want to meet the timing requirements of my employer, I will not be able to use MPS, since it needs more maturing. Because of the above considerations, I would like to suggest the following plan of actions: As the first step, I would like to add the MVP (minimal viable product) fragmentation to the development version. The MVP takes the following assumptions: 1. The RAM footprint is not a concern for the MVP (my employer is going to run it in the desktop environment). 2. Unification of the fragmentation between TLS and DTLS is not a concern for the MVP 3. LTS is not a concern for the MVP (potentially not at all) Because of the above simplifying assumptions, I believe that the change can be small and focused. I think I can have code ready for review in a couple of weeks. As the second step, I would like to put my effort into helping Hanno Becker with his MPS system. Once sufficiently mature, the MPS will supersede the MVP fragmentation, and will open the doors for adding support for QUIC. The simplifying assumptions 1. (RAM) and 2. (TLS <=> DTLS) will be addressed by MPS. Addressing the last assumption may not be required. What are your thoughts? On Wed, Oct 14, 2020 at 10:28 AM Dave Rodgman <dave.rodgman(a)arm.com> wrote: > Hi Omer, > > > > Thanks for offering to help us with this feature. > > > > Normally, we wouldn’t add new features directly to an older branch, for a > few reasons. 2.7 is quite old and is in fact only guaranteed to be > supported until Feb 21, so it’s not the ideal place to spend effort on new > features. Introducing new features here would also create the situation > where 2.7 has features not in development, and vice-versa, creating an > upgrade dilemma for users (unless we were to port the feature to all > supported branches). And adding significant new features to LTS branches > can always introduce some risk of destabilising it. > > > > So for these reasons, we would normally recommend targeting the > development branch for new features (with backports only where there is a > strong reason to do so), and then picking up the next stable release that > contains the new feature. > > > > Is there a particular reason you’re focusing on 2.7, rather than > development, or would it be viable for you to add this to development and > pick up the next release? > > > > Thanks > > > > Dave > > > > *From: *mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf > of Omer Shapira via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> > *Reply to: *Omer Shapira <omer.shapira(a)gmail.com> > *Date: *Monday, 12 October 2020 at 20:04 > *To: *"mbed-tls(a)lists.trustedfirmware.org" < > mbed-tls(a)lists.trustedfirmware.org> > *Subject: *[mbed-tls] Working on TLS handshake record fragmentation > (#1840) > > > > Hello, > > My employer (Facebook) is willing to give me some time to TLS handshake > fragmentation support to MbedTLS 2.7 [0] . This would be my first > contribution to MbedTLS, and I have several novice questions: > > 1. What is the best way to add the feature to MbedTLS 2.7? > 2. Trade-off between the consistency of the fragmentation code across the > branches, vs. the consistency of the branches. > > > Question 1: Best way to add the feature to MbedTLS 2.7 > > One constraint that I am facing is the code must be added to the upstream > branch that is as close as possible to the 2.7.xx. My understanding of the > Contribution Guidelines[1] is that while the LTS branches are mostly meant > for the bug fixes, backporting of the new features is welcomed as long as > the API/ABI compatibility is maintained and the disruption to the users is > minimized. > > If adding support to the LTS branches is not advisable, are there any > other possibilities of contributing the code to an upstream branch that is > very close to the 2.7.xx? > > Question 2: Trade-off between the consistency of the fragmentation code > across the branches, vs. the consistency of the branches. > > Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a > trade-off between the consistency of the fragmentation code across the > branches, vs. the consistency of the branches. The `development` branch > supports variable-length buffers[2] . Variable messages sizes would make > the fragmentation easier in the development branch. In addition, there is > the MPS effort by Hanno Becker which would make the fragmentation support > even easier in the development branch. None of that is present in the 2.7 > or the 2.16 branches. > > What is the preferable trade-off in such a situation: > a. Minimizing the change to the "host" version (2.7 or 2.16), on the > expense the implementation of the feature differ between 2.7 and > `development`, or > b. Minimizing the differences in the implementation of the feature, on > the expense of more intrusive changes to the earlier versions? > > > [0] https://github.com/ARMmbed/mbedtls/issues/1840 > [1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md > [2] > https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.… > > -- > > Sincerely Yours, > Omer Shapira > -- Sincerely Yours, Omer Shapira -- Sincerely Yours, Omer Shapira

4 years, 11 months

1
0
0 0

Re: [mbed-tls] Working on TLS handshake record fragmentation (#1840)

by Dave Rodgman

Hi Omer, Thanks for offering to help us with this feature. Normally, we wouldn’t add new features directly to an older branch, for a few reasons. 2.7 is quite old and is in fact only guaranteed to be supported until Feb 21, so it’s not the ideal place to spend effort on new features. Introducing new features here would also create the situation where 2.7 has features not in development, and vice-versa, creating an upgrade dilemma for users (unless we were to port the feature to all supported branches). And adding significant new features to LTS branches can always introduce some risk of destabilising it. So for these reasons, we would normally recommend targeting the development branch for new features (with backports only where there is a strong reason to do so), and then picking up the next stable release that contains the new feature. Is there a particular reason you’re focusing on 2.7, rather than development, or would it be viable for you to add this to development and pick up the next release? Thanks Dave From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Omer Shapira via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: Omer Shapira <omer.shapira(a)gmail.com> Date: Monday, 12 October 2020 at 20:04 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Working on TLS handshake record fragmentation (#1840) Hello, My employer (Facebook) is willing to give me some time to TLS handshake fragmentation support to MbedTLS 2.7 [0] . This would be my first contribution to MbedTLS, and I have several novice questions: 1. What is the best way to add the feature to MbedTLS 2.7? 2. Trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. Question 1: Best way to add the feature to MbedTLS 2.7 One constraint that I am facing is the code must be added to the upstream branch that is as close as possible to the 2.7.xx. My understanding of the Contribution Guidelines[1] is that while the LTS branches are mostly meant for the bug fixes, backporting of the new features is welcomed as long as the API/ABI compatibility is maintained and the disruption to the users is minimized. If adding support to the LTS branches is not advisable, are there any other possibilities of contributing the code to an upstream branch that is very close to the 2.7.xx? Question 2: Trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. The `development` branch supports variable-length buffers[2] . Variable messages sizes would make the fragmentation easier in the development branch. In addition, there is the MPS effort by Hanno Becker which would make the fragmentation support even easier in the development branch. None of that is present in the 2.7 or the 2.16 branches. What is the preferable trade-off in such a situation: a. Minimizing the change to the "host" version (2.7 or 2.16), on the expense the implementation of the feature differ between 2.7 and `development`, or b. Minimizing the differences in the implementation of the feature, on the expense of more intrusive changes to the earlier versions? [0] https://github.com/ARMmbed/mbedtls/issues/1840 [1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md [2] https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.… -- Sincerely Yours, Omer Shapira

4 years, 11 months

1
0
0 0

Re: [mbed-tls] Working on TLS handshake record fragmentation (#1840)

by Omer Shapira

While waiting for opinions regarding the question of adding features to the LTS versions, I have written a draft design doc. I discussed the "design review process" with Hanno Becker, and we decided to try and use GitHub for the design review. I have created PR #3783 [0], which includes `docs/proposed/hs_fragmentation.md` [1]. I will appreciate your comments, and will update the design doc following the feedback. Once there is clarity on the approach, I will proceed with the implementation PRs. [0] https://github.com/ARMmbed/mbedtls/pull/3783 [1] https://github.com/ARMmbed/mbedtls/pull/3783/commits/8be34f22237ee3cd3c1db2… On Mon, Oct 12, 2020 at 12:04 PM Omer Shapira via mbed-tls < mbed-tls(a)lists.trustedfirmware.org> wrote: > Hello, > > My employer (Facebook) is willing to give me some time to TLS handshake > fragmentation support to MbedTLS 2.7 [0] . This would be my first > contribution to MbedTLS, and I have several novice questions: > > 1. What is the best way to add the feature to MbedTLS 2.7? > 2. Trade-off between the consistency of the fragmentation code across the > branches, vs. the consistency of the branches. > > Question 1: Best way to add the feature to MbedTLS 2.7 > > One constraint that I am facing is the code must be added to the upstream > branch that is as close as possible to the 2.7.xx. My understanding of the > Contribution Guidelines[1] is that while the LTS branches are mostly meant > for the bug fixes, backporting of the new features is welcomed as long as > the API/ABI compatibility is maintained and the disruption to the users is > minimized. > > If adding support to the LTS branches is not advisable, are there any > other possibilities of contributing the code to an upstream branch that is > very close to the 2.7.xx? > > Question 2: Trade-off between the consistency of the fragmentation code > across the branches, vs. the consistency of the branches. > > Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a > trade-off between the consistency of the fragmentation code across the > branches, vs. the consistency of the branches. The `development` branch > supports variable-length buffers[2] . Variable messages sizes would make > the fragmentation easier in the development branch. In addition, there is > the MPS effort by Hanno Becker which would make the fragmentation support > even easier in the development branch. None of that is present in the 2.7 > or the 2.16 branches. > > What is the preferable trade-off in such a situation: > a. Minimizing the change to the "host" version (2.7 or 2.16), on the > expense the implementation of the feature differ between 2.7 and > `development`, or > b. Minimizing the differences in the implementation of the feature, on > the expense of more intrusive changes to the earlier versions? > > > [0] https://github.com/ARMmbed/mbedtls/issues/1840 > [1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md > [2] > https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.… > > -- > Sincerely Yours, > Omer Shapira > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > -- Sincerely Yours, Omer Shapira

4 years, 11 months

1
0
0 0

Working on TLS handshake record fragmentation (#1840)

by Omer Shapira

Hello, My employer (Facebook) is willing to give me some time to TLS handshake fragmentation support to MbedTLS 2.7 [0] . This would be my first contribution to MbedTLS, and I have several novice questions: 1. What is the best way to add the feature to MbedTLS 2.7? 2. Trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. Question 1: Best way to add the feature to MbedTLS 2.7 One constraint that I am facing is the code must be added to the upstream branch that is as close as possible to the 2.7.xx. My understanding of the Contribution Guidelines[1] is that while the LTS branches are mostly meant for the bug fixes, backporting of the new features is welcomed as long as the API/ABI compatibility is maintained and the disruption to the users is minimized. If adding support to the LTS branches is not advisable, are there any other possibilities of contributing the code to an upstream branch that is very close to the 2.7.xx? Question 2: Trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. The `development` branch supports variable-length buffers[2] . Variable messages sizes would make the fragmentation easier in the development branch. In addition, there is the MPS effort by Hanno Becker which would make the fragmentation support even easier in the development branch. None of that is present in the 2.7 or the 2.16 branches. What is the preferable trade-off in such a situation: a. Minimizing the change to the "host" version (2.7 or 2.16), on the expense the implementation of the feature differ between 2.7 and `development`, or b. Minimizing the differences in the implementation of the feature, on the expense of more intrusive changes to the earlier versions? [0] https://github.com/ARMmbed/mbedtls/issues/1840 [1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md [2] https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.… -- Sincerely Yours, Omer Shapira

4 years, 11 months

1
0
0 0

Mbed TLS Virtual Workshop on Nov. 3rd

by Shebu Varghese Kuriakose

Hi All, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop on November 3rd (Tuesday) from 2pm to 6pm GMT. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration The workshop will be hosted in Zoom open to all. The invitation with the zoom link will be send in the Mbed TLS, PSA Crypto* mailing lists in the coming days. Here are some of the proposed agenda topics. Please reply if there is anything else you would like us or you to present during the workshop that will be interesting to the community * Constant-time code * How to be an effective Mbed TLS reviewer * Processes - how does work get scheduled? * Roadmap, Mbed TLS3.0 * PSA Crypto APIs * How Do I contribute my first review. Thanks, Shebu (TrustedFirmware.org Co-Chair, Mbed TLS Technology Manager) * https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto

4 years, 11 months

1
0
0 0

Re: [mbed-tls] Official bug list

by Janos Follath

Hi Innocenti, The official list of defects is available on github: https://github.com/ARMmbed/mbedtls/issues?q=is%3Aissue+is%3Aopen+label%3Abug The revision of fixing is in the Bugfix sections of the ChangeLog file in the source. Eg. for the latest release: https://github.com/ARMmbed/mbedtls/blob/mbedtls-2.24.0/ChangeLog The entries here usually reference the issue number they fixed. Is this something that you can use for your evaluation? Regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of "Innocenti, Michele via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org> Reply to: "Innocenti, Michele" <michele_innocenti(a)baxter.com> Date: Thursday, 1 October 2020 at 14:04 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Official bug list Hi, We are evaluating Mbed TLS library and we need to know if it’s available an official list of defects and revision of fixing. I’m not looking for CVEs but for bugs in the library. Thanks! Michele

4 years, 11 months

1
0
0 0

Official bug list

by Innocenti, Michele

Hi, We are evaluating Mbed TLS library and we need to know if it's available an official list of defects and revision of fixing. I'm not looking for CVEs but for bugs in the library. Thanks! Michele

4 years, 11 months

1
0
0 0

Re: [mbed-tls] FIPS

by Janos Follath

Hi, There is no FIPS validated/certified version of Mbed TLS. In general most of the components should be very close to FIPS/NIST standards, but I don’t know of any that would have undergone a validation/certification process. Regards, Janos (Mbed TLS developer) From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Subramanian Gopi Krishnan via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: Subramanian Gopi Krishnan <gopikrishnan.subramanian(a)kone.com> Date: Thursday, 1 October 2020 at 07:38 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] FIPS Hi, Do we have FIPS compliant for mbedtls; similar to openssl fips? Thanks, Gopi Krishnan

4 years, 11 months

1
0
0 0

FIPS

by Subramanian Gopi Krishnan

Hi, Do we have FIPS compliant for mbedtls; similar to openssl fips? Thanks, Gopi Krishnan

4 years, 11 months

1
0
0 0

Re: [mbed-tls] Building a collaborative Mbed TLS community

by Frank Bergmann

Hi Gilles, actually I meant that the creator of the PR tries to make a first estimation. Maybe even this could be helpful. :-) Frank On Wed, Sep 30, 2020 at 09:47:41AM +0000, Gilles Peskine via mbed-tls wrote: > Hi Frank, > > Thanks for the suggestion. Sorry for not replying earlier. A time > estimate can help with scheduling, but our problem isn't so much > scheduling as a lack of bandwidth. Also we've found it very difficult to > estimate the time a review will take: some innocuous-looking patches end > up raising time-consuming questions about security or compatibility, > while some large patches turn out to be easy because they don't affect > risky areas much. > > The way we currently work is to schedule large contributions as part of > our sprint planning, but for most reviews we put them in a queue > (https://github.com/orgs/ARMmbed/projects/3). We've found that for our > team, having people pull from that queue works better than designating > reviewers a priori. > > -- > Gilles Peskine > Mbed TLS developer > > On 21/09/2020 07:35, Frank Bergmann via mbed-tls wrote: > > Hi Gilles, > > > > when I ask in our team to review a PR I usually provide an estimation about > > it. Of course a time base estimation and not an agile one in values of > > complexity. ;-) > > One could also provide an estimation about priority. > > Maybe these tiny rules may help somewhat. At least it can provide a better > > overview if you have tons of PRs. > > > > sincerely, > > Frank > > > > On Sun, Sep 20, 2020 at 10:27:44PM +0000, Gilles Peskine via mbed-tls wrote: > >> Hello, > >> > >> Historically, Mbed TLS has been maintained by Arm as an open-source > >> project, accepting external contributions, but with with priorities and > >> plans mostly driven only by Arm. Since earlier this year, Mbed TLS is an > >> open governance project under the umbrella of TrustedFirmware, with the > >> objective of making it a community led project, allowing community to > >> contribute and collaborate on the design and development of the project. > >> In practice, however, the project effectively still has some barriers of > >> entry. We would like to lift these barriers. > >> > >> The Mbed TLS team at Arm have already identified some concrete actions, > >> filed on the Mbed TLS epic board > >> https://github.com/ARMmbed/mbedtls/projects/2#column-10667107 > >> under “Facilitating community contributions”. A few more should be up > >> soon as the result of some internal brainstorming. > >> > >> We've also identified some problem areas which we're tracking as > >> separate topics. > >> > >> * Probably the biggest topic: review was and is a bottleneck. We are > >> working to streamline the review process where possible, without > >> lowering the quality bar, and to prioritize reviews better over new > >> work. (Having personally often been on both sides of the coin, I can > >> confirm that having a pull request sit around for years without getting > >> reviews is frustrating, and so is seeing all these pull request and not > >> having the time to review them all.) We would also like to enable, > >> encourage and value reviews from people who are not project maintainers. > >> > >> * We will migrate the CI to a publicly available platform hosted by > >> TrustedFirmware. However this platform will not be available until 2021. > >> > >> * We are working on a new documentation platform, where we'll transfer > >> both the information available on the current website and information > >> that is currently recorded in an Arm internal wiki. > >> > >> To all of you who have contributed to Mbed TLS, who have tried, or who > >> are considering it, what difficulties have you encountered? What else > >> can we do to make contributing easier? > >> > >> Best regards, > >> > >> -- > >> Gilles Peskine > >> Mbed TLS developer > >> > >> > >> -- > >> mbed-tls mailing list > >> mbed-tls(a)lists.trustedfirmware.org > >> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls -- Frank Bergmann, Pödinghauser Str. 5, D-32051 Herford, Tel. +49-5221-9249753 SAP Hybris & Linux LPIC-3, E-Mail tx2014(a)tuxad.de, USt-IdNr DE237314606 http://tdyn.de/freel -- Redirect to profile at freelancermap http://www.gulp.de/freiberufler/2HNKY2YHW.html -- Profile at GULP

4 years, 11 months

1
0
0 0

Re: [mbed-tls] Building a collaborative Mbed TLS community

by Gilles Peskine

Hi Frank, Thanks for the suggestion. Sorry for not replying earlier. A time estimate can help with scheduling, but our problem isn't so much scheduling as a lack of bandwidth. Also we've found it very difficult to estimate the time a review will take: some innocuous-looking patches end up raising time-consuming questions about security or compatibility, while some large patches turn out to be easy because they don't affect risky areas much. The way we currently work is to schedule large contributions as part of our sprint planning, but for most reviews we put them in a queue (https://github.com/orgs/ARMmbed/projects/3). We've found that for our team, having people pull from that queue works better than designating reviewers a priori. -- Gilles Peskine Mbed TLS developer On 21/09/2020 07:35, Frank Bergmann via mbed-tls wrote: > Hi Gilles, > > when I ask in our team to review a PR I usually provide an estimation about > it. Of course a time base estimation and not an agile one in values of > complexity. ;-) > One could also provide an estimation about priority. > Maybe these tiny rules may help somewhat. At least it can provide a better > overview if you have tons of PRs. > > sincerely, > Frank > > On Sun, Sep 20, 2020 at 10:27:44PM +0000, Gilles Peskine via mbed-tls wrote: >> Hello, >> >> Historically, Mbed TLS has been maintained by Arm as an open-source >> project, accepting external contributions, but with with priorities and >> plans mostly driven only by Arm. Since earlier this year, Mbed TLS is an >> open governance project under the umbrella of TrustedFirmware, with the >> objective of making it a community led project, allowing community to >> contribute and collaborate on the design and development of the project. >> In practice, however, the project effectively still has some barriers of >> entry. We would like to lift these barriers. >> >> The Mbed TLS team at Arm have already identified some concrete actions, >> filed on the Mbed TLS epic board >> https://github.com/ARMmbed/mbedtls/projects/2#column-10667107 >> under “Facilitating community contributions”. A few more should be up >> soon as the result of some internal brainstorming. >> >> We've also identified some problem areas which we're tracking as >> separate topics. >> >> * Probably the biggest topic: review was and is a bottleneck. We are >> working to streamline the review process where possible, without >> lowering the quality bar, and to prioritize reviews better over new >> work. (Having personally often been on both sides of the coin, I can >> confirm that having a pull request sit around for years without getting >> reviews is frustrating, and so is seeing all these pull request and not >> having the time to review them all.) We would also like to enable, >> encourage and value reviews from people who are not project maintainers. >> >> * We will migrate the CI to a publicly available platform hosted by >> TrustedFirmware. However this platform will not be available until 2021. >> >> * We are working on a new documentation platform, where we'll transfer >> both the information available on the current website and information >> that is currently recorded in an Arm internal wiki. >> >> To all of you who have contributed to Mbed TLS, who have tried, or who >> are considering it, what difficulties have you encountered? What else >> can we do to make contributing easier? >> >> Best regards, >> >> -- >> Gilles Peskine >> Mbed TLS developer >> >> >> -- >> mbed-tls mailing list >> mbed-tls(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

4 years, 11 months

1
0
0 0

Re: [mbed-tls] Proposed change: no longer credit contributors in the ChangeLog file

by Gilles Peskine

Hello, We're going ahead with this new process. For changes made since the last release (2.24.0 and corresponding updates to long-time support branches), the ChangeLog file will only record user-visible changes, and entries will not be used to credit contributors. We're updating ChangeLog.d/00README.md accordingly (https://github.com/ARMmbed/mbedtls/pull/3726). -- Gilles Peskine Mbed TLS developer On 20/09/2020 23:41, Gilles Peskine via mbed-tls wrote: > Hello, > > The Mbed TLS team is soliciting feedback on a proposed change of our > contributor acknowledgement policy. > > Background: our current policy is to acknowledge all contributors who > are not Arm employees in the ChangeLog files. This is a tradition that > dates back from when the version control history of Mbed TLS (then > PolarSSL) was not public. > > Proposed change: the ChangeLog file will no longer mention who > contributed a patch (“Contributed by …”). A patch will require a > ChangeLog entry only if it makes a user-visible changes, regardless of > who contributed it. We will still credit reporters in the ChangeLog > file, at least for security issues. > > Rationale: the ChangeLog file had a dual purpose: informing users, and > acknowledging contributors. It will now have the single purpose of > informing users. There are better ways of acknowledging contributors > nowadays: the Git history is public, and your contributions are visible > from your GitHub profile. (Note that we don't squash commits, and > attempt to preserve authorship as much as possible when we have to > rebase a patch.) Furthermore, writing a good ChangeLog entry often turns > out to require some back-and-forth, so lessening this requirement will > make it easier to accept contributions and to merge them faster (this is > in fact our primary motivation for the change). > > We are also thinking of creating an acknowledgement page out-of-tree. It > isn't clear yet what its scope would be, but it would include > acknowledging contributions in the form of reviews, which we wish to > encourage. (Please stay tuned for future announcements and discussions > regarding the Mbed TLS review process.) > > Question to potential contributors, or people who have participated in > other open-source projects: do you think that there is any value in > keeping acknowledgements in a file that is distributed with Mbed TLS? Is > there any value in maintaining an exhaustive list of contributors in a > form other than the Git history? > > Best regards, >

4 years, 11 months

1
0
0 0

Information about CI failures on pull requests to Mbed TLS

by Gilles Peskine

Hello, If you've made a pull request to Mbed TLS, you've noticed that some of the continuous integration happens on a private server run by Arm. For jobs that ran since yesterday, if there are failures, you can now see the name of the failed tasks next to “PR-NNN-head TLS Testing” or “PR-NNN-merge TLS Testing”. See https://developer.trustedfirmware.org/w/mbed-tls/testing/ci/#identifying-je… for more details. If this isn't enough, an Arm employee can copy the logs from the server. Please ask in a comment. We hope to post logs automatically (https://github.com/ARMmbed/mbedtls/issues/3633) but I can't give a due date for that. We are planning to move to a public server run by TrustedFirmware, but this can't happen until some time in 2021. Please bear with us in the meantime, and thank you for your contributions. -- Gilles Peskine Mbed TLS developer

4 years, 11 months

1
0
0 0

MbedTLS Webserver

by Thomas Schwarz

Hello everyone, I want to set up a webserver on my ESP32 Dev Module based von MbedTLS. Therefore I view the ssl_server example on github. Now my question: How can I connect the ssl_server to my local WIFI-network. What extra code do I need? And where is the SSID and the password configurable? Thanks for your help! Best regards Thomas Tel.: +49833460134418 MULTIVAC Info Box MULTIVAC Sepp Haggenmüller SE & Co. KG - Bahnhofstr. 4 - D-87787 Wolfertschwenden - Germany Tel.: +49(0)8334/601-0 - Fax: +49(0)8334/601-199 - multivac(a)multivac.de Kommanditgesellschaft Sitz: 87787 Wolfertschwenden Amtsgericht: Memmingen HRA 8040 USt-IdNr.: DE 129082475 - Steuer-Nr.: 138/169/51105 - WEEE-Reg.-Nr.: DE 16576440 Persönlich haftende Gesellschafterin: MULTIVAC Sepp Haggenmüller Verwaltungs SE Sitz: 87787 Wolfertschwenden Amtsgericht: Memmingen HRB 16659 Geschäftsführende Direktoren: Guido Spix, Christian Traumann Verwaltungsratsvorsitzender: Elmar Fischer Bankverbindung: Deutsche Bank Memmingen . IBAN: DE 31 7337 0008 0123 6330 00 . BIC: DEUT DE MM 733 Banner

5 years

1
0
0 0

DTLS server

by Mehdi Karimi

I am using v16 of the mbedTLS library to setup DTLS server. However, I observe that the handshake does not work well and there are several issues starting with the cookie exchange. Do I necessarily have to update to the latest version of mbedTLS? Are there known issues with DTLS server setup using previous versions (as far as I could tell from the ChangeLog). Thanks Mehdi

5 years

1
0
0 0

Re: [mbed-tls] Proposed change: no longer credit contributors in the ChangeLog file

by Frank Bergmann

Hi Gilles, as you said: Git is public. As long as it is kept public there's no reason to "duplicate details". My 2 cents. sincerely, Frank On Sun, Sep 20, 2020 at 09:41:26PM +0000, Gilles Peskine via mbed-tls wrote: > Hello, > > The Mbed TLS team is soliciting feedback on a proposed change of our > contributor acknowledgement policy. > > Background: our current policy is to acknowledge all contributors who > are not Arm employees in the ChangeLog files. This is a tradition that > dates back from when the version control history of Mbed TLS (then > PolarSSL) was not public. > > Proposed change: the ChangeLog file will no longer mention who > contributed a patch (“Contributed by …”). A patch will require a > ChangeLog entry only if it makes a user-visible changes, regardless of > who contributed it. We will still credit reporters in the ChangeLog > file, at least for security issues. > > Rationale: the ChangeLog file had a dual purpose: informing users, and > acknowledging contributors. It will now have the single purpose of > informing users. There are better ways of acknowledging contributors > nowadays: the Git history is public, and your contributions are visible > from your GitHub profile. (Note that we don't squash commits, and > attempt to preserve authorship as much as possible when we have to > rebase a patch.) Furthermore, writing a good ChangeLog entry often turns > out to require some back-and-forth, so lessening this requirement will > make it easier to accept contributions and to merge them faster (this is > in fact our primary motivation for the change). > > We are also thinking of creating an acknowledgement page out-of-tree. It > isn't clear yet what its scope would be, but it would include > acknowledging contributions in the form of reviews, which we wish to > encourage. (Please stay tuned for future announcements and discussions > regarding the Mbed TLS review process.) > > Question to potential contributors, or people who have participated in > other open-source projects: do you think that there is any value in > keeping acknowledgements in a file that is distributed with Mbed TLS? Is > there any value in maintaining an exhaustive list of contributors in a > form other than the Git history? > > Best regards, > > -- > Gilles Peskine > Mbed TLS developer > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls -- Frank Bergmann, Pödinghauser Str. 5, D-32051 Herford, Tel. +49-5221-9249753 SAP Hybris & Linux LPIC-3, E-Mail tx2014(a)tuxad.de, USt-IdNr DE237314606 http://tdyn.de/freel -- Redirect to profile at freelancermap http://www.gulp.de/freiberufler/2HNKY2YHW.html -- Profile at GULP

5 years

1
0
0 0

Re: [mbed-tls] Building a collaborative Mbed TLS community

by Frank Bergmann

Hi Gilles, when I ask in our team to review a PR I usually provide an estimation about it. Of course a time base estimation and not an agile one in values of complexity. ;-) One could also provide an estimation about priority. Maybe these tiny rules may help somewhat. At least it can provide a better overview if you have tons of PRs. sincerely, Frank On Sun, Sep 20, 2020 at 10:27:44PM +0000, Gilles Peskine via mbed-tls wrote: > Hello, > > Historically, Mbed TLS has been maintained by Arm as an open-source > project, accepting external contributions, but with with priorities and > plans mostly driven only by Arm. Since earlier this year, Mbed TLS is an > open governance project under the umbrella of TrustedFirmware, with the > objective of making it a community led project, allowing community to > contribute and collaborate on the design and development of the project. > In practice, however, the project effectively still has some barriers of > entry. We would like to lift these barriers. > > The Mbed TLS team at Arm have already identified some concrete actions, > filed on the Mbed TLS epic board > https://github.com/ARMmbed/mbedtls/projects/2#column-10667107 > under “Facilitating community contributions”. A few more should be up > soon as the result of some internal brainstorming. > > We've also identified some problem areas which we're tracking as > separate topics. > > * Probably the biggest topic: review was and is a bottleneck. We are > working to streamline the review process where possible, without > lowering the quality bar, and to prioritize reviews better over new > work. (Having personally often been on both sides of the coin, I can > confirm that having a pull request sit around for years without getting > reviews is frustrating, and so is seeing all these pull request and not > having the time to review them all.) We would also like to enable, > encourage and value reviews from people who are not project maintainers. > > * We will migrate the CI to a publicly available platform hosted by > TrustedFirmware. However this platform will not be available until 2021. > > * We are working on a new documentation platform, where we'll transfer > both the information available on the current website and information > that is currently recorded in an Arm internal wiki. > > To all of you who have contributed to Mbed TLS, who have tried, or who > are considering it, what difficulties have you encountered? What else > can we do to make contributing easier? > > Best regards, > > -- > Gilles Peskine > Mbed TLS developer > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls -- Frank Bergmann, Pödinghauser Str. 5, D-32051 Herford, Tel. +49-5221-9249753 SAP Hybris & Linux LPIC-3, E-Mail tx2014(a)tuxad.de, USt-IdNr DE237314606 http://tdyn.de/freel -- Redirect to profile at freelancermap http://www.gulp.de/freiberufler/2HNKY2YHW.html -- Profile at GULP

5 years

1
0
0 0

Building a collaborative Mbed TLS community

by Gilles Peskine

Hello, Historically, Mbed TLS has been maintained by Arm as an open-source project, accepting external contributions, but with with priorities and plans mostly driven only by Arm. Since earlier this year, Mbed TLS is an open governance project under the umbrella of TrustedFirmware, with the objective of making it a community led project, allowing community to contribute and collaborate on the design and development of the project. In practice, however, the project effectively still has some barriers of entry. We would like to lift these barriers. The Mbed TLS team at Arm have already identified some concrete actions, filed on the Mbed TLS epic board https://github.com/ARMmbed/mbedtls/projects/2#column-10667107 under “Facilitating community contributions”. A few more should be up soon as the result of some internal brainstorming. We've also identified some problem areas which we're tracking as separate topics. * Probably the biggest topic: review was and is a bottleneck. We are working to streamline the review process where possible, without lowering the quality bar, and to prioritize reviews better over new work. (Having personally often been on both sides of the coin, I can confirm that having a pull request sit around for years without getting reviews is frustrating, and so is seeing all these pull request and not having the time to review them all.) We would also like to enable, encourage and value reviews from people who are not project maintainers. * We will migrate the CI to a publicly available platform hosted by TrustedFirmware. However this platform will not be available until 2021. * We are working on a new documentation platform, where we'll transfer both the information available on the current website and information that is currently recorded in an Arm internal wiki. To all of you who have contributed to Mbed TLS, who have tried, or who are considering it, what difficulties have you encountered? What else can we do to make contributing easier? Best regards, -- Gilles Peskine Mbed TLS developer

5 years

1
0
0 0

Proposed change: no longer credit contributors in the ChangeLog file

by Gilles Peskine

Hello, The Mbed TLS team is soliciting feedback on a proposed change of our contributor acknowledgement policy. Background: our current policy is to acknowledge all contributors who are not Arm employees in the ChangeLog files. This is a tradition that dates back from when the version control history of Mbed TLS (then PolarSSL) was not public. Proposed change: the ChangeLog file will no longer mention who contributed a patch (“Contributed by …”). A patch will require a ChangeLog entry only if it makes a user-visible changes, regardless of who contributed it. We will still credit reporters in the ChangeLog file, at least for security issues. Rationale: the ChangeLog file had a dual purpose: informing users, and acknowledging contributors. It will now have the single purpose of informing users. There are better ways of acknowledging contributors nowadays: the Git history is public, and your contributions are visible from your GitHub profile. (Note that we don't squash commits, and attempt to preserve authorship as much as possible when we have to rebase a patch.) Furthermore, writing a good ChangeLog entry often turns out to require some back-and-forth, so lessening this requirement will make it easier to accept contributions and to merge them faster (this is in fact our primary motivation for the change). We are also thinking of creating an acknowledgement page out-of-tree. It isn't clear yet what its scope would be, but it would include acknowledging contributions in the form of reviews, which we wish to encourage. (Please stay tuned for future announcements and discussions regarding the Mbed TLS review process.) Question to potential contributors, or people who have participated in other open-source projects: do you think that there is any value in keeping acknowledgements in a file that is distributed with Mbed TLS? Is there any value in maintaining an exhaustive list of contributors in a form other than the Git history? Best regards, -- Gilles Peskine Mbed TLS developer

5 years

1
0
0 0

Parse RSA keyfile-Error

by youssouf sokhona

Good morning to all, I am currently trying to perform RSA encryption, so I am using a file containing a public key (generated by OpenSSL) to do this. So at the beginning I use the "mbedtls_pk_parse_keyfile" function to read it, as you can see on the image below. Unfortunately, I find the following error : ERROR 3E00 : Read/write of file failed. Do someone have an idea of why I have this error ? Or should I change my way to read this file ? Thanks a lot, have a nice Weekend [cid:image002.png@01D68839.7B058100]

5 years

1
0
0 0

Re: [mbed-tls] Query related to ARM - MbedTLS

by Manu Abraham

Hi, Unrelated comment from my side, adding on to Manuel's comment: It appears that ST supplies a binary blob which does make use of their hardware crypto accelerator. https://www.st.com/en/embedded-software/x-cube-cryptolib.html Cheers, Manu On Wed, Sep 9, 2020 at 1:21 PM Manuel Pegourie-Gonnard via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> wrote: > > Hi, > > On those CPUs, the AES implementation in Mbed TLS is pure C, it doesn't use any hand-written assembly. The only platforms where it does so so far are x86-64 (to take advantage of the AES-NI extension if available), and some Via CPUs (x86) that have AES acceleration as well. > > Regards, > Manuel. > ________________________________ > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Areeb Asad via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> > Sent: 09 September 2020 08:32 > To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> > Subject: [mbed-tls] Query related to ARM - MbedTLS > > Hi, > > I hope you are doing well. I am using the mbedTLS AES library in my projects, part of my master thesis at Uppsala University. > > I would like to know whether the mbedTLS AES library uses any assemble specific code for operations? I am using this library on Cortex-M23 and Cortex M0+. > > Looking forward to hearing from you. > > > Best regards, > Hafiz Areeb Asad > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

5 years

2
1
0 0

Re: [mbed-tls] Query related to ARM - MbedTLS

by Manuel Pegourie-Gonnard

Hi, On those CPUs, the AES implementation in Mbed TLS is pure C, it doesn't use any hand-written assembly. The only platforms where it does so so far are x86-64 (to take advantage of the AES-NI extension if available), and some Via CPUs (x86) that have AES acceleration as well. Regards, Manuel. ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Areeb Asad via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 09 September 2020 08:32 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Query related to ARM - MbedTLS Hi, I hope you are doing well. I am using the mbedTLS AES library in my projects, part of my master thesis at Uppsala University. I would like to know whether the mbedTLS AES library uses any assemble specific code for operations? I am using this library on Cortex-M23 and Cortex M0+. Looking forward to hearing from you. Best regards, Hafiz Areeb Asad

5 years

1
0
0 0

Query related to ARM - MbedTLS

by Areeb Asad

Hi, I hope you are doing well. I am using the mbedTLS AES library in my projects, part of my master thesis at Uppsala University. I would like to know whether the mbedTLS AES library uses any assemble specific code for operations? I am using this library on Cortex-M23 and Cortex M0+. Looking forward to hearing from you. Best regards, Hafiz Areeb Asad

5 years

1
0
0 0

A new configuration mechanism for PSA crypto in Mbed TLS

by Gilles Peskine

Hello, As you may be aware, there is work in progress to implement support for hardware drivers in Mbed TLS when using the PSA API. These are direct calls from the PSA frontend layer to driver code, without going through mbedtls_xxx APIs and the ALT implementations. The specifications are the psa-driver-*.md files in https://github.com/ARMmbed/mbedtls/tree/development/docs/proposed and you can watch the work in progress in the “Unified driver interface: API design and prototype” epic https://github.com/ARMmbed/mbedtls/projects/2#column-8543266 . When an algorithm is implemented in hardware, in most cases, it is unnecessary to include a software implementation, and it should be possible to exclude the software implementation from the build to keep the code size down. Unfortunately the current Mbed TLS configuration mechanism does not support this, because it does not distinguish “I want AES” from “I want mbedtls_aes_xxx”. So we need new compile-time options to convey “I want PSA_KEY_TYPE_AES in my application but I don't care whether it's done in hardware or mbedtls_aes_xxx”. We are going to implement a configuration mechanism to select which cryptographic algorithms are included in the PSA interface in a build of Mbed TLS. It will rely on #define statements, like the existing config.h, but with different naming conventions for PSA. You can see the specification proposal at https://github.com/ARMmbed/mbedtls/pull/3628 . Feedback is welcome. We're likely to merge this pull request soon, but even after it's merged I'll keep watching comments, or you can post feedback on the mailing list, or raise an issue on GitHub if you have a specific feature request. A major difference between the current MBEDTLS_xxx_C configuration and the new PSA_WANT_xxx configuration is that PSA_WANT_xxx is additive: if PSA_WANT_xxx depends on some other feature, enabling PSA_WANT_xxx will automatically enable that feature in most cases (the exception being when there's more than one way to enable the dependent feature, e.g. when a hash algorithm is needed but it doesn't matter which hash). This is in contrast with the current strict mechanism where enabling MBEDTLS_xxx_C is an error if it depends on some other feature that isn't enabled. We haven't decided yet, but we're thinking of changing to an additive mechanism for the whole Mbed TLS configuration in Mbed TLS 3.0. If you want to watch the implementation work in progress, it will be under the “Driver Interface: Removing unused code” epic https://github.com/ARMmbed/mbedtls/projects/2#column-9449707 . Note that the #define-based mechanism is somewhat experimental and we won't commit yet about its long-term stability in Mbed TLS. It is likely to be complemented by a JSON-based mechanism in the future. This JSON mechanism would be similar to the proposed mechanism for drivers and would allow finer granularity (for example, RSA verification without RSA signature). Arm is considering standardizing the (as yet non-existent) JSON mechanism as a PSA specification. Best regards, -- Gilles Peskine Mbed TLS developer (and PSA crypto architect)

5 years

1
0
0 0

How can I encrypt RSA private key with AES?

by Shariful Alam

Hi, I hope everyone is doing well. I am a beginner on mbedtls and cryptography. I hope you will understand if there is a lack of understanding or a rookie mistake from my part. So, My goal is to do a key-encryption key. I have an *RSA* private key file "*private.pem*" generated by OpenSSL. I want to encrypt the content of this "private.pem" with *AES* *encryption* and followed by *AES decryption *on the encrypted data. To do that, I read the "private.pem" file into a buffer and perform AES encryption. The problem is when I perform the AES decryption operation I get something else instead of the original "private.pem" data. I have a working example of AES encryption/decryption working on plaintext perfectly. So, I guess there is a flaw in my understanding of encryption/decryption of byte64 encoded string. Can someone please suggests me how can I encrypt RSA private key with AES? Thanks, Shariful

5 years

1
0
0 0

[Mbed-tls-announce] Latest release link on github

by Janos Follath via Mbed-tls-announce

Mbed TLS version 2.24.0, 2.16.8 and 2.7.17 have been released recently. Version 2.7.17 is incorrectly marked as the latest release by github. Since this happens automatically based on the commit creation dates, this can’t be fixed until the next release. We have extended the release notes of 2.7.17 to warn about this and changed the download links on the website. We would like to confirm that version 2.24.0 is the latest release and the other two are the patch releases for the 2.16 and 2.7 long term support branches. My apologies for the inconvenience and thank you for your support! Best regards, Janos (On behalf of the Mbed TLS team) -- 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] Mbed TLS: Security Advisory and Release of Mbed TLS 2.24.0, 2.16.8 and 2.7.17

by Janos Follath via Mbed-tls-announce

Mbed TLS Security Advisories have been issued to accompany the release of Mbed TLS versions 2.24.0, 2.16.8 and 2.7.17, 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 (https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.24.0, https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.16.8, https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.7.17) and in the 2020-07 security advisories (https://tls.mbed.org/tech-updates/security-advisories) 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

Re: [mbed-tls] Print long MPI

by Gilles Peskine

Hello, 4096 bytes is a lot larger than a typical public key. 4096 *bits* is common for an RSA key. Are you sure you're using the correct units? By default the library doesn't support the creation of MPI that are larger than 1024 bytes. This is a configuration option (MBEDTLS_MPI_MAX_SIZE), although it's uncommon to change it (a larger value is hardly ever necessary, and a smaller value won't save memory except in RSA which needs at least 512 bytes for 4096-bit keys). However mbedtls_mpi_write_file itself doesn't have any size limit. Best regards, -- Gilles Peskine Mbed TLS developer On 27/08/2020 13:27, youssouf sokhona via mbed-tls wrote: > > Hello everyone, I think you are fine during this crisis. > > > > I am working now with mbedtls modulee, and I wanted to print a > function « mbedtls_mpi_write_file » to print the value of an MPI. This > function works with common values. > > > > However, when I want to print an MPI which is very long (about 4096 > bytes, a public key), it doesn’t work. Someone knows how to solve this > problem ? > > > > Thanks a lot > > > > Best regards, YS > > > >

5 years

1
0
0 0

Print long MPI

by youssouf sokhona

Hello everyone, I think you are fine during this crisis. I am working now with mbedtls modulee, and I wanted to print a function « mbedtls_mpi_write_file » to print the value of an MPI. This function works with common values. However, when I want to print an MPI which is very long (about 4096 bytes, a public key), it doesn’t work. Someone knows how to solve this problem ? Thanks a lot Best regards, YS

5 years

1
0
0 0

Re: [mbed-tls] mbedtls handshake failed

by Hannes Tschofenig

Hi Manu, It looks like you made a mistake on the client side configuring the certificate/private key. The client does not send the certificate and that corresponds to the error message on the server-side ("peer did not return a certificate"). Ciao Hannes -----Original Message----- From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of Manu Abraham via mbed-tls Sent: Tuesday, August 25, 2020 5:20 PM To: mbed-tls(a)lists.trustedfirmware.org Subject: [mbed-tls] mbedtls handshake failed Greetings, I am trying to connect from a STM32H7 MCU to a mosquitto peer, Can someone please help me to fix this issue that I have ? I have used the DES3 cipher to create the keys .. openssl genrsa -des3 -out test_ca.key 2048 .. Fiddled quite a bit with buffers, stack, heap and mbedtls config, eventually the communication appears to be working, but the handshake appears to fail. At the client MCU side, I see the mbedtls_ssl_handshake failed message with a return value of 0x7780 Additionally, I do see this message too: ssl_tls.c:5169: got an alert message, type: [2:40] ssl_tls.c:5177: is a fatal alert message (msg 40) But unfortunately, I am unable to make out what the error message means. At the peer, this is what i do see: 1598367067: New connection from 192.168.1.33 on port 8883. 1598367074: OpenSSL Error: error:1417C0C7:SSL routines:tls_process_client_certif icate:peer did not return a certificate 1598367074: Socket error on client <unknown>, disconnecting. 1598368366: mosquitto version 1.6.7 terminating Someone, Please help ! Thanks, Manu ssl_tls.c:8084: => handshake ssl_cli.c:3510: client state: 0 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_cli.c:3510: client state: 1 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_cli.c:0774: => write client hello ssl_cli.c:0811: client hello, max version: [3:3] ssl_cli.c:0821: dumping 'client hello, random bytes' (32 bytes) ssl_cli.c:0821: 0000: 3c ce d6 f9 48 cc 7d 5d 77 24 74 f2 1d 9f 8b aa <...H.}]w$t..... ssl_cli.c:0821: 0010: 4b 0c 20 64 d3 22 d0 ee 5e 3b 83 24 a7 01 ec d9 K. d."..^;.$.... ssl_cli.c:0874: client hello, session id len.: 0 ssl_cli.c:0875: dumping 'client hello, session id' (0 bytes) ssl_cli.c:0921: client hello, add ciphersuite: c02c ssl_cli.c:0921: client hello, add ciphersuite: c02b ssl_cli.c:0921: client hello, add ciphersuite: c030 ssl_cli.c:0921: client hello, add ciphersuite: c02f ssl_cli.c:0934: client hello, got 4 ciphersuites (excluding SCSVs) ssl_cli.c:0943: adding EMPTY_RENEGOTIATION_INFO_SCSV ssl_cli.c:0992: client hello, compress len.: 1 ssl_cli.c:0993: client hello, compress alg.: 0 ssl_cli.c:0186: client hello, adding signature_algorithms extension ssl_cli.c:0271: client hello, adding supported_elliptic_curves extension ssl_cli.c:0336: client hello, adding supported_point_formats extension ssl_cli.c:1070: client hello, total extension length: 38 ssl_tls.c:3184: => write handshake message ssl_tls.c:3343: => write record ssl_tls.c:3420: output record: msgtype = 22, version = [3:3], msglen = 93 ssl_tls.c:3425: dumping 'output record sent to network' (98 bytes) ssl_tls.c:3425: 0000: 16 03 03 00 5d 01 00 00 59 03 03 3c ce d6 f9 48 ....]...Y..<...H .. .. .. .. .. .. .. .. .. .. ssl_tls.c:3425: 0050: 03 01 00 0a 00 06 00 04 00 18 00 17 00 0b 00 02 ................ ssl_tls.c:3425: 0060: 01 00 .. ssl_tls.c:2755: => flush output ssl_tls.c:2773: message length: 98, out_left: 98 ssl_tls.c:2779: ssl->f_send() returned 98 (-0xffffff9e) ssl_tls.c:2807: <= flush output ssl_tls.c:3476: <= write record ssl_tls.c:3320: <= write handshake message ssl_cli.c:1106: <= write client hello ssl_cli.c:3510: client state: 2 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_cli.c:1499: => parse server hello ssl_tls.c:4311: => read record ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 0, nb_want: 5 ssl_tls.c:2720: in_left: 0, nb_want: 5 ssl_tls.c:8094: <= handshake ssl_tls.c:8084: => handshake ssl_cli.c:3510: client state: 2 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_cli.c:1499: => parse server hello ssl_tls.c:4311: => read record ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 0, nb_want: 5 ssl_tls.c:2720: in_left: 0, nb_want: 5 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_tls.c:2742: <= fetch input ssl_tls.c:4047: dumping 'input record header' (5 bytes) ssl_tls.c:4047: 0000: 16 03 03 00 59 ....Y ssl_tls.c:4053: input record: msgtype = 22, version = [3:3], msglen = 89 ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 5, nb_want: 94 ssl_tls.c:2720: in_left: 5, nb_want: 94 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 89 (-0xffffffa7) ssl_tls.c:2742: <= fetch input ssl_tls.c:4232: dumping 'input record from network' (94 bytes) ssl_tls.c:4232: 0000: 16 03 03 00 59 02 00 00 55 03 03 d1 64 6e e1 0c ....Y...U...dn.. .. .. .. .. .. .. .. .. .. .. ssl_tls.c:4232: 0050: 0d ff 01 00 01 00 00 0b 00 04 03 00 01 02 .............. ssl_tls.c:3624: handshake message: msglen = 89, type = 2, hslen = 89 ssl_tls.c:4385: <= read record ssl_cli.c:1579: dumping 'server hello, version' (2 bytes) ssl_cli.c:1579: 0000: 03 03 .. ssl_cli.c:1600: server hello, current time: 3513020129 ssl_cli.c:1610: dumping 'server hello, random bytes' (32 bytes) ssl_cli.c:1610: 0000: d1 64 6e e1 0c 1f ac 75 77 eb d7 02 24 dd a7 da .dn....uw...$... ssl_cli.c:1610: 0010: 48 f3 50 43 34 10 d8 d9 44 4f 57 4e 47 52 44 01 H.PC4...DOWNGRD. ssl_cli.c:1690: server hello, session id len.: 32 ssl_cli.c:1691: dumping 'server hello, session id' (32 bytes) ssl_cli.c:1691: 0000: 90 8f cc f8 31 63 81 ae aa bf a9 b9 61 1e 78 f6 ....1c......a.x. ssl_cli.c:1691: 0010: 79 b8 26 66 51 99 f4 50 45 d4 21 9b 22 24 4c 63 y.&fQ..PE.!."$Lc ssl_cli.c:1728: no session has been resumed ssl_cli.c:1731: server hello, chosen ciphersuite: c030 ssl_cli.c:1732: server hello, compress alg.: 0 ssl_cli.c:1764: server hello, chosen ciphersuite: TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 ssl_cli.c:1789: server hello, total extension length: 13 ssl_cli.c:1809: found renegotiation extension ssl_cli.c:1888: found supported_point_formats extension ssl_cli.c:1292: point format selected: 0 ssl_cli.c:1978: <= parse server hello ssl_cli.c:3510: client state: 3 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_tls.c:5655: => parse certificate ssl_tls.c:4311: => read record ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 0, nb_want: 5 ssl_tls.c:2720: in_left: 0, nb_want: 5 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_tls.c:2742: <= fetch input ssl_tls.c:4047: dumping 'input record header' (5 bytes) ssl_tls.c:4047: 0000: 16 03 03 07 80 ..... ssl_tls.c:4053: input record: msgtype = 22, version = [3:3], msglen = 1920 ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 5, nb_want: 1925 ssl_tls.c:2720: in_left: 5, nb_want: 1925 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 1361 (-0xfffffaaf) ssl_tls.c:2720: in_left: 1366, nb_want: 1925 ssl_tls.c:8094: <= handshake ssl_tls.c:8084: => handshake ssl_cli.c:3510: client state: 3 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_tls.c:5655: => parse certificate ssl_tls.c:4311: => read record ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 1366, nb_want: 5 ssl_tls.c:2742: <= fetch input ssl_tls.c:4047: dumping 'input record header' (5 bytes) ssl_tls.c:4047: 0000: 16 03 03 07 80 ..... ssl_tls.c:4053: input record: msgtype = 22, version = [3:3], msglen = 1920 ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 1366, nb_want: 1925 ssl_tls.c:2720: in_left: 1366, nb_want: 1925 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 559 (-0xfffffdd1) ssl_tls.c:2742: <= fetch input ssl_tls.c:4232: dumping 'input record from network' (1925 bytes) ssl_tls.c:4232: 0000: 16 03 03 07 80 0b 00 07 7c 00 07 79 00 03 90 30 ........|..y...0 .. .. .. .. .. .. .. .. .. .. ssl_tls.c:4232: 0770: df d8 30 17 65 70 2a 02 54 9a 4c cf b1 51 04 25 ..0.ep*.T.L..Q.% ssl_tls.c:4232: 0780: 83 2c ab dd 46 .,..F ssl_tls.c:3624: handshake message: msglen = 1920, type = 11, hslen = 1920 ssl_tls.c:4385: <= read record ssl_tls.c:5606: peer certificate #1: ssl_tls.c:5606: cert. version : 1 ssl_tls.c:5606: serial number : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ssl_tls.c:5606: issuer name : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ssl_tls.c:5606: subject name : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ssl_tls.c:5606: issued on : 2020-08-15 09:12:30 ssl_tls.c:5606: expires on : 2030-08-13 09:12:30 ssl_tls.c:5606: signed using : RSA with SHA-256 ssl_tls.c:5606: RSA key size : 2048 bits ssl_tls.c:5606: value of 'crt->rsa.N' (2048 bits) is: ssl_tls.c:5606: c9 93 0d f4 7b 93 95 8f 4d ec bb 77 46 82 48 6d .. .. .. .. .. .. .. .. .. .. ssl_tls.c:5606: 0f 00 85 cf c9 40 b0 f8 b2 df 1b 75 bd 2e 95 43 ssl_tls.c:5606: value of 'crt->rsa.E' (17 bits) is: ssl_tls.c:5606: 01 00 01 ssl_tls.c:5606: peer certificate #2: ssl_tls.c:5606: cert. version : 3 ssl_tls.c:5606: serial number : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ssl_tls.c:5606: issuer name : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ssl_tls.c:5606: subject name : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ssl_tls.c:5606: issued on : 2020-08-15 08:54:30 ssl_tls.c:5606: expires on : 2030-08-13 08:54:30 ssl_tls.c:5606: signed using : RSA with SHA-256 ssl_tls.c:5606: RSA key size : 2048 bits ssl_tls.c:5606: basic constraints : CA=true ssl_tls.c:5606: value of 'crt->rsa.N' (2048 bits) is: ssl_tls.c:5606: c4 e2 4b 37 45 4a 36 e5 b0 14 f7 fa 76 1d c4 29 .. .. .. .. .. .. .. .. .. .. ssl_tls.c:5606: 43 7c 19 f2 b0 dc ef 69 cf 13 c4 cb fa 80 92 f1 ssl_tls.c:5606: value of 'crt->rsa.E' (17 bits) is: ssl_tls.c:5606: 01 00 01 ssl_tls.c:5856: Certificate verification flags clear ssl_tls.c:5863: <= parse certificate ssl_cli.c:3510: client state: 4 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_cli.c:2336: => parse server key exchange ssl_tls.c:4311: => read record ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 0, nb_want: 5 ssl_tls.c:2720: in_left: 0, nb_want: 5 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_tls.c:2742: <= fetch input ssl_tls.c:4047: dumping 'input record header' (5 bytes) ssl_tls.c:4047: 0000: 16 03 03 01 4d ....M ssl_tls.c:4053: input record: msgtype = 22, version = [3:3], msglen = 333 ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 5, nb_want: 338 ssl_tls.c:2720: in_left: 5, nb_want: 338 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 333 (-0xfffffeb3) ssl_tls.c:2742: <= fetch input ssl_tls.c:4232: dumping 'input record from network' (338 bytes) ssl_tls.c:4232: 0000: 16 03 03 01 4d 0c 00 01 49 03 00 17 41 04 6e 49 ....M...I...A.nI .. .. .. .. .. .. .. .. .. .. ssl_tls.c:4232: 0140: c4 4b 34 2f 83 5f 98 17 39 5e 6e 4d 56 f4 c1 4c .K4/._..9^nMV..L ssl_tls.c:4232: 0150: 39 0f 9. ssl_tls.c:3624: handshake message: msglen = 333, type = 12, hslen = 333 ssl_tls.c:4385: <= read record ssl_cli.c:2424: dumping 'server key exchange' (329 bytes) ssl_cli.c:2424: 0000: 03 00 17 41 04 6e 49 4b 1c 4e 7b 2b ff c3 c9 9b ...A.nIK.N{+.... .. .. .. .. .. .. .. .. .. .. ssl_cli.c:2424: 0130: d9 33 d2 6e a7 05 ca c4 4b 34 2f 83 5f 98 17 39 .3.n....K4/._..9 ssl_cli.c:2424: 0140: 5e 6e 4d 56 f4 c1 4c 39 0f ^nMV..L9. ssl_cli.c:2044: ECDH curve: secp256r1 ssl_cli.c:2054: value of 'ECDH: Qp(X)' (255 bits) is: ssl_cli.c:2054: 6e 49 4b 1c 4e 7b 2b ff c3 c9 9b 81 29 4d a8 92 ssl_cli.c:2054: af c2 77 2b 3b c6 26 ba d4 c7 a2 2d 83 78 e3 54 ssl_cli.c:2054: value of 'ECDH: Qp(Y)' (256 bits) is: ssl_cli.c:2054: d6 91 fe 18 70 fb bc b6 c7 aa 67 1c 08 8b 4d 58 ssl_cli.c:2054: a4 70 59 97 90 23 8d 4b b6 24 4e 1a 7e 13 f2 d1 ssl_cli.c:2278: Server used SignatureAlgorithm 1 ssl_cli.c:2279: Server used HashAlgorithm 4 ssl_cli.c:2580: dumping 'signature' (256 bytes) ssl_cli.c:2580: 0000: b3 88 25 7f 3f 6b cf 7e 03 de 11 5b 4f 47 e9 6e ..%.?k.~...[OG.n .. .. .. .. .. .. .. .. .. .. ssl_cli.c:2580: 00f0: 34 2f 83 5f 98 17 39 5e 6e 4d 56 f4 c1 4c 39 0f 4/._..9^nMV..L9. ssl_cli.c:2616: dumping 'parameters hash' (32 bytes) ssl_cli.c:2616: 0000: bc 4e 7e a6 a6 02 76 66 2c da 19 6c ea 5a aa df .N~...vf,..l.Z.. ssl_cli.c:2616: 0010: ae 3a ff e9 34 c6 d1 72 98 b4 f3 7d b8 71 11 65 .:..4..r...}.q.e ssl_cli.c:2664: <= parse server key exchange ssl_cli.c:3510: client state: 5 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_cli.c:2697: => parse certificate request ssl_tls.c:4311: => read record ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 0, nb_want: 5 ssl_tls.c:2720: in_left: 0, nb_want: 5 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_tls.c:2742: <= fetch input ssl_tls.c:4047: dumping 'input record header' (5 bytes) ssl_tls.c:4047: 0000: 16 03 03 00 3a ....: ssl_tls.c:4053: input record: msgtype = 22, version = [3:3], msglen = 58 ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 5, nb_want: 63 ssl_tls.c:2720: in_left: 5, nb_want: 63 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 58 (-0xffffffc6) ssl_tls.c:2742: <= fetch input ssl_tls.c:4232: dumping 'input record from network' (63 bytes) ssl_tls.c:4232: 0000: 16 03 03 00 3a 0d 00 00 36 03 01 02 40 00 2e 04 ....:...6...@... .. .. .. .. .. .. .. .. .. .. ssl_tls.c:4232: 0030: 01 02 01 03 02 02 02 04 02 05 02 06 02 00 00 ............... ssl_tls.c:3624: handshake message: msglen = 58, type = 13, hslen = 58 ssl_tls.c:4385: <= read record ssl_cli.c:2723: got a certificate request ssl_cli.c:2823: Supported Signature Algorithm found: 4,3 ssl_cli.c:2823: Supported Signature Algorithm found: 5,3 ssl_cli.c:2823: Supported Signature Algorithm found: 6,3 ssl_cli.c:2823: Supported Signature Algorithm found: 8,7 ssl_cli.c:2823: Supported Signature Algorithm found: 8,8 ssl_cli.c:2823: Supported Signature Algorithm found: 8,9 ssl_cli.c:2823: Supported Signature Algorithm found: 8,10 ssl_cli.c:2823: Supported Signature Algorithm found: 8,11 ssl_cli.c:2823: Supported Signature Algorithm found: 8,4 ssl_cli.c:2823: Supported Signature Algorithm found: 8,5 ssl_cli.c:2823: Supported Signature Algorithm found: 8,6 ssl_cli.c:2823: Supported Signature Algorithm found: 4,1 ssl_cli.c:2823: Supported Signature Algorithm found: 5,1 ssl_cli.c:2823: Supported Signature Algorithm found: 6,1 ssl_cli.c:2823: Supported Signature Algorithm found: 3,3 ssl_cli.c:2823: Supported Signature Algorithm found: 2,3 ssl_cli.c:2823: Supported Signature Algorithm found: 3,1 ssl_cli.c:2823: Supported Signature Algorithm found: 2,1 ssl_cli.c:2823: Supported Signature Algorithm found: 3,2 ssl_cli.c:2823: Supported Signature Algorithm found: 2,2 ssl_cli.c:2823: Supported Signature Algorithm found: 4,2 ssl_cli.c:2823: Supported Signature Algorithm found: 5,2 ssl_cli.c:2823: Supported Signature Algorithm found: 6,2 ssl_cli.c:2846: <= parse certificate request ssl_cli.c:3510: client state: 6 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_cli.c:2856: => parse server hello done ssl_tls.c:4311: => read record ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 0, nb_want: 5 ssl_tls.c:2720: in_left: 0, nb_want: 5 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_tls.c:2742: <= fetch input ssl_tls.c:4047: dumping 'input record header' (5 bytes) ssl_tls.c:4047: 0000: 16 03 03 00 04 ..... ssl_tls.c:4053: input record: msgtype = 22, version = [3:3], msglen = 4 ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 5, nb_want: 9 ssl_tls.c:2720: in_left: 5, nb_want: 9 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 4 (-0xfffffffc) ssl_tls.c:2742: <= fetch input ssl_tls.c:4232: dumping 'input record from network' (9 bytes) ssl_tls.c:4232: 0000: 16 03 03 00 04 0e 00 00 00 ......... ssl_tls.c:3624: handshake message: msglen = 4, type = 14, hslen = 4 ssl_tls.c:4385: <= read record ssl_cli.c:2886: <= parse server hello done ssl_cli.c:3510: client state: 7 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_tls.c:5329: => write certificate ssl_tls.c:3184: => write handshake message ssl_tls.c:3343: => write record ssl_tls.c:3420: output record: msgtype = 22, version = [3:3], msglen = 7 ssl_tls.c:3425: dumping 'output record sent to network' (12 bytes) ssl_tls.c:3425: 0000: 16 03 03 00 07 0b 00 00 03 00 00 00 ............ ssl_tls.c:2755: => flush output ssl_tls.c:2773: message length: 12, out_left: 12 ssl_tls.c:2779: ssl->f_send() returned 12 (-0xfffffff4) ssl_tls.c:2807: <= flush output ssl_tls.c:3476: <= write record ssl_tls.c:3320: <= write handshake message ssl_tls.c:5433: <= write certificate ssl_cli.c:3510: client state: 8 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_cli.c:2898: => write client key exchange ssl_cli.c:2977: value of 'ECDH: Q(X)' (256 bits) is: ssl_cli.c:2977: e8 dd a7 e4 3d f4 43 c0 1f 42 67 99 2f 1b bd a8 ssl_cli.c:2977: 10 03 3d 45 5f 3b f8 46 ff d6 b8 65 3c 13 6a 3b ssl_cli.c:2977: value of 'ECDH: Q(Y)' (256 bits) is: ssl_cli.c:2977: 9a f8 36 4d 19 01 01 02 d6 bb 51 4a 1d ec f1 7f ssl_cli.c:2977: 28 70 31 95 65 62 1e d6 8d 97 b6 cc 3f b4 9a 8e ssl_cli.c:3005: value of 'ECDH: z' (253 bits) is: ssl_cli.c:3005: 14 06 75 26 fd 2c 2e 3f ad cf 0c fe 6b df 66 7c ssl_cli.c:3005: c2 b7 54 7e 62 ea 4e 0b 93 d0 62 22 15 e6 db 43 ssl_tls.c:3184: => write handshake message ssl_tls.c:3343: => write record ssl_tls.c:3420: output record: msgtype = 22, version = [3:3], msglen = 70 ssl_tls.c:3425: dumping 'output record sent to network' (75 bytes) ssl_tls.c:3425: 0000: 16 03 03 00 46 10 00 00 42 41 04 e8 dd a7 e4 3d ....F...BA.....= .. .. .. .. .. .. .. .. .. .. ssl_tls.c:3425: 0040: 62 1e d6 8d 97 b6 cc 3f b4 9a 8e b......?... ssl_tls.c:2755: => flush output ssl_tls.c:2773: message length: 75, out_left: 75 ssl_tls.c:2779: ssl->f_send() returned 75 (-0xffffffb5) ssl_tls.c:2807: <= flush output ssl_tls.c:3476: <= write record ssl_tls.c:3320: <= write handshake message ssl_cli.c:3172: <= write client key exchange ssl_cli.c:3510: client state: 9 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_cli.c:3224: => write certificate verify ssl_tls.c:0628: => derive keys ssl_tls.c:0705: dumping 'premaster secret' (32 bytes) ssl_tls.c:0705: 0000: 14 06 75 26 fd 2c 2e 3f ad cf 0c fe 6b df 66 7c ..u&.,.?....k.f| ssl_tls.c:0705: 0010: c2 b7 54 7e 62 ea 4e 0b 93 d0 62 22 15 e6 db 43 ..T~b.N...b"...C ssl_tls.c:0794: ciphersuite = TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 ssl_tls.c:0796: dumping 'master secret' (48 bytes) ssl_tls.c:0796: 0000: 5a 15 26 c7 71 73 1a 2e 8c 0d 0e 55 d7 6f 7f b5 Z.&.qs.....U.o.. .. .. .. .. .. .. .. .. .. .. ssl_tls.c:0796: 0020: 24 bf 3f 51 ca e9 7b 66 99 61 cf a9 fb 61 e2 2f $.?Q..{f.a...a./ ssl_tls.c:0797: dumping 'random bytes' (64 bytes) ssl_tls.c:0797: 0000: d1 64 6e e1 0c 1f ac 75 77 eb d7 02 24 dd a7 da .dn....uw...$... .. .. .. .. .. .. .. .. .. .. ssl_tls.c:0797: 0030: 4b 0c 20 64 d3 22 d0 ee 5e 3b 83 24 a7 01 ec d9 K. d."..^;.$.... ssl_tls.c:0798: dumping 'key block' (256 bytes) ssl_tls.c:0798: 0000: 5d b4 7a 60 2e 5b f8 fb 8f e4 75 22 9a b4 8c 04 ].z`.[....u".... .. .. .. .. .. .. .. .. .. .. ssl_tls.c:0798: 00f0: 53 af 8e 78 d0 03 ca 26 b7 43 ee c6 aa 0e 71 88 S..x...&.C....q. ssl_tls.c:0919: keylen: 32, minlen: 24, ivlen: 12, maclen: 0 ssl_tls.c:1116: <= derive keys ssl_cli.c:3253: <= skip write certificate verify ssl_cli.c:3510: client state: 10 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_tls.c:5879: => write change cipher spec ssl_tls.c:3184: => write handshake message ssl_tls.c:3343: => write record ssl_tls.c:3420: output record: msgtype = 20, version = [3:3], msglen = 1 ssl_tls.c:3425: dumping 'output record sent to network' (6 bytes) ssl_tls.c:3425: 0000: 14 03 03 00 01 01 ...... ssl_tls.c:2755: => flush output ssl_tls.c:2773: message length: 6, out_left: 6 ssl_tls.c:2779: ssl->f_send() returned 6 (-0xfffffffa) ssl_tls.c:2807: <= flush output ssl_tls.c:3476: <= write record ssl_tls.c:3320: <= write handshake message ssl_tls.c:5893: <= write change cipher spec ssl_cli.c:3510: client state: 11 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_tls.c:6398: => write finished ssl_tls.c:6272: => calc finished tls sha384 ssl_tls.c:6283: dumping 'finished sha512 state' (64 bytes) ssl_tls.c:6283: 0000: e2 6c 37 56 90 66 0a f8 1c c7 26 d0 49 a9 87 52 .l7V.f....&.I..R .. .. .. .. .. .. .. .. .. .. ssl_tls.c:6283: 0030: 85 b3 04 84 77 e5 02 b0 53 d7 31 b4 c4 e4 08 c0 ....w...S.1..... ssl_tls.c:6296: dumping 'calc finished result' (12 bytes) ssl_tls.c:6296: 0000: c4 6a dd c2 9b a7 75 28 ff 53 5a 3f .j....u(.SZ? ssl_tls.c:6302: <= calc finished ssl_tls.c:6443: switching to new transform spec for outbound data ssl_tls.c:3184: => write handshake message ssl_tls.c:3343: => write record ssl_tls.c:1445: => encrypt buf ssl_tls.c:1455: dumping 'before encrypt: output payload' (16 bytes) ssl_tls.c:1455: 0000: 14 00 00 0c c4 6a dd c2 9b a7 75 28 ff 53 5a 3f .....j....u(.SZ? ssl_tls.c:1574: dumping 'additional data for AEAD' (13 bytes) ssl_tls.c:1574: 0000: 00 00 00 00 00 00 00 00 16 03 03 00 10 ............. ssl_tls.c:1604: dumping 'IV used (internal)' (12 bytes) ssl_tls.c:1604: 0000: a0 9a 1f cb 00 00 00 00 00 00 00 00 ............ ssl_tls.c:1606: dumping 'IV used (transmitted)' (8 bytes) ssl_tls.c:1606: 0000: 00 00 00 00 00 00 00 00 ........ ssl_tls.c:1616: before encrypt: msglen = 24, including 0 bytes of padding ssl_tls.c:1643: dumping 'after encrypt: tag' (16 bytes) ssl_tls.c:1643: 0000: e7 10 1d 99 f6 b6 a5 40 de e8 c0 d5 ec 48 de 6e .......@.....H.n ssl_tls.c:1781: <= encrypt buf ssl_tls.c:3420: output record: msgtype = 22, version = [3:3], msglen = 40 ssl_tls.c:3425: dumping 'output record sent to network' (45 bytes) ssl_tls.c:3425: 0000: 16 03 03 00 28 00 00 00 00 00 00 00 00 00 73 7e ....(.........s~ .. .. .. .. .. .. .. .. .. .. ssl_tls.c:3425: 0020: 99 f6 b6 a5 40 de e8 c0 d5 ec 48 de 6e ....@.....H.n ssl_tls.c:2755: => flush output ssl_tls.c:2773: message length: 45, out_left: 45 ssl_tls.c:2779: ssl->f_send() returned 45 (-0xffffffd3) ssl_tls.c:2807: <= flush output ssl_tls.c:3476: <= write record ssl_tls.c:3320: <= write handshake message ssl_tls.c:6507: <= write finished ssl_cli.c:3510: client state: 12 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_tls.c:5902: => parse change cipher spec ssl_tls.c:4311: => read record ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 0, nb_want: 5 ssl_tls.c:2720: in_left: 0, nb_want: 5 ssl_tls.c:8094: <= handshake ssl_tls.c:8084: => handshake ssl_cli.c:3510: client state: 12 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_tls.c:5902: => parse change cipher spec ssl_tls.c:4311: => read record ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 0, nb_want: 5 ssl_tls.c:2720: in_left: 0, nb_want: 5 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_tls.c:2742: <= fetch input ssl_tls.c:4047: dumping 'input record header' (5 bytes) ssl_tls.c:4047: 0000: 15 03 03 00 02 ..... ssl_tls.c:4053: input record: msgtype = 21, version = [3:3], msglen = 2 ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 5, nb_want: 7 ssl_tls.c:2720: in_left: 5, nb_want: 7 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 2 (-0xfffffffe) ssl_tls.c:2742: <= fetch input ssl_tls.c:4232: dumping 'input record from network' (7 bytes) ssl_tls.c:4232: 0000: 15 03 03 00 02 02 28 ......( ssl_tls.c:5169: got an alert message, type: [2:40] ssl_tls.c:5177: is a fatal alert message (msg 40) ssl_tls.c:4369: mbedtls_ssl_handle_message_type() returned -30592 (-0x7780) ssl_tls.c:5906: mbedtls_ssl_read_record() returned -30592 (-0x7780) ssl_tls.c:8094: <= handshake mbedtls_ssl_handshake failed: -30592 -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

5 years

2
1
0 0

Re: [mbed-tls] Set an MPI and print it

by Manuel Pegourie-Gonnard

Hi Youssouf, I think you're looking for mbedtls_mpi_write_file() - just pass NULL as the file argument to write to stdout. You can use the radix argument to print out hex or decimal. Regards, Manuel. ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of youssouf sokhona via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 25 August 2020 15:40 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Set an MPI and print it Hi everyone, I think you all are fine. I am a beginner on mbedtls, and I wanted to set a dhm context. So, at first, I just want to set the value of the prime P, and the generator G. So to that I wrote the function below : [cid:image001.png@01D67AF5.D43FDE60] To check if it is correctly set, I wanted to print it to see. However, it is not the case. Do you know how to set and print the value ? Thanks, and have a good day Best regards, YS

5 years

1
0
0 0

mbedtls handshake failed

by Manu Abraham

Greetings, I am trying to connect from a STM32H7 MCU to a mosquitto peer, Can someone please help me to fix this issue that I have ? I have used the DES3 cipher to create the keys .. openssl genrsa -des3 -out test_ca.key 2048 .. Fiddled quite a bit with buffers, stack, heap and mbedtls config, eventually the communication appears to be working, but the handshake appears to fail. At the client MCU side, I see the mbedtls_ssl_handshake failed message with a return value of 0x7780 Additionally, I do see this message too: ssl_tls.c:5169: got an alert message, type: [2:40] ssl_tls.c:5177: is a fatal alert message (msg 40) But unfortunately, I am unable to make out what the error message means. At the peer, this is what i do see: 1598367067: New connection from 192.168.1.33 on port 8883. 1598367074: OpenSSL Error: error:1417C0C7:SSL routines:tls_process_client_certif icate:peer did not return a certificate 1598367074: Socket error on client <unknown>, disconnecting. 1598368366: mosquitto version 1.6.7 terminating Someone, Please help ! Thanks, Manu ssl_tls.c:8084: => handshake ssl_cli.c:3510: client state: 0 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_cli.c:3510: client state: 1 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_cli.c:0774: => write client hello ssl_cli.c:0811: client hello, max version: [3:3] ssl_cli.c:0821: dumping 'client hello, random bytes' (32 bytes) ssl_cli.c:0821: 0000: 3c ce d6 f9 48 cc 7d 5d 77 24 74 f2 1d 9f 8b aa <...H.}]w$t..... ssl_cli.c:0821: 0010: 4b 0c 20 64 d3 22 d0 ee 5e 3b 83 24 a7 01 ec d9 K. d."..^;.$.... ssl_cli.c:0874: client hello, session id len.: 0 ssl_cli.c:0875: dumping 'client hello, session id' (0 bytes) ssl_cli.c:0921: client hello, add ciphersuite: c02c ssl_cli.c:0921: client hello, add ciphersuite: c02b ssl_cli.c:0921: client hello, add ciphersuite: c030 ssl_cli.c:0921: client hello, add ciphersuite: c02f ssl_cli.c:0934: client hello, got 4 ciphersuites (excluding SCSVs) ssl_cli.c:0943: adding EMPTY_RENEGOTIATION_INFO_SCSV ssl_cli.c:0992: client hello, compress len.: 1 ssl_cli.c:0993: client hello, compress alg.: 0 ssl_cli.c:0186: client hello, adding signature_algorithms extension ssl_cli.c:0271: client hello, adding supported_elliptic_curves extension ssl_cli.c:0336: client hello, adding supported_point_formats extension ssl_cli.c:1070: client hello, total extension length: 38 ssl_tls.c:3184: => write handshake message ssl_tls.c:3343: => write record ssl_tls.c:3420: output record: msgtype = 22, version = [3:3], msglen = 93 ssl_tls.c:3425: dumping 'output record sent to network' (98 bytes) ssl_tls.c:3425: 0000: 16 03 03 00 5d 01 00 00 59 03 03 3c ce d6 f9 48 ....]...Y..<...H .. .. .. .. .. .. .. .. .. .. ssl_tls.c:3425: 0050: 03 01 00 0a 00 06 00 04 00 18 00 17 00 0b 00 02 ................ ssl_tls.c:3425: 0060: 01 00 .. ssl_tls.c:2755: => flush output ssl_tls.c:2773: message length: 98, out_left: 98 ssl_tls.c:2779: ssl->f_send() returned 98 (-0xffffff9e) ssl_tls.c:2807: <= flush output ssl_tls.c:3476: <= write record ssl_tls.c:3320: <= write handshake message ssl_cli.c:1106: <= write client hello ssl_cli.c:3510: client state: 2 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_cli.c:1499: => parse server hello ssl_tls.c:4311: => read record ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 0, nb_want: 5 ssl_tls.c:2720: in_left: 0, nb_want: 5 ssl_tls.c:8094: <= handshake ssl_tls.c:8084: => handshake ssl_cli.c:3510: client state: 2 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_cli.c:1499: => parse server hello ssl_tls.c:4311: => read record ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 0, nb_want: 5 ssl_tls.c:2720: in_left: 0, nb_want: 5 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_tls.c:2742: <= fetch input ssl_tls.c:4047: dumping 'input record header' (5 bytes) ssl_tls.c:4047: 0000: 16 03 03 00 59 ....Y ssl_tls.c:4053: input record: msgtype = 22, version = [3:3], msglen = 89 ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 5, nb_want: 94 ssl_tls.c:2720: in_left: 5, nb_want: 94 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 89 (-0xffffffa7) ssl_tls.c:2742: <= fetch input ssl_tls.c:4232: dumping 'input record from network' (94 bytes) ssl_tls.c:4232: 0000: 16 03 03 00 59 02 00 00 55 03 03 d1 64 6e e1 0c ....Y...U...dn.. .. .. .. .. .. .. .. .. .. .. ssl_tls.c:4232: 0050: 0d ff 01 00 01 00 00 0b 00 04 03 00 01 02 .............. ssl_tls.c:3624: handshake message: msglen = 89, type = 2, hslen = 89 ssl_tls.c:4385: <= read record ssl_cli.c:1579: dumping 'server hello, version' (2 bytes) ssl_cli.c:1579: 0000: 03 03 .. ssl_cli.c:1600: server hello, current time: 3513020129 ssl_cli.c:1610: dumping 'server hello, random bytes' (32 bytes) ssl_cli.c:1610: 0000: d1 64 6e e1 0c 1f ac 75 77 eb d7 02 24 dd a7 da .dn....uw...$... ssl_cli.c:1610: 0010: 48 f3 50 43 34 10 d8 d9 44 4f 57 4e 47 52 44 01 H.PC4...DOWNGRD. ssl_cli.c:1690: server hello, session id len.: 32 ssl_cli.c:1691: dumping 'server hello, session id' (32 bytes) ssl_cli.c:1691: 0000: 90 8f cc f8 31 63 81 ae aa bf a9 b9 61 1e 78 f6 ....1c......a.x. ssl_cli.c:1691: 0010: 79 b8 26 66 51 99 f4 50 45 d4 21 9b 22 24 4c 63 y.&fQ..PE.!."$Lc ssl_cli.c:1728: no session has been resumed ssl_cli.c:1731: server hello, chosen ciphersuite: c030 ssl_cli.c:1732: server hello, compress alg.: 0 ssl_cli.c:1764: server hello, chosen ciphersuite: TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 ssl_cli.c:1789: server hello, total extension length: 13 ssl_cli.c:1809: found renegotiation extension ssl_cli.c:1888: found supported_point_formats extension ssl_cli.c:1292: point format selected: 0 ssl_cli.c:1978: <= parse server hello ssl_cli.c:3510: client state: 3 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_tls.c:5655: => parse certificate ssl_tls.c:4311: => read record ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 0, nb_want: 5 ssl_tls.c:2720: in_left: 0, nb_want: 5 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_tls.c:2742: <= fetch input ssl_tls.c:4047: dumping 'input record header' (5 bytes) ssl_tls.c:4047: 0000: 16 03 03 07 80 ..... ssl_tls.c:4053: input record: msgtype = 22, version = [3:3], msglen = 1920 ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 5, nb_want: 1925 ssl_tls.c:2720: in_left: 5, nb_want: 1925 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 1361 (-0xfffffaaf) ssl_tls.c:2720: in_left: 1366, nb_want: 1925 ssl_tls.c:8094: <= handshake ssl_tls.c:8084: => handshake ssl_cli.c:3510: client state: 3 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_tls.c:5655: => parse certificate ssl_tls.c:4311: => read record ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 1366, nb_want: 5 ssl_tls.c:2742: <= fetch input ssl_tls.c:4047: dumping 'input record header' (5 bytes) ssl_tls.c:4047: 0000: 16 03 03 07 80 ..... ssl_tls.c:4053: input record: msgtype = 22, version = [3:3], msglen = 1920 ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 1366, nb_want: 1925 ssl_tls.c:2720: in_left: 1366, nb_want: 1925 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 559 (-0xfffffdd1) ssl_tls.c:2742: <= fetch input ssl_tls.c:4232: dumping 'input record from network' (1925 bytes) ssl_tls.c:4232: 0000: 16 03 03 07 80 0b 00 07 7c 00 07 79 00 03 90 30 ........|..y...0 .. .. .. .. .. .. .. .. .. .. ssl_tls.c:4232: 0770: df d8 30 17 65 70 2a 02 54 9a 4c cf b1 51 04 25 ..0.ep*.T.L..Q.% ssl_tls.c:4232: 0780: 83 2c ab dd 46 .,..F ssl_tls.c:3624: handshake message: msglen = 1920, type = 11, hslen = 1920 ssl_tls.c:4385: <= read record ssl_tls.c:5606: peer certificate #1: ssl_tls.c:5606: cert. version : 1 ssl_tls.c:5606: serial number : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ssl_tls.c:5606: issuer name : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ssl_tls.c:5606: subject name : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ssl_tls.c:5606: issued on : 2020-08-15 09:12:30 ssl_tls.c:5606: expires on : 2030-08-13 09:12:30 ssl_tls.c:5606: signed using : RSA with SHA-256 ssl_tls.c:5606: RSA key size : 2048 bits ssl_tls.c:5606: value of 'crt->rsa.N' (2048 bits) is: ssl_tls.c:5606: c9 93 0d f4 7b 93 95 8f 4d ec bb 77 46 82 48 6d .. .. .. .. .. .. .. .. .. .. ssl_tls.c:5606: 0f 00 85 cf c9 40 b0 f8 b2 df 1b 75 bd 2e 95 43 ssl_tls.c:5606: value of 'crt->rsa.E' (17 bits) is: ssl_tls.c:5606: 01 00 01 ssl_tls.c:5606: peer certificate #2: ssl_tls.c:5606: cert. version : 3 ssl_tls.c:5606: serial number : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ssl_tls.c:5606: issuer name : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ssl_tls.c:5606: subject name : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ssl_tls.c:5606: issued on : 2020-08-15 08:54:30 ssl_tls.c:5606: expires on : 2030-08-13 08:54:30 ssl_tls.c:5606: signed using : RSA with SHA-256 ssl_tls.c:5606: RSA key size : 2048 bits ssl_tls.c:5606: basic constraints : CA=true ssl_tls.c:5606: value of 'crt->rsa.N' (2048 bits) is: ssl_tls.c:5606: c4 e2 4b 37 45 4a 36 e5 b0 14 f7 fa 76 1d c4 29 .. .. .. .. .. .. .. .. .. .. ssl_tls.c:5606: 43 7c 19 f2 b0 dc ef 69 cf 13 c4 cb fa 80 92 f1 ssl_tls.c:5606: value of 'crt->rsa.E' (17 bits) is: ssl_tls.c:5606: 01 00 01 ssl_tls.c:5856: Certificate verification flags clear ssl_tls.c:5863: <= parse certificate ssl_cli.c:3510: client state: 4 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_cli.c:2336: => parse server key exchange ssl_tls.c:4311: => read record ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 0, nb_want: 5 ssl_tls.c:2720: in_left: 0, nb_want: 5 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_tls.c:2742: <= fetch input ssl_tls.c:4047: dumping 'input record header' (5 bytes) ssl_tls.c:4047: 0000: 16 03 03 01 4d ....M ssl_tls.c:4053: input record: msgtype = 22, version = [3:3], msglen = 333 ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 5, nb_want: 338 ssl_tls.c:2720: in_left: 5, nb_want: 338 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 333 (-0xfffffeb3) ssl_tls.c:2742: <= fetch input ssl_tls.c:4232: dumping 'input record from network' (338 bytes) ssl_tls.c:4232: 0000: 16 03 03 01 4d 0c 00 01 49 03 00 17 41 04 6e 49 ....M...I...A.nI .. .. .. .. .. .. .. .. .. .. ssl_tls.c:4232: 0140: c4 4b 34 2f 83 5f 98 17 39 5e 6e 4d 56 f4 c1 4c .K4/._..9^nMV..L ssl_tls.c:4232: 0150: 39 0f 9. ssl_tls.c:3624: handshake message: msglen = 333, type = 12, hslen = 333 ssl_tls.c:4385: <= read record ssl_cli.c:2424: dumping 'server key exchange' (329 bytes) ssl_cli.c:2424: 0000: 03 00 17 41 04 6e 49 4b 1c 4e 7b 2b ff c3 c9 9b ...A.nIK.N{+.... .. .. .. .. .. .. .. .. .. .. ssl_cli.c:2424: 0130: d9 33 d2 6e a7 05 ca c4 4b 34 2f 83 5f 98 17 39 .3.n....K4/._..9 ssl_cli.c:2424: 0140: 5e 6e 4d 56 f4 c1 4c 39 0f ^nMV..L9. ssl_cli.c:2044: ECDH curve: secp256r1 ssl_cli.c:2054: value of 'ECDH: Qp(X)' (255 bits) is: ssl_cli.c:2054: 6e 49 4b 1c 4e 7b 2b ff c3 c9 9b 81 29 4d a8 92 ssl_cli.c:2054: af c2 77 2b 3b c6 26 ba d4 c7 a2 2d 83 78 e3 54 ssl_cli.c:2054: value of 'ECDH: Qp(Y)' (256 bits) is: ssl_cli.c:2054: d6 91 fe 18 70 fb bc b6 c7 aa 67 1c 08 8b 4d 58 ssl_cli.c:2054: a4 70 59 97 90 23 8d 4b b6 24 4e 1a 7e 13 f2 d1 ssl_cli.c:2278: Server used SignatureAlgorithm 1 ssl_cli.c:2279: Server used HashAlgorithm 4 ssl_cli.c:2580: dumping 'signature' (256 bytes) ssl_cli.c:2580: 0000: b3 88 25 7f 3f 6b cf 7e 03 de 11 5b 4f 47 e9 6e ..%.?k.~...[OG.n .. .. .. .. .. .. .. .. .. .. ssl_cli.c:2580: 00f0: 34 2f 83 5f 98 17 39 5e 6e 4d 56 f4 c1 4c 39 0f 4/._..9^nMV..L9. ssl_cli.c:2616: dumping 'parameters hash' (32 bytes) ssl_cli.c:2616: 0000: bc 4e 7e a6 a6 02 76 66 2c da 19 6c ea 5a aa df .N~...vf,..l.Z.. ssl_cli.c:2616: 0010: ae 3a ff e9 34 c6 d1 72 98 b4 f3 7d b8 71 11 65 .:..4..r...}.q.e ssl_cli.c:2664: <= parse server key exchange ssl_cli.c:3510: client state: 5 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_cli.c:2697: => parse certificate request ssl_tls.c:4311: => read record ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 0, nb_want: 5 ssl_tls.c:2720: in_left: 0, nb_want: 5 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_tls.c:2742: <= fetch input ssl_tls.c:4047: dumping 'input record header' (5 bytes) ssl_tls.c:4047: 0000: 16 03 03 00 3a ....: ssl_tls.c:4053: input record: msgtype = 22, version = [3:3], msglen = 58 ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 5, nb_want: 63 ssl_tls.c:2720: in_left: 5, nb_want: 63 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 58 (-0xffffffc6) ssl_tls.c:2742: <= fetch input ssl_tls.c:4232: dumping 'input record from network' (63 bytes) ssl_tls.c:4232: 0000: 16 03 03 00 3a 0d 00 00 36 03 01 02 40 00 2e 04 ....:...6...@... .. .. .. .. .. .. .. .. .. .. ssl_tls.c:4232: 0030: 01 02 01 03 02 02 02 04 02 05 02 06 02 00 00 ............... ssl_tls.c:3624: handshake message: msglen = 58, type = 13, hslen = 58 ssl_tls.c:4385: <= read record ssl_cli.c:2723: got a certificate request ssl_cli.c:2823: Supported Signature Algorithm found: 4,3 ssl_cli.c:2823: Supported Signature Algorithm found: 5,3 ssl_cli.c:2823: Supported Signature Algorithm found: 6,3 ssl_cli.c:2823: Supported Signature Algorithm found: 8,7 ssl_cli.c:2823: Supported Signature Algorithm found: 8,8 ssl_cli.c:2823: Supported Signature Algorithm found: 8,9 ssl_cli.c:2823: Supported Signature Algorithm found: 8,10 ssl_cli.c:2823: Supported Signature Algorithm found: 8,11 ssl_cli.c:2823: Supported Signature Algorithm found: 8,4 ssl_cli.c:2823: Supported Signature Algorithm found: 8,5 ssl_cli.c:2823: Supported Signature Algorithm found: 8,6 ssl_cli.c:2823: Supported Signature Algorithm found: 4,1 ssl_cli.c:2823: Supported Signature Algorithm found: 5,1 ssl_cli.c:2823: Supported Signature Algorithm found: 6,1 ssl_cli.c:2823: Supported Signature Algorithm found: 3,3 ssl_cli.c:2823: Supported Signature Algorithm found: 2,3 ssl_cli.c:2823: Supported Signature Algorithm found: 3,1 ssl_cli.c:2823: Supported Signature Algorithm found: 2,1 ssl_cli.c:2823: Supported Signature Algorithm found: 3,2 ssl_cli.c:2823: Supported Signature Algorithm found: 2,2 ssl_cli.c:2823: Supported Signature Algorithm found: 4,2 ssl_cli.c:2823: Supported Signature Algorithm found: 5,2 ssl_cli.c:2823: Supported Signature Algorithm found: 6,2 ssl_cli.c:2846: <= parse certificate request ssl_cli.c:3510: client state: 6 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_cli.c:2856: => parse server hello done ssl_tls.c:4311: => read record ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 0, nb_want: 5 ssl_tls.c:2720: in_left: 0, nb_want: 5 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_tls.c:2742: <= fetch input ssl_tls.c:4047: dumping 'input record header' (5 bytes) ssl_tls.c:4047: 0000: 16 03 03 00 04 ..... ssl_tls.c:4053: input record: msgtype = 22, version = [3:3], msglen = 4 ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 5, nb_want: 9 ssl_tls.c:2720: in_left: 5, nb_want: 9 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 4 (-0xfffffffc) ssl_tls.c:2742: <= fetch input ssl_tls.c:4232: dumping 'input record from network' (9 bytes) ssl_tls.c:4232: 0000: 16 03 03 00 04 0e 00 00 00 ......... ssl_tls.c:3624: handshake message: msglen = 4, type = 14, hslen = 4 ssl_tls.c:4385: <= read record ssl_cli.c:2886: <= parse server hello done ssl_cli.c:3510: client state: 7 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_tls.c:5329: => write certificate ssl_tls.c:3184: => write handshake message ssl_tls.c:3343: => write record ssl_tls.c:3420: output record: msgtype = 22, version = [3:3], msglen = 7 ssl_tls.c:3425: dumping 'output record sent to network' (12 bytes) ssl_tls.c:3425: 0000: 16 03 03 00 07 0b 00 00 03 00 00 00 ............ ssl_tls.c:2755: => flush output ssl_tls.c:2773: message length: 12, out_left: 12 ssl_tls.c:2779: ssl->f_send() returned 12 (-0xfffffff4) ssl_tls.c:2807: <= flush output ssl_tls.c:3476: <= write record ssl_tls.c:3320: <= write handshake message ssl_tls.c:5433: <= write certificate ssl_cli.c:3510: client state: 8 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_cli.c:2898: => write client key exchange ssl_cli.c:2977: value of 'ECDH: Q(X)' (256 bits) is: ssl_cli.c:2977: e8 dd a7 e4 3d f4 43 c0 1f 42 67 99 2f 1b bd a8 ssl_cli.c:2977: 10 03 3d 45 5f 3b f8 46 ff d6 b8 65 3c 13 6a 3b ssl_cli.c:2977: value of 'ECDH: Q(Y)' (256 bits) is: ssl_cli.c:2977: 9a f8 36 4d 19 01 01 02 d6 bb 51 4a 1d ec f1 7f ssl_cli.c:2977: 28 70 31 95 65 62 1e d6 8d 97 b6 cc 3f b4 9a 8e ssl_cli.c:3005: value of 'ECDH: z' (253 bits) is: ssl_cli.c:3005: 14 06 75 26 fd 2c 2e 3f ad cf 0c fe 6b df 66 7c ssl_cli.c:3005: c2 b7 54 7e 62 ea 4e 0b 93 d0 62 22 15 e6 db 43 ssl_tls.c:3184: => write handshake message ssl_tls.c:3343: => write record ssl_tls.c:3420: output record: msgtype = 22, version = [3:3], msglen = 70 ssl_tls.c:3425: dumping 'output record sent to network' (75 bytes) ssl_tls.c:3425: 0000: 16 03 03 00 46 10 00 00 42 41 04 e8 dd a7 e4 3d ....F...BA.....= .. .. .. .. .. .. .. .. .. .. ssl_tls.c:3425: 0040: 62 1e d6 8d 97 b6 cc 3f b4 9a 8e b......?... ssl_tls.c:2755: => flush output ssl_tls.c:2773: message length: 75, out_left: 75 ssl_tls.c:2779: ssl->f_send() returned 75 (-0xffffffb5) ssl_tls.c:2807: <= flush output ssl_tls.c:3476: <= write record ssl_tls.c:3320: <= write handshake message ssl_cli.c:3172: <= write client key exchange ssl_cli.c:3510: client state: 9 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_cli.c:3224: => write certificate verify ssl_tls.c:0628: => derive keys ssl_tls.c:0705: dumping 'premaster secret' (32 bytes) ssl_tls.c:0705: 0000: 14 06 75 26 fd 2c 2e 3f ad cf 0c fe 6b df 66 7c ..u&.,.?....k.f| ssl_tls.c:0705: 0010: c2 b7 54 7e 62 ea 4e 0b 93 d0 62 22 15 e6 db 43 ..T~b.N...b"...C ssl_tls.c:0794: ciphersuite = TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 ssl_tls.c:0796: dumping 'master secret' (48 bytes) ssl_tls.c:0796: 0000: 5a 15 26 c7 71 73 1a 2e 8c 0d 0e 55 d7 6f 7f b5 Z.&.qs.....U.o.. .. .. .. .. .. .. .. .. .. .. ssl_tls.c:0796: 0020: 24 bf 3f 51 ca e9 7b 66 99 61 cf a9 fb 61 e2 2f $.?Q..{f.a...a./ ssl_tls.c:0797: dumping 'random bytes' (64 bytes) ssl_tls.c:0797: 0000: d1 64 6e e1 0c 1f ac 75 77 eb d7 02 24 dd a7 da .dn....uw...$... .. .. .. .. .. .. .. .. .. .. ssl_tls.c:0797: 0030: 4b 0c 20 64 d3 22 d0 ee 5e 3b 83 24 a7 01 ec d9 K. d."..^;.$.... ssl_tls.c:0798: dumping 'key block' (256 bytes) ssl_tls.c:0798: 0000: 5d b4 7a 60 2e 5b f8 fb 8f e4 75 22 9a b4 8c 04 ].z`.[....u".... .. .. .. .. .. .. .. .. .. .. ssl_tls.c:0798: 00f0: 53 af 8e 78 d0 03 ca 26 b7 43 ee c6 aa 0e 71 88 S..x...&.C....q. ssl_tls.c:0919: keylen: 32, minlen: 24, ivlen: 12, maclen: 0 ssl_tls.c:1116: <= derive keys ssl_cli.c:3253: <= skip write certificate verify ssl_cli.c:3510: client state: 10 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_tls.c:5879: => write change cipher spec ssl_tls.c:3184: => write handshake message ssl_tls.c:3343: => write record ssl_tls.c:3420: output record: msgtype = 20, version = [3:3], msglen = 1 ssl_tls.c:3425: dumping 'output record sent to network' (6 bytes) ssl_tls.c:3425: 0000: 14 03 03 00 01 01 ...... ssl_tls.c:2755: => flush output ssl_tls.c:2773: message length: 6, out_left: 6 ssl_tls.c:2779: ssl->f_send() returned 6 (-0xfffffffa) ssl_tls.c:2807: <= flush output ssl_tls.c:3476: <= write record ssl_tls.c:3320: <= write handshake message ssl_tls.c:5893: <= write change cipher spec ssl_cli.c:3510: client state: 11 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_tls.c:6398: => write finished ssl_tls.c:6272: => calc finished tls sha384 ssl_tls.c:6283: dumping 'finished sha512 state' (64 bytes) ssl_tls.c:6283: 0000: e2 6c 37 56 90 66 0a f8 1c c7 26 d0 49 a9 87 52 .l7V.f....&.I..R .. .. .. .. .. .. .. .. .. .. ssl_tls.c:6283: 0030: 85 b3 04 84 77 e5 02 b0 53 d7 31 b4 c4 e4 08 c0 ....w...S.1..... ssl_tls.c:6296: dumping 'calc finished result' (12 bytes) ssl_tls.c:6296: 0000: c4 6a dd c2 9b a7 75 28 ff 53 5a 3f .j....u(.SZ? ssl_tls.c:6302: <= calc finished ssl_tls.c:6443: switching to new transform spec for outbound data ssl_tls.c:3184: => write handshake message ssl_tls.c:3343: => write record ssl_tls.c:1445: => encrypt buf ssl_tls.c:1455: dumping 'before encrypt: output payload' (16 bytes) ssl_tls.c:1455: 0000: 14 00 00 0c c4 6a dd c2 9b a7 75 28 ff 53 5a 3f .....j....u(.SZ? ssl_tls.c:1574: dumping 'additional data for AEAD' (13 bytes) ssl_tls.c:1574: 0000: 00 00 00 00 00 00 00 00 16 03 03 00 10 ............. ssl_tls.c:1604: dumping 'IV used (internal)' (12 bytes) ssl_tls.c:1604: 0000: a0 9a 1f cb 00 00 00 00 00 00 00 00 ............ ssl_tls.c:1606: dumping 'IV used (transmitted)' (8 bytes) ssl_tls.c:1606: 0000: 00 00 00 00 00 00 00 00 ........ ssl_tls.c:1616: before encrypt: msglen = 24, including 0 bytes of padding ssl_tls.c:1643: dumping 'after encrypt: tag' (16 bytes) ssl_tls.c:1643: 0000: e7 10 1d 99 f6 b6 a5 40 de e8 c0 d5 ec 48 de 6e .......@.....H.n ssl_tls.c:1781: <= encrypt buf ssl_tls.c:3420: output record: msgtype = 22, version = [3:3], msglen = 40 ssl_tls.c:3425: dumping 'output record sent to network' (45 bytes) ssl_tls.c:3425: 0000: 16 03 03 00 28 00 00 00 00 00 00 00 00 00 73 7e ....(.........s~ .. .. .. .. .. .. .. .. .. .. ssl_tls.c:3425: 0020: 99 f6 b6 a5 40 de e8 c0 d5 ec 48 de 6e ....@.....H.n ssl_tls.c:2755: => flush output ssl_tls.c:2773: message length: 45, out_left: 45 ssl_tls.c:2779: ssl->f_send() returned 45 (-0xffffffd3) ssl_tls.c:2807: <= flush output ssl_tls.c:3476: <= write record ssl_tls.c:3320: <= write handshake message ssl_tls.c:6507: <= write finished ssl_cli.c:3510: client state: 12 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_tls.c:5902: => parse change cipher spec ssl_tls.c:4311: => read record ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 0, nb_want: 5 ssl_tls.c:2720: in_left: 0, nb_want: 5 ssl_tls.c:8094: <= handshake ssl_tls.c:8084: => handshake ssl_cli.c:3510: client state: 12 ssl_tls.c:2755: => flush output ssl_tls.c:2767: <= flush output ssl_tls.c:5902: => parse change cipher spec ssl_tls.c:4311: => read record ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 0, nb_want: 5 ssl_tls.c:2720: in_left: 0, nb_want: 5 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_tls.c:2742: <= fetch input ssl_tls.c:4047: dumping 'input record header' (5 bytes) ssl_tls.c:4047: 0000: 15 03 03 00 02 ..... ssl_tls.c:4053: input record: msgtype = 21, version = [3:3], msglen = 2 ssl_tls.c:2536: => fetch input ssl_tls.c:2696: in_left: 5, nb_want: 7 ssl_tls.c:2720: in_left: 5, nb_want: 7 ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 2 (-0xfffffffe) ssl_tls.c:2742: <= fetch input ssl_tls.c:4232: dumping 'input record from network' (7 bytes) ssl_tls.c:4232: 0000: 15 03 03 00 02 02 28 ......( ssl_tls.c:5169: got an alert message, type: [2:40] ssl_tls.c:5177: is a fatal alert message (msg 40) ssl_tls.c:4369: mbedtls_ssl_handle_message_type() returned -30592 (-0x7780) ssl_tls.c:5906: mbedtls_ssl_read_record() returned -30592 (-0x7780) ssl_tls.c:8094: <= handshake mbedtls_ssl_handshake failed: -30592

5 years, 1 month

1
0
0 0

Set an MPI and print it

by youssouf sokhona

Hi everyone, I think you all are fine. I am a beginner on mbedtls, and I wanted to set a dhm context. So, at first, I just want to set the value of the prime P, and the generator G. So to that I wrote the function below : [cid:image001.png@01D67AF5.D43FDE60] To check if it is correctly set, I wanted to print it to see. However, it is not the case. Do you know how to set and print the value ? Thanks, and have a good day Best regards, YS

5 years, 1 month

1
0
0 0

undefined reference….

by youssouf sokhona

Hello everybody, I hope you are going well I am creating a diffie Hellman key exchange program, so I am using functions like « mbedtls_dhm_init() » or « mbedtls_ctr_drbg_init() « for example. However, even if I defined the CTR_DRBG & the DHM_C module in the config.h file, and the header in my C file, I Always have error like that : [cid:image002.png@01D6770C.20370D40] Can someone help me to find out where does it come from ? Because I don’t know at all. Thanks, and have a good day

5 years, 1 month

1
0
0 0

Printf with %z and %hh format specifiers.

by Paul Elliott

Hi all, I am placing into review a patch ( https://github.com/ARMmbed/mbedtls/pull/3579) which replaces some invalid size printf format specifiers, mostly for size_t. This patch utilises %zu and %hhu, both of which were only introduced in C99, which I know caused some issues with compiler compatibility at the time. The problem with printf and size_t as most will know, is that its a different size in 32 bit and 64 bit, which is what %z was introduced to safely fix. My question is to whether there is anyone on the list that is using a compiler that might not handle these specifiers, for whom this patch would presumably be something of an issue. I am admittedly hoping this is not the case, given the age of the spec, but thought it best to ask. Thanks in advance, Paul.

5 years, 1 month

1
0
0 0

Re: [mbed-tls] Custom PSA API Implementation for mbedTLS tests

by Dan Handley

Hi Murat What you request may be possible with invasive changes but it is not a design goal for the PSA Cryptography API implementation in Mbed TLS to be completely replaced with an alternative implementation, while allowing re-use of the Mbed TLS build system and tests. The focus instead is to develop and implement a PSA Cryptoprocessor Driver Interface, which will allow drivers for custom secure environments to be plugged into the core PSA Cryptography API implementation in Mbed TLS. An early version of the specification of that interface can be found here: https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-drive… That specification and its implementation is under active development. Let us know if you would like to get involved. Regards Dan. From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of Murat Cakmak via mbed-tls Sent: 14 August 2020 13:34 To: mbed-tls(a)lists.trustedfirmware.org Subject: [mbed-tls] Custom PSA API Implementation for mbedTLS tests Hi all, We have implemented the PSA Functional API for a custom secure environment which passes PSA Arch tests. Now we would like to run mbedtls tests (make check) on the PSA API if possible. When we run "make check", it includes and compiles library/psa_crypto.c file for mbedTLS's PSA API Implementation. Herein, we would like to compile our own psa_crypto.c implementation, does mbedtls build system allow us to include custom PSA API Implementation to run tests? Thank you. Murat

5 years, 1 month

1
0
0 0

Re: [mbed-tls] MBEDTLS_ENTROPY_HARDWARE_ALT, mbedtls_ctr_drbg_seed() freezes ?

by Manu Abraham

Replying to my own post, I did dig in a bit more; It appears that it gets stuck in here within: int mbedtls_ctr_drbg_reseed( mbedtls_ctr_drbg_context *ctx, const unsigned char *additional, size_t len ) memset( seed, 0, MBEDTLS_CTR_DRBG_MAX_SEED_INPUT ); printf("(%d) %s: Done\r\n", __LINE__, __FUNCTION__); <---- line#412 /* * Gather entropy_len bytes of entropy to seed state */ if( 0 != ctx->f_entropy( ctx->p_entropy, seed, ctx->entropy_len ) ) <----- appears to be stuck in this callback f_entropy() { return( MBEDTLS_ERR_CTR_DRBG_ENTROPY_SOURCE_FAILED ); } seedlen += ctx->entropy_len; printf("(%d) %s: Done\r\n", __LINE__, __FUNCTION__); <----- line #424 Sprinkling a few prints here and there, it looks thus: (174) tls_init: Initializing (178) tls_init: SSL initialize (181) tls_init: SSL Config initialized (184) tls_init: x509 CRT initialized (187) tls_init: DRBG initialized (190) tls_init: Entropy initialized (95) mbedtls_ctr_drbg_seed_entropy_len: AES initialized (112) mbedtls_ctr_drbg_seed_entropy_len: AES setkey enc (412) mbedtls_ctr_drbg_reseed: Done (1027) mbedtls_hardware_poll: Random Words: 128 Word: 834688558 Someone help ? Thanks, Manu On Mon, Aug 17, 2020 at 10:46 PM Manu Abraham via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> wrote: > > Greetings, > > I am new to the list, please do excuse me, in case of any list > specific etiquette issues. > > Trying to use a 1.6.1 release with a Cortex M7 port, specifically a STM32H7. > > After enabling MBEDTLS_ENTROPY_HARDWARE_ALT, did implement > mbedtls_hardware_poll() > > It looks thus, and it does appear to work from a hardware perspective: > > /** > * mbedtls_hardware_poll() > * Read random data from the Hardware RNG for entropy applications > */ > int mbedtls_hardware_poll(void *arg, > unsigned char *ent_buf, > size_t count, > size_t *ent_len) > { > register uint8_t i = 0; > uint32_t rand; > > if (!LL_RNG_IsEnabled(RNG)) > LL_RNG_Enable(RNG); /* Enable Random Number Generator */ > > for (i = 0; i < count; i++) { > while (!LL_RNG_IsActiveFlag_DRDY(RNG)) { } /* Wait for DRDY > flag to be raised */ > if ((LL_RNG_IsActiveFlag_CECS(RNG)) || > (LL_RNG_IsActiveFlag_SECS(RNG))) { /* Check error, if any */ > > /* Clock or Seed Error detected. Set Error */ > printf(" (%d) %s: Clock/Seed Error!\r\n", __LINE__, __FUNCTION__); > } > rand = LL_RNG_ReadRandData32(RNG); /* Read RNG data */ > memcpy(&(ent_buf[i * 4]), &rand, 4); /* *ent_len += 4 */ > } > LL_RNG_Disable(RNG); /* Stop random numbers generation */ > *ent_len = ((i + 1) * 4); > printf(" (%d) %s: Random Words: %d Word: %04d\r\n", > __LINE__, > __FUNCTION__, > count, > rand); > > return 0; > } > > The code which causes the problem is this, in my tls_init() > > int tls_init(void) > { > int ret; > > /* inspired by https://tls.mbed.org/kb/how-to/mbedtls-tutorial */ > const char *pers = "SYS-LWH7"; > > printf(" (%d) %s: Initializing\r\n", __LINE__, __FUNCTION__); > /* initialize descriptors */ > > mbedtls_ssl_init(&ssl); > printf(" (%d) %s: SSL initialize\r\n", __LINE__, __FUNCTION__); > > mbedtls_ssl_config_init(&conf); > printf(" (%d) %s: SSL Config initialized\r\n", __LINE__, __FUNCTION__); > > mbedtls_x509_crt_init(&cacert); > printf(" (%d) %s: x509 CRT initialized\r\n", __LINE__, __FUNCTION__); > > mbedtls_ctr_drbg_init(&ctr_drbg); > printf(" (%d) %s: DRBG initialized\r\n", __LINE__, __FUNCTION__); > > mbedtls_entropy_init(&entropy); > printf(" (%d) %s: Entropy initialized\r\n", __LINE__, __FUNCTION__); > > > ret = mbedtls_ctr_drbg_seed(&ctr_drbg, > mbedtls_entropy_func, > &entropy, > (const unsigned char *) pers, > strlen(pers)); > if (ret) { > > LWIP_DEBUGF(MQTT_APP_DEBUG_TRACE, > ("failed !\n mbedtls_ctr_drbg_seed returned %d\n", > ret)); > > printf(" (%d) %s: DRBG seed failed, ret=%d\r\n", __LINE__, > __FUNCTION__, ret); > return -1; > } > printf(" (%d) %s: DRBG seed returned:%d\r\n", __LINE__, __FUNCTION__, ret); > > /** > * The transport type determines if we are using > * TLS (MBEDTLS_SSL_TRANSPORT_STREAM) or > * DTLS (MBEDTLS_SSL_TRANSPORT_DATAGRAM). > */ > ret = mbedtls_ssl_config_defaults(&conf, > MBEDTLS_SSL_IS_CLIENT, > MBEDTLS_SSL_TRANSPORT_STREAM, > MBEDTLS_SSL_PRESET_DEFAULT); > if (ret) { > LWIP_DEBUGF(MQTT_APP_DEBUG_TRACE, > ("failed !\n mbedtls_ssl_config_defaults returned %d\n\n", > ret)); > > printf("(%d) %s: SSL config defaults failed, ret=%d\r\n", > __LINE__, __FUNCTION__, ret); > return -1; > } > printf("(%d) %s: SSL config defaults returned:%d\r\n", __LINE__, > __FUNCTION__, ret); > > ret = mbedtls_x509_crt_parse(&cacert, > (const unsigned char *)test_ca_crt, > test_ca_crt_len); > if (ret) > printf(" (%d) %s: failed!\n mbedtls_x509_crt_parse returned > %d\r\n", __LINE__, __FUNCTION__, ret); > else > printf(" (%d) %s: mbedtls_x509_crt_parse returned %d\r\n", > __LINE__, __FUNCTION__, ret); > > mbedtls_ssl_conf_ca_chain(&conf, &cacert, NULL); > mbedtls_ssl_conf_authmode(&conf, MBEDTLS_SSL_VERIFY_REQUIRED); > > /** > * The library needs to know which random engine > * to use and which debug function to use as callback. > */ > mbedtls_ssl_conf_rng(&conf, mbedtls_ctr_drbg_random, &ctr_drbg); > mbedtls_ssl_conf_dbg(&conf, my_debug, stdout); > mbedtls_ssl_setup(&ssl, &conf); > } > > > The output of which looks thus, in a serial terminal: > > (1217) print_dhcp_state: Try connect to Broker > (174) tls_init: Initializing > (178) tls_init: SSL initialize > (181) tls_init: SSL Config initialized > (184) tls_init: x509 CRT initialized > (187) tls_init: DRBG initialized > (190) tls_init: Entropy initialized > (1027) mbedtls_hardware_poll: Random Words: 128 Word: -558876895 > > > Any thoughts/ideas, what could be wrong ? > Any kind soul in here ? > > Thanks, > Manu > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

5 years, 1 month

1
0
0 0

MBEDTLS_ENTROPY_HARDWARE_ALT, mbedtls_ctr_drbg_seed() freezes ?

by Manu Abraham

Greetings, I am new to the list, please do excuse me, in case of any list specific etiquette issues. Trying to use a 1.6.1 release with a Cortex M7 port, specifically a STM32H7. After enabling MBEDTLS_ENTROPY_HARDWARE_ALT, did implement mbedtls_hardware_poll() It looks thus, and it does appear to work from a hardware perspective: /** * mbedtls_hardware_poll() * Read random data from the Hardware RNG for entropy applications */ int mbedtls_hardware_poll(void *arg, unsigned char *ent_buf, size_t count, size_t *ent_len) { register uint8_t i = 0; uint32_t rand; if (!LL_RNG_IsEnabled(RNG)) LL_RNG_Enable(RNG); /* Enable Random Number Generator */ for (i = 0; i < count; i++) { while (!LL_RNG_IsActiveFlag_DRDY(RNG)) { } /* Wait for DRDY flag to be raised */ if ((LL_RNG_IsActiveFlag_CECS(RNG)) || (LL_RNG_IsActiveFlag_SECS(RNG))) { /* Check error, if any */ /* Clock or Seed Error detected. Set Error */ printf(" (%d) %s: Clock/Seed Error!\r\n", __LINE__, __FUNCTION__); } rand = LL_RNG_ReadRandData32(RNG); /* Read RNG data */ memcpy(&(ent_buf[i * 4]), &rand, 4); /* *ent_len += 4 */ } LL_RNG_Disable(RNG); /* Stop random numbers generation */ *ent_len = ((i + 1) * 4); printf(" (%d) %s: Random Words: %d Word: %04d\r\n", __LINE__, __FUNCTION__, count, rand); return 0; } The code which causes the problem is this, in my tls_init() int tls_init(void) { int ret; /* inspired by https://tls.mbed.org/kb/how-to/mbedtls-tutorial */ const char *pers = "SYS-LWH7"; printf(" (%d) %s: Initializing\r\n", __LINE__, __FUNCTION__); /* initialize descriptors */ mbedtls_ssl_init(&ssl); printf(" (%d) %s: SSL initialize\r\n", __LINE__, __FUNCTION__); mbedtls_ssl_config_init(&conf); printf(" (%d) %s: SSL Config initialized\r\n", __LINE__, __FUNCTION__); mbedtls_x509_crt_init(&cacert); printf(" (%d) %s: x509 CRT initialized\r\n", __LINE__, __FUNCTION__); mbedtls_ctr_drbg_init(&ctr_drbg); printf(" (%d) %s: DRBG initialized\r\n", __LINE__, __FUNCTION__); mbedtls_entropy_init(&entropy); printf(" (%d) %s: Entropy initialized\r\n", __LINE__, __FUNCTION__); ret = mbedtls_ctr_drbg_seed(&ctr_drbg, mbedtls_entropy_func, &entropy, (const unsigned char *) pers, strlen(pers)); if (ret) { LWIP_DEBUGF(MQTT_APP_DEBUG_TRACE, ("failed !\n mbedtls_ctr_drbg_seed returned %d\n", ret)); printf(" (%d) %s: DRBG seed failed, ret=%d\r\n", __LINE__, __FUNCTION__, ret); return -1; } printf(" (%d) %s: DRBG seed returned:%d\r\n", __LINE__, __FUNCTION__, ret); /** * The transport type determines if we are using * TLS (MBEDTLS_SSL_TRANSPORT_STREAM) or * DTLS (MBEDTLS_SSL_TRANSPORT_DATAGRAM). */ ret = mbedtls_ssl_config_defaults(&conf, MBEDTLS_SSL_IS_CLIENT, MBEDTLS_SSL_TRANSPORT_STREAM, MBEDTLS_SSL_PRESET_DEFAULT); if (ret) { LWIP_DEBUGF(MQTT_APP_DEBUG_TRACE, ("failed !\n mbedtls_ssl_config_defaults returned %d\n\n", ret)); printf("(%d) %s: SSL config defaults failed, ret=%d\r\n", __LINE__, __FUNCTION__, ret); return -1; } printf("(%d) %s: SSL config defaults returned:%d\r\n", __LINE__, __FUNCTION__, ret); ret = mbedtls_x509_crt_parse(&cacert, (const unsigned char *)test_ca_crt, test_ca_crt_len); if (ret) printf(" (%d) %s: failed!\n mbedtls_x509_crt_parse returned %d\r\n", __LINE__, __FUNCTION__, ret); else printf(" (%d) %s: mbedtls_x509_crt_parse returned %d\r\n", __LINE__, __FUNCTION__, ret); mbedtls_ssl_conf_ca_chain(&conf, &cacert, NULL); mbedtls_ssl_conf_authmode(&conf, MBEDTLS_SSL_VERIFY_REQUIRED); /** * The library needs to know which random engine * to use and which debug function to use as callback. */ mbedtls_ssl_conf_rng(&conf, mbedtls_ctr_drbg_random, &ctr_drbg); mbedtls_ssl_conf_dbg(&conf, my_debug, stdout); mbedtls_ssl_setup(&ssl, &conf); } The output of which looks thus, in a serial terminal: (1217) print_dhcp_state: Try connect to Broker (174) tls_init: Initializing (178) tls_init: SSL initialize (181) tls_init: SSL Config initialized (184) tls_init: x509 CRT initialized (187) tls_init: DRBG initialized (190) tls_init: Entropy initialized (1027) mbedtls_hardware_poll: Random Words: 128 Word: -558876895 Any thoughts/ideas, what could be wrong ? Any kind soul in here ? Thanks, Manu

5 years, 1 month

1
0
0 0

Re: [mbed-tls] LTS roadmap and announcement channel?

by Manuel Pegourie-Gonnard

Hi Simon, Indeed while the migration is underway things can be a bit confusing, so let me try to clarify: * releases can be found at: https://github.com/ARMmbed/mbedtls/releases - near the top you'll alwys find the latest development release followed by the latest LTS releases. At this point it is unclear if releases are going to stay on github or if they would move to trustedfrimware.org in the future, but if anything changes, we'll announce it. * announcements about new releases and other important project events are made on the new Mbed-tls-announce mailing-list: https://github.com/ARMmbed/mbedtls/releases - if you're already subscribed to mbed-tls (this list), you don't need to subscribe to the "announce" mailing list in addition, as any post to "announce" is automatically cross-posted here ("announce" is for people who want a lower volume list). * I don't think we're currently making announcements about upcoming releases, but I know we considered that. Unfortunately I don't remember the details and the colleague who was working on improving our release process is on leave now. But it we start making such announcements, they'll be on the "announce" list. * We're currently planning 2.16.8 early in September. * If you have a large number of products deployed that depend on Mbed TLS (or indeed any other tf.org project) and would like to be notified in advance of upcoming security fixes, please see the following pages: https://developer.trustedfirmware.org/w/mbed-tls/security-center/ https://developer.trustedfirmware.org/w/collaboration/security_center/repor… https://developer.trustedfirmware.org/w/collaboration/security_center/trust… I hope this answers your questions, and feel free to ask otherwise. Manuel. ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Simon Leet via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 14 August 2020 15:13 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] LTS roadmap and announcement channel? Hi folks, I understand that https://tls.mbed.org/ has migrated under the umbrella of https://www.trustedfirmware.org/ but it’s not clear where I should turn to for information about the updates to the LTS versions. The https://tls.mbed.org/tech-updates blog used to announce LTS branch updates but seems defunct as of 2.16.7, and I can’t find equivalent information in https://developer.trustedfirmware.org/w/mbed-tls/roadmap/, https://github.com/ARMmbed/mbedtls/projects/2 or the generic https://www.trustedfirmware.org/blog/. Is there a new channel for information about upcoming LTS mbedtls releases so that users can plan their appropriate upgrade cycles? E.g. when is 2.16.8 roughly expected to be released? Is the new model for monitoring release announcements reliably going to be as a new tag on https://github.com/ARMmbed/mbedtls/tags? -Simon

5 years, 1 month

1
0
0 0

MbedTLS_hardware_poll

by youssouf sokhona

Hi everyone, Hope you are still going well I am now working on MbedTLS to establish a key exchange with a BGM which has a TRNG , and I read that I have to implement myself a function called «mbedTLS_hardware_poll » But I have no idea to know how I can implement this function zlthough I read articles on the mbedtls.com about entropy site…. Can you help me, to know how I can implement this function ?

5 years, 1 month

1
0
0 0

Test

by Manu Abraham

Test mail

5 years, 1 month

1
0
0 0

Custom PSA API Implementation for mbedTLS tests

by murat＠za-ya.co

Hi all, We have implemented the PSA Functional API for a custom secure environment which passes PSA Arch tests. Now we would like to run mbedtls tests (make check) on the PSA API if possible. When we run "make check", it includes and compiles library/psa_crypto.c file for mbedTLS's PSA API Implementation. Herein, we would like to compile our own psa_crypto.c implementation, does mbedtls build system allow us to include custom PSA API Implementation to run tests? Thank you. Murat

5 years, 1 month

1
0
0 0

LTS roadmap and announcement channel?

by Simon Leet

Hi folks, I understand that https://tls.mbed.org/ has migrated under the umbrella of https://www.trustedfirmware.org/ but it's not clear where I should turn to for information about the updates to the LTS versions. The https://tls.mbed.org/tech-updates blog used to announce LTS branch updates but seems defunct as of 2.16.7, and I can't find equivalent information in https://developer.trustedfirmware.org/w/mbed-tls/roadmap/, https://github.com/ARMmbed/mbedtls/projects/2 or the generic https://www.trustedfirmware.org/blog/. Is there a new channel for information about upcoming LTS mbedtls releases so that users can plan their appropriate upgrade cycles? E.g. when is 2.16.8 roughly expected to be released? Is the new model for monitoring release announcements reliably going to be as a new tag on https://github.com/ARMmbed/mbedtls/tags? -Simon

5 years, 1 month

1
0
0 0

Re: [mbed-tls] Diffie Hellman Key Exchange

by Gilles Peskine

Hello, The interface of the Diffie-Hellman (DHM) module is modeled on the way it's used in TLS, which is a bit different from the classical presentation. You can find code examples in programs/pkey/dh_client.c and programs/pkey/dh_server.c . Elliptic-curve Diffie-Hellman (provided by the ECDH module) has similar security properties and is significantly faster. If you don't need interoperability with legacy software that only supports classical (finite-field) Diffie-Hellman, you should use ECDH rather than DHM. With the ECDH module, you can use either the same TLS-inspired interface as the DHM module, or a more classical interface for which there is a usage example in psa_crypto.c in the function psa_key_agreement_ecdh. Hope this helps, -- Gilles Peskine Mbed TLS developer You can find an example of the TLS-like inter On 12/08/2020 14:02, youssouf sokhona via mbed-tls wrote: > > Hello, I hope you are going well during this Covid crisis. > > > > I'm sending you this message to find out how to generate a Diffie > Hellman key using MbedTLS. Indeed, with all the documentation, I'm a > bit lost. > > > > I think, you have to use the int mbedtls_dhm_set_group function to > create p and g. And then, I don't know how to use which function... > Moreover, I can't find any function that allows to set a and b, > whereas they are 2 fundamental elements > > Can you help me? Thank you! > > > > Best regards, YS > > >

5 years, 1 month

1
0
0 0

Minimum Python version

by Gilles Peskine

Hello, Short version: to use the official tools to configure Mbed TLS, or to run the unit tests, you need Python. If we start requiring Python 3.5, is this going to be a problem? Detailed version: Mbed TLS includes four Python scripts that are of interest to users, with a fifth one in preparation: * scripts/config.py : compile-time configuration (unless you prefer to edit config.h directly). * scripts/generate_psa_constants.py : to build programs/psa/psa_constant_names (we have a pending task to commit the result instead of requiring it during the build). * tests/scripts/generate_test_code.py : necessary to build the unit tests. * tests/scripts/mbedtls_test.py : does anyone use this? It's for testing on platforms with Greentea, but some of the automation is missing. * upcoming: a script to generate glue code for accelerator and secure element drivers. We'll also provide a manual way, but it won't be as convenient. This is a question to everyone who's building Mbed TLS and using some of these scripts: is it ok if they require Python 3.5? Currently: * scripts/config.py requires Python 3.5. * scripts/generate_psa_constants.py requires Python 3.3. * tests/scripts/generate_test_code.py still works with Python 2.7. * tests/scripts/mbedtls_test.py still works with Python 2.7. * the driver glue code generation script will require Python 3.5, or Python 3.4 + typing. Is there any demand for versions of Python before 3.5? -- Gilles Peskine Mbed TLS developer

5 years, 1 month

1
0
0 0

Diffie Hellman Key Exchange

by youssouf sokhona

Hello, I hope you are going well during this Covid crisis. I'm sending you this message to find out how to generate a Diffie Hellman key using MbedTLS. Indeed, with all the documentation, I'm a bit lost. I think, you have to use the int mbedtls_dhm_set_group function to create p and g. And then, I don't know how to use which function... Moreover, I can't find any function that allows to set a and b, whereas they are 2 fundamental elements Can you help me? Thank you! Best regards, YS

5 years, 1 month

1
0
0 0

Re: [mbed-tls] Availability of 2.16.7 in download archive

by Janos Follath

Hi Frank, We have now updated the links both on the download-archive and releases site and now they point to https://github.com/ARMmbed/mbedtls/releases, where all the releases are available. We also have added checksums to the release notes on github and fixed the archive structure. Thank you very much for pointing these issues out! Cheers, Janos (Mbed TLS developer) On 04/08/2020, 19:06, "mbed-tls on behalf of Frank Bergmann via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote: Hi, 2.16.7 was released on github more than one month ago (2020-07-01). But it is not listed on - download archive at https://tls.mbed.org/download-archive - release news at https://tls.mbed.org/tech-updates/releases Questions about that: - Is it an "official" release even if it is not mentioned on release news? - When will it be available in download archive? - If there will be no more addings to download archive because now we'll have to use github: * Will there be separate releases GPL/Apache available? * Will a signed/unsigned check sum be provided? * Will the "new structure" as provided by tarball on github be kept in future or was it just an accident? (e.g. main dir is named "mbedtls-mbedtls-2.16.7") I started using mbed TLS with 2.16.6 but now I am confused. ;-) cheers, Frank -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

5 years, 1 month

1
0
0 0

Re: [mbed-tls] Availability of 2.16.7 in download archive

by Gilles Peskine

Hi Frank, I confirm that 2.16.7 is an official release of the 2.16 long-time support branch of Mbed TLS, alongside 2.7.16 for the 2.7 branch and 2.23.0 for the latest features. Everyone should update to one of these versions since they fix security issues and other bugs. We're progressively transitioning the project from Arm infrastructure to TrustedFirmware infrastructure. Eventually we'll decommission the existing tls.mbed.org, and we intend to distribute releases via trustedfirmware.org. We no longer intend to reference new releases directly on https://tls.mbed.org/download-archive . For the time being, we're distributing via GitHub. However, it isn't right that https://tls.mbed.org/download-archive links to https://github.com/ARMmbed/mbedtls/releases/ which doesn't list LTS branches. We need to link from https://tls.mbed.org/download-archive to the place that has the latest LTS releases one way or the other. There are no longer separate archives with Apache and GPL licenses. These archives were always identical except for license headers. Now LTS releases are distributed as a single archive in which the files are dual-licensed. The naming with mbedtls-mbedtls- must be a bug in our release script. Thanks for noticing. I don't think we made a conscious decision not to provide official checksums. I can see the value of having them so let's try to incorporate those in our new release process. -- Gilles Peskine Mbed TLS developer On 04/08/2020 19:05, Frank Bergmann via mbed-tls wrote: > Hi, > > 2.16.7 was released on github more than one month ago (2020-07-01). > But it is not listed on > - download archive at https://tls.mbed.org/download-archive > - release news at https://tls.mbed.org/tech-updates/releases > > Questions about that: > - Is it an "official" release even if it is not mentioned on release news? > - When will it be available in download archive? > - If there will be no more addings to download archive because now we'll > have to use github: > * Will there be separate releases GPL/Apache available? > * Will a signed/unsigned check sum be provided? > * Will the "new structure" as provided by tarball on github be kept > in future or was it just an accident? (e.g. main dir is named > "mbedtls-mbedtls-2.16.7") > > I started using mbed TLS with 2.16.6 but now I am confused. ;-) > > cheers, > Frank > >

5 years, 1 month

1
0
0 0

Availability of 2.16.7 in download archive

by Frank Bergmann

Hi, 2.16.7 was released on github more than one month ago (2020-07-01). But it is not listed on - download archive at https://tls.mbed.org/download-archive - release news at https://tls.mbed.org/tech-updates/releases Questions about that: - Is it an "official" release even if it is not mentioned on release news? - When will it be available in download archive? - If there will be no more addings to download archive because now we'll have to use github: * Will there be separate releases GPL/Apache available? * Will a signed/unsigned check sum be provided? * Will the "new structure" as provided by tarball on github be kept in future or was it just an accident? (e.g. main dir is named "mbedtls-mbedtls-2.16.7") I started using mbed TLS with 2.16.6 but now I am confused. ;-) cheers, Frank

5 years, 1 month

1
0
0 0

Re: [mbed-tls] Entropy & TRNG on the BGM13P32

by Steven Cooreman

Hi Youssouf, This is Steven with Silicon Labs. It sounds like you have questions that are very device-specific, and relate to Silicon Labs products. We do provide TRNG drivers for mbed TLS through Simplicity Studio and our software SDK. Please contact our support staff at www.silabs.com/support<http://www.silabs.com/support>, and they’ll do their best to help you out with your questions. Regards, -- Steven From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of youssouf sokhona via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: youssouf sokhona <youssouf.sokhona(a)hotmail.fr> Date: Tuesday, 4 August 2020 at 12:59 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Entropy & TRNG on the BGM13P32 CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi, everyone, First of all, I hope you are all healthy during this difficult time. I am working with Simplicity Studio IDE with MbedTLS and I am currently working on a project with a BGM13P32. I plan to perform a key exchange via bluetooth with the Diffie Hellman protocol. To start my project, I need an entropy source. I read the following on the BGM13P32 documentation "The TRNG is a non-deterministic random number generator based on a full hardware solution. The TRNG is validated with NIST800-22and AIS-31 test suites as well as being suitable for FIPS 140-2 certification (for the purposes of cryptographic key generation)." And I also read about the Random Number Generator "The Frame Controller (FRC) implements a random number generator that uses entropy gathered from noise in the RF receive chain.The data is suitable for use in cryptographic applications.Output from the random number generator can be used either directly or as a seed or entropy source for software-based random num-ber generator algorithms such as Fortuna" Knowing this, how can we use this to create entropy and then create a sequence of random numbers? I need to implement the MbedTLS_hardware_poll() function? Do I have to add another entropy, like real timing for example As you can see I am a bit confused actually. Can you help me out? Thanks in advance, and take care of yourself !

5 years, 1 month

1
0
0 0

Entropy & TRNG on the BGM13P32

by youssouf sokhona

Hi, everyone, First of all, I hope you are all healthy during this difficult time. I am working with Simplicity Studio IDE with MbedTLS and I am currently working on a project with a BGM13P32. I plan to perform a key exchange via bluetooth with the Diffie Hellman protocol. To start my project, I need an entropy source. I read the following on the BGM13P32 documentation "The TRNG is a non-deterministic random number generator based on a full hardware solution. The TRNG is validated with NIST800-22and AIS-31 test suites as well as being suitable for FIPS 140-2 certification (for the purposes of cryptographic key generation)." And I also read about the Random Number Generator "The Frame Controller (FRC) implements a random number generator that uses entropy gathered from noise in the RF receive chain.The data is suitable for use in cryptographic applications.Output from the random number generator can be used either directly or as a seed or entropy source for software-based random num-ber generator algorithms such as Fortuna" Knowing this, how can we use this to create entropy and then create a sequence of random numbers? I need to implement the MbedTLS_hardware_poll() function? Do I have to add another entropy, like real timing for example As you can see I am a bit confused actually. Can you help me out? Thanks in advance, and take care of yourself !

5 years, 1 month

1
0
0 0

Open & Read a file with a BGMQ

by youssouf sokhona

Morning, First of all, I hope you are all healthy during this difficult time. I am working with Simplicity Studio IDE and with Mbed TLS and I am currently working on a project with a BGM13P32. I plan to write in a file some parameters that will allow a key exchange by bluetooth (Diffie Hellman Protocol). I intend to make the BGM13P32 read this file, and these data to allow a key exchange. Is it possible to do that? If yes, how? Because I'm a total beginner Thank you, and take care of yourself !

5 years, 1 month

1
0
0 0

DTS session resumption and fragmentation

by Fatima, Fariya

Hi all, I have configured the max fragment length at the client and server to both 512. With this setting when I try to reconnect using a saved session at the client side, the ssl handshake doesn’t seem to happen. Below is the comment in the server code. /* We don't support fragmentation of ClientHello (yet?) */ The mbedtls code I am using is version 2.16.6. Are there any plans to support fragmentation of clienthello? Do let me know Regards, Fariya

5 years, 1 month

1
0
0 0

DTLS session resumption

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

5 years, 1 month

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

5 years, 2 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

5 years, 2 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

5 years, 2 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 >

5 years, 2 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 > >

5 years, 2 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…

5 years, 2 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

5 years, 2 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

5 years, 2 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

5 years, 2 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

5 years, 2 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, 2 months

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, 2 months

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 months

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, 2 months

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, 2 months

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 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 3 months

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]

5 years, 3 months

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

5 years, 3 months

1
0
0 0

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

by Gilles Peskine

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

5 years, 3 months

1
0
0 0

Working with a PEM file

by Thompson, Jeff

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 [cid:image001.gif@01D64974.02162CD0]

5 years, 3 months

1
0
0 0

Re: [mbed-tls] Using mbed without a client certificate

by Manuel Pegourie-Gonnard

Hi Jeff, if you don't want to provision a client certificate in your TLS client, all you have to do is to not call `mbedtls_ssl_conf_own_cert()` in your client code. Then the library will send an empty certificate list as required by the standard. Actually in the example code you have, if you look at the second and third argument in the call to `mbedtls_ssl_conf_own_cert()`, you should be able to remove all references to those arguments, and end up with a functional example without client certificates. Also, you might want to have a look at this example from our source, which is a simple client without client-side certificates: https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_client… Hope that helps, 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: 22 June 2020 16:03 To: 'mbed-tls(a)lists.trustedfirmware.org' <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Using mbed without a client certificate I'm usiing: #define MBEDTLS_VERSION_NUMBER 0x020D0100 #define MBEDTLS_VERSION_STRING "2.13.1" #define MBEDTLS_VERSION_STRING_FULL "mbed TLS 2.13.1" According to RFC5246: If no suitable certificate is available, the client MUST send a certificate message containing no certificates. That is, the certificate_list structure has a length of zero. How do I do this with mbedTLS? The example code I have has certificates in it and calls mbedtls_x509_crt_parse(), which wants a list of certificates and will reject a zero-length list. Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D64864.692FAD30]

5 years, 3 months

2
1
0 0

Re: [mbed-tls] BLE and Mbed TLS

by Janos Follath

Hi, The packet size limitations can be accommodated by using the Maximum Fragment Length extension (https://tools.ietf.org/html/rfc6066#section-4, enabled by MBEDTLS_SSL_MAX_FRAGMENT_LENGTH in Mbed TLS). In Mbed TLS this is only implemented for application data and DTLS handshake messages so far, and therefore you will need to use DTLS. Also the negotiation is driven by the client and it needs to be enabled both on the server and on the client. (See the documentation of mbedtls_ssl_conf_max_frag_len() for more details.) I hope that helps, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of "Fatima, Fariya via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org> Reply to: "Fatima, Fariya" <Fariya.Fatima(a)Carrier.com> Date: Tuesday, 23 June 2020 at 11:47 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] BLE and Mbed TLS Hi, Can anyone help if mbedTLS TLS/DTLS code would work on top of BLE (specifically SPP). I am not sure if the packet size limitation on SPP would make TLS work.. any pointers anyone? Would be really helpful. Regards, Fariya From: Fatima, Fariya Sent: Monday, June 15, 2020 9:21 AM To: 'mbed-tls(a)lists.trustedfirmware.org' <mbed-tls(a)lists.trustedfirmware.org> Subject: BLE and Mbed TLS Hi, I wanted to use TLS over BLE application. When I googled, I figured out that MbedTLS can work on BLE. If someone can share a sample application where-in MbedTLS APIs are used as part of a BT/BLE application, it will be of great help. Regards, Fariya

5 years, 3 months

2
2
0 0

Re: [mbed-tls] BLE and Mbed TLS

by Fatima, Fariya

Hi, Can anyone help if mbedTLS TLS/DTLS code would work on top of BLE (specifically SPP). I am not sure if the packet size limitation on SPP would make TLS work.. any pointers anyone? Would be really helpful. Regards, Fariya From: Fatima, Fariya Sent: Monday, June 15, 2020 9:21 AM To: 'mbed-tls(a)lists.trustedfirmware.org' <mbed-tls(a)lists.trustedfirmware.org> Subject: BLE and Mbed TLS Hi, I wanted to use TLS over BLE application. When I googled, I figured out that MbedTLS can work on BLE. If someone can share a sample application where-in MbedTLS APIs are used as part of a BT/BLE application, it will be of great help. Regards, Fariya

5 years, 3 months

1
0
0 0

Re: [mbed-tls] ECDH set custom private key

by Manuel Pegourie-Gonnard

Hi Oleksandr, I understand you want to validate your implementation against the test vectors in the cited reference. It's obvious, but just in case my reply is read out of context some day, I want to emphasize: what I'm recommending below is for testing purposes only, importing a private key from a public reference must never be done in production. In your situation the simplest way to proceed is probably to directly import the private and public key from the test vector to your ECDH context. For example (assuming the data in the reference is big-endian, and omitting error checking for brevity): static unsigned char private_a[32] = { 0x3f, 0x49, /* ... from the reference */ }; static unsigned char public_a[65] = { 0x04, /* this special value marks the start of an uncompressed public key */ 0x20, 0xb0, /* ... (public A(x) from the reference) */ 0xdc, 0x80, /* ... (public B(x) from the reference) */ }; static mbedtls_ecdh_context ctx_a; mbedtls_ecdh_init(&ctx_a); /* load the private/public key pair * this replaces mbedtls_ecdh_gen_public() */ mbedtls_mpi_read_binary( &ctx_a->d, private_a, sizeof( private_a ) ); /* should check errors! */ mbedtls_ecp_point_read_binary( &ctx_a->Q, public_a, sizeof( public_a ) ); /* should check errors! */ Doing the same with ctx_b and then exchanging public keys and computing the shared secret as usual, you should obtain values that match the reference. Again, this is only for validating against known test vectors. Importing a private key from a public reference must never be done in production. Hope that helps, Manuel. ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Oleksandr Nychyporuk via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 22 June 2020 15:33 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] ECDH set custom private key Hi, I wanna configure the ECDH algorithm to repeat the following keys: [image.png] I was able to configure the algorithm, generate private and public keys on both: client and server sides. And it works as expected. The secret keys are equal on both sides. But I did not manage to calculate the secret key that is on the picture. I do not know how to set these private keys. Could someone help me to do that? Thanks,

5 years, 3 months

1
0
0 0

Using mbed without a client certificate

by Thompson, Jeff

I'm usiing: #define MBEDTLS_VERSION_NUMBER 0x020D0100 #define MBEDTLS_VERSION_STRING "2.13.1" #define MBEDTLS_VERSION_STRING_FULL "mbed TLS 2.13.1" According to RFC5246: If no suitable certificate is available, the client MUST send a certificate message containing no certificates. That is, the certificate_list structure has a length of zero. How do I do this with mbedTLS? The example code I have has certificates in it and calls mbedtls_x509_crt_parse(), which wants a list of certificates and will reject a zero-length list. Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D64864.692FAD30]

5 years, 3 months

1
0
0 0

Re: [mbed-tls] mbed-tls Digest, Vol 4, Issue 15

by Oleksandr Nychyporuk

Attaching the keys from the picture: *7.1.2.1 P-256 Data Set 1* *Private A*: 3f49f6d4 a3c55f38 74c9b3e3 d2103f50 4aff607b eb40b799 5899b8a6 cd3c1abd *Private B*: 55188b3d 32f6bb9a 900afcfb eed4e72a 59cb9ac2 f19d7cfb 6b4fdd49 f47fc5fd *Public A(x):* 20b003d2 f297be2c 5e2c83a7 e9f9a5b9 eff49111 acf4fddb cc030148 0e359de6 *Public A(y)*: dc809c49 652aeb6d 63329abf 5a52155c 766345c2 8fed3024 741c8ed0 1589d28b *Public B(x)*: 1ea1f0f0 1faf1d96 09592284 f19e4c00 47b58afd 8615a69f 559077b2 2faaa190 *Public B(y)*: 4c55f33e 429dad37 7356703a 9ab85160 472d1130 e28e3676 5f89aff9 15b1214a *DHKey*: ec0234a3 57c8ad05 341010a6 0a397d9b 99796b13 b4f866f1 868d34f3 73bfa698 пн, 22 черв. 2020 о 16:33 <mbed-tls-request(a)lists.trustedfirmware.org> пише: > 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. ECDH set custom private key (Oleksandr Nychyporuk) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 22 Jun 2020 16:33:15 +0300 > From: Oleksandr Nychyporuk <olexandr.nychyporuk(a)gmail.com> > To: mbed-tls(a)lists.trustedfirmware.org > Subject: [mbed-tls] ECDH set custom private key > Message-ID: > <CAAjyQQ4kQ8J-iVSV_yputKD83G9Aj65fYEWJ= > ObPTeptXogghw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > I wanna configure the ECDH algorithm to repeat the following keys: > [image: image.png] > > I was able to configure the algorithm, generate private and public keys on > both: client and server sides. And it works as expected. The secret keys > are equal on both sides. > But I did not manage to calculate the secret key that is on the picture. I > do not know how to set these private keys. Could someone help me to do > that? > > Thanks, >

5 years, 3 months

1
0
0 0

ECDH set custom private key

by Oleksandr Nychyporuk

Hi, I wanna configure the ECDH algorithm to repeat the following keys: [image: image.png] I was able to configure the algorithm, generate private and public keys on both: client and server sides. And it works as expected. The secret keys are equal on both sides. But I did not manage to calculate the secret key that is on the picture. I do not know how to set these private keys. Could someone help me to do that? Thanks,

5 years, 3 months

1
0
0 0

Re: [mbed-tls] How to enable mbedtls complete debug logs?

by Srinivasa Rao Ragolu

Hi Hannes, See the output of ssl_client2 output with command line arguments Could you please help me in resolving the issue. Same source code on Ubuntu is working fine but not working on my embedded device(STM32MP157x-EV1) Your support is appreciated. =450a-certificate.pem.crt key_file=/certs/774a17950a-private.pem.key debug_leve . Seeding the random number generator... ok . Loading the CA root certificate ... ok (0 skipped) . Loading the client cert. and key... ok . Connecting to tcp/a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com/443... ok . Setting up the SSL/TLS structure...ssl_tls.c:0081: |3| set_timer to 0 ms ok . Performing the SSL/TLS handshake...ssl_tls.c:8084: |2| => handshake ssl_cli.c:3510: |2| client state: 0 ssl_tls.c:2755: |2| => flush output ssl_tls.c:2767: |2| <= flush output ssl_cli.c:3510: |2| client state: 1 ssl_tls.c:2755: |2| => flush output ssl_tls.c:2767: |2| <= flush output ssl_cli.c:0774: |2| => write client hello ssl_cli.c:0812: |3| client hello, max version: [3:3] ssl_cli.c:0703: |3| client hello, current time: 1592572806 ssl_cli.c:0821: |3| dumping 'client hello, random bytes' (32 bytes) ssl_cli.c:0821: |3| 0000: 5e ec bb 86 f1 65 15 c9 27 e1 12 b3 af 40 7d ab ^....e..'....@}. ssl_cli.c:0821: |3| 0010: 16 2e 28 f5 f6 e1 82 9b 2d 5c e7 93 e1 e6 e8 17 ..(.....-\...... ssl_cli.c:0874: |3| client hello, session id len.: 0 ssl_cli.c:0875: |3| dumping 'client hello, session id' (0 bytes) ssl_cli.c:0922: |3| client hello, add ciphersuite: cca8 ssl_cli.c:0922: |3| client hello, add ciphersuite: cca9 ssl_cli.c:0922: |3| client hello, add ciphersuite: ccaa ssl_cli.c:0922: |3| client hello, add ciphersuite: c02c ssl_cli.c:0922: |3| client hello, add ciphersuite: c030 ssl_cli.c:0922: |3| client hello, add ciphersuite: 009f ssl_cli.c:0922: |3| client hello, add ciphersuite: c0ad ssl_cli.c:0922: |3| client hello, add ciphersuite: c09f ssl_cli.c:0922: |3| client hello, add ciphersuite: c024 ssl_cli.c:0922: |3| client hello, add ciphersuite: c028 ssl_cli.c:0922: |3| client hello, add ciphersuite: 006b ssl_cli.c:0922: |3| client hello, add ciphersuite: c00a ssl_cli.c:0922: |3| client hello, add ciphersuite: c014 ssl_cli.c:0922: |3| client hello, add ciphersuite: 0039 ssl_cli.c:0922: |3| client hello, add ciphersuite: c0af ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a3 ssl_cli.c:0922: |3| client hello, add ciphersuite: c087 ssl_cli.c:0922: |3| client hello, add ciphersuite: c08b ssl_cli.c:0922: |3| client hello, add ciphersuite: c07d ssl_cli.c:0922: |3| client hello, add ciphersuite: c073 ssl_cli.c:0922: |3| client hello, add ciphersuite: c077 ssl_cli.c:0922: |3| client hello, add ciphersuite: 00c4 ssl_cli.c:0922: |3| client hello, add ciphersuite: 0088 ssl_cli.c:0922: |3| client hello, add ciphersuite: c02b ssl_cli.c:0922: |3| client hello, add ciphersuite: c02f ssl_cli.c:0922: |3| client hello, add ciphersuite: 009e ssl_cli.c:0922: |3| client hello, add ciphersuite: c0ac ssl_cli.c:0922: |3| client hello, add ciphersuite: c09e ssl_cli.c:0922: |3| client hello, add ciphersuite: c023 ssl_cli.c:0922: |3| client hello, add ciphersuite: c027 ssl_cli.c:0922: |3| client hello, add ciphersuite: 0067 ssl_cli.c:0922: |3| client hello, add ciphersuite: c009 ssl_cli.c:0922: |3| client hello, add ciphersuite: c013 ssl_cli.c:0922: |3| client hello, add ciphersuite: 0033 ssl_cli.c:0922: |3| client hello, add ciphersuite: c0ae ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a2 ssl_cli.c:0922: |3| client hello, add ciphersuite: c086 ssl_cli.c:0922: |3| client hello, add ciphersuite: c08a ssl_cli.c:0922: |3| client hello, add ciphersuite: c07c ssl_cli.c:0922: |3| client hello, add ciphersuite: c072 ssl_cli.c:0922: |3| client hello, add ciphersuite: c076 ssl_cli.c:0922: |3| client hello, add ciphersuite: 00be ssl_cli.c:0922: |3| client hello, add ciphersuite: 0045 ssl_cli.c:0922: |3| client hello, add ciphersuite: ccac ssl_cli.c:0922: |3| client hello, add ciphersuite: ccad ssl_cli.c:0922: |3| client hello, add ciphersuite: 00ab ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a7 ssl_cli.c:0922: |3| client hello, add ciphersuite: c038 ssl_cli.c:0922: |3| client hello, add ciphersuite: 00b3 ssl_cli.c:0922: |3| client hello, add ciphersuite: c036 ssl_cli.c:0922: |3| client hello, add ciphersuite: 0091 ssl_cli.c:0922: |3| client hello, add ciphersuite: c091 ssl_cli.c:0922: |3| client hello, add ciphersuite: c09b ssl_cli.c:0922: |3| client hello, add ciphersuite: c097 ssl_cli.c:0922: |3| client hello, add ciphersuite: c0ab ssl_cli.c:0922: |3| client hello, add ciphersuite: 00aa ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a6 ssl_cli.c:0922: |3| client hello, add ciphersuite: c037 ssl_cli.c:0922: |3| client hello, add ciphersuite: 00b2 ssl_cli.c:0922: |3| client hello, add ciphersuite: c035 ssl_cli.c:0922: |3| client hello, add ciphersuite: 0090 ssl_cli.c:0922: |3| client hello, add ciphersuite: c090 ssl_cli.c:0922: |3| client hello, add ciphersuite: c096 ssl_cli.c:0922: |3| client hello, add ciphersuite: c09a ssl_cli.c:0922: |3| client hello, add ciphersuite: c0aa ssl_cli.c:0922: |3| client hello, add ciphersuite: 009d ssl_cli.c:0922: |3| client hello, add ciphersuite: c09d ssl_cli.c:0922: |3| client hello, add ciphersuite: 003d ssl_cli.c:0922: |3| client hello, add ciphersuite: 0035 ssl_cli.c:0922: |3| client hello, add ciphersuite: c032 ssl_cli.c:0922: |3| client hello, add ciphersuite: c02a ssl_cli.c:0922: |3| client hello, add ciphersuite: c00f ssl_cli.c:0922: |3| client hello, add ciphersuite: c02e ssl_cli.c:0922: |3| client hello, add ciphersuite: c026 ssl_cli.c:0922: |3| client hello, add ciphersuite: c005 ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a1 ssl_cli.c:0922: |3| client hello, add ciphersuite: c07b ssl_cli.c:0922: |3| client hello, add ciphersuite: 00c0 ssl_cli.c:0922: |3| client hello, add ciphersuite: 0084 ssl_cli.c:0922: |3| client hello, add ciphersuite: c08d ssl_cli.c:0922: |3| client hello, add ciphersuite: c079 ssl_cli.c:0922: |3| client hello, add ciphersuite: c089 ssl_cli.c:0922: |3| client hello, add ciphersuite: c075 ssl_cli.c:0922: |3| client hello, add ciphersuite: 009c ssl_cli.c:0922: |3| client hello, add ciphersuite: c09c ssl_cli.c:0922: |3| client hello, add ciphersuite: 003c ssl_cli.c:0922: |3| client hello, add ciphersuite: 002f ssl_cli.c:0922: |3| client hello, add ciphersuite: c031 ssl_cli.c:0922: |3| client hello, add ciphersuite: c029 ssl_cli.c:0922: |3| client hello, add ciphersuite: c00e ssl_cli.c:0922: |3| client hello, add ciphersuite: c02d ssl_cli.c:0922: |3| client hello, add ciphersuite: c025 ssl_cli.c:0922: |3| client hello, add ciphersuite: c004 ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a0 ssl_cli.c:0922: |3| client hello, add ciphersuite: c07a ssl_cli.c:0922: |3| client hello, add ciphersuite: 00ba ssl_cli.c:0922: |3| client hello, add ciphersuite: 0041 ssl_cli.c:0922: |3| client hello, add ciphersuite: c08c ssl_cli.c:0922: |3| client hello, add ciphersuite: c078 ssl_cli.c:0922: |3| client hello, add ciphersuite: c088 ssl_cli.c:0922: |3| client hello, add ciphersuite: c074 ssl_cli.c:0922: |3| client hello, add ciphersuite: ccae ssl_cli.c:0922: |3| client hello, add ciphersuite: 00ad ssl_cli.c:0922: |3| client hello, add ciphersuite: 00b7 ssl_cli.c:0922: |3| client hello, add ciphersuite: 0095 ssl_cli.c:0922: |3| client hello, add ciphersuite: c093 ssl_cli.c:0922: |3| client hello, add ciphersuite: c099 ssl_cli.c:0922: |3| client hello, add ciphersuite: 00ac ssl_cli.c:0922: |3| client hello, add ciphersuite: 00b6 ssl_cli.c:0922: |3| client hello, add ciphersuite: 0094 ssl_cli.c:0922: |3| client hello, add ciphersuite: c092 ssl_cli.c:0922: |3| client hello, add ciphersuite: c098 ssl_cli.c:0922: |3| client hello, add ciphersuite: ccab ssl_cli.c:0922: |3| client hello, add ciphersuite: 00a9 ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a5 ssl_cli.c:0922: |3| client hello, add ciphersuite: 00af ssl_cli.c:0922: |3| client hello, add ciphersuite: 008d ssl_cli.c:0922: |3| client hello, add ciphersuite: c08f ssl_cli.c:0922: |3| client hello, add ciphersuite: c095 ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a9 ssl_cli.c:0922: |3| client hello, add ciphersuite: 00a8 ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a4 ssl_cli.c:0922: |3| client hello, add ciphersuite: 00ae ssl_cli.c:0922: |3| client hello, add ciphersuite: 008c ssl_cli.c:0922: |3| client hello, add ciphersuite: c08e ssl_cli.c:0922: |3| client hello, add ciphersuite: c094 ssl_cli.c:0922: |3| client hello, add ciphersuite: c0a8 ssl_cli.c:0934: |3| client hello, got 127 ciphersuites (excluding SCSVs) ssl_cli.c:0943: |3| adding EMPTY_RENEGOTIATION_INFO_SCSV ssl_cli.c:0992: |3| client hello, compress len.: 1 ssl_cli.c:0994: |3| client hello, compress alg.: 0 ssl_cli.c:0069: |3| client hello, adding server name extension: a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com ssl_cli.c:0186: |3| client hello, adding signature_algorithms extension ssl_cli.c:0271: |3| client hello, adding supported_elliptic_curves extension ssl_cli.c:0336: |3| client hello, adding supported_point_formats extension ssl_cli.c:0518: |3| client hello, adding encrypt_then_mac extension ssl_cli.c:0552: |3| client hello, adding extended_master_secret extension ssl_cli.c:0585: |3| client hello, adding session ticket extension ssl_cli.c:1071: |3| client hello, total extension length: 128 ssl_tls.c:3184: |2| => write handshake message ssl_tls.c:3343: |2| => write record ssl_tls.c:3423: |3| output record: msgtype = 22, version = [3:1], msglen = 429 ssl_tls.c:3426: |4| dumping 'output record sent to network' (434 bytes) ssl_tls.c:3426: |4| 0000: 16 03 01 01 ad 01 00 01 a9 03 03 5e ec bb 86 f1 ...........^.... ssl_tls.c:3426: |4| 0010: 65 15 c9 27 e1 12 b3 af 40 7d ab 16 2e 28 f5 f6 e..'....@}...(.. ssl_tls.c:3426: |4| 0020: e1 82 9b 2d 5c e7 93 e1 e6 e8 17 00 01 00 cc a8 ...-\........... ssl_tls.c:3426: |4| 0030: cc a9 cc aa c0 2c c0 30 00 9f c0 ad c0 9f c0 24 .....,.0.......$ ssl_tls.c:3426: |4| 0040: c0 28 00 6b c0 0a c0 14 00 39 c0 af c0 a3 c0 87 .(.k.....9...... ssl_tls.c:3426: |4| 0050: c0 8b c0 7d c0 73 c0 77 00 c4 00 88 c0 2b c0 2f ...}.s.w.....+./ ssl_tls.c:3426: |4| 0060: 00 9e c0 ac c0 9e c0 23 c0 27 00 67 c0 09 c0 13 .......#.'.g.... ssl_tls.c:3426: |4| 0070: 00 33 c0 ae c0 a2 c0 86 c0 8a c0 7c c0 72 c0 76 .3.........|.r.v ssl_tls.c:3426: |4| 0080: 00 be 00 45 cc ac cc ad 00 ab c0 a7 c0 38 00 b3 ...E.........8.. ssl_tls.c:3426: |4| 0090: c0 36 00 91 c0 91 c0 9b c0 97 c0 ab 00 aa c0 a6 .6.............. ssl_tls.c:3426: |4| 00a0: c0 37 00 b2 c0 35 00 90 c0 90 c0 96 c0 9a c0 aa .7...5.......... ssl_tls.c:3426: |4| 00b0: 00 9d c0 9d 00 3d 00 35 c0 32 c0 2a c0 0f c0 2e .....=.5.2.*.... ssl_tls.c:3426: |4| 00c0: c0 26 c0 05 c0 a1 c0 7b 00 c0 00 84 c0 8d c0 79 .&.....{.......y ssl_tls.c:3426: |4| 00d0: c0 89 c0 75 00 9c c0 9c 00 3c 00 2f c0 31 c0 29 ...u.....<./.1.) ssl_tls.c:3426: |4| 00e0: c0 0e c0 2d c0 25 c0 04 c0 a0 c0 7a 00 ba 00 41 ...-.%.....z...A ssl_tls.c:3426: |4| 00f0: c0 8c c0 78 c0 88 c0 74 cc ae 00 ad 00 b7 00 95 ...x...t........ ssl_tls.c:3426: |4| 0100: c0 93 c0 99 00 ac 00 b6 00 94 c0 92 c0 98 cc ab ................ ssl_tls.c:3426: |4| 0110: 00 a9 c0 a5 00 af 00 8d c0 8f c0 95 c0 a9 00 a8 ................ ssl_tls.c:3426: |4| 0120: c0 a4 00 ae 00 8c c0 8e c0 94 c0 a8 00 ff 01 00 ................ ssl_tls.c:3426: |4| 0130: 00 80 00 00 00 34 00 32 00 00 2f 61 32 67 37 74 .....4.2../a2g7t ssl_tls.c:3426: |4| 0140: 77 6d 71 6f 37 68 67 38 32 2d 61 74 73 2e 69 6f wmqo7hg82-ats.io ssl_tls.c:3426: |4| 0150: 74 2e 61 70 2d 73 6f 75 74 68 2d 31 2e 61 6d 61 t.ap-south-1.ama ssl_tls.c:3426: |4| 0160: 7a 6f 6e 61 77 73 2e 63 6f 6d 00 0d 00 16 00 14 zonaws.com...... ssl_tls.c:3426: |4| 0170: 06 03 06 01 05 03 05 01 04 03 04 01 03 03 03 01 ................ ssl_tls.c:3426: |4| 0180: 02 03 02 01 00 0a 00 18 00 16 00 19 00 1c 00 18 ................ ssl_tls.c:3426: |4| 0190: 00 1b 00 17 00 16 00 1a 00 15 00 14 00 13 00 12 ................ ssl_tls.c:3426: |4| 01a0: 00 0b 00 02 01 00 00 16 00 00 00 17 00 00 00 23 ...............# ssl_tls.c:3426: |4| 01b0: 00 00 .. ssl_tls.c:2755: |2| => flush output ssl_tls.c:2774: |2| message length: 434, out_left: 434 ssl_tls.c:2779: |2| ssl->f_send() returned 434 (-0xfffffe4e) ssl_tls.c:2807: |2| <= flush output ssl_tls.c:3476: |2| <= write record ssl_tls.c:3320: |2| <= write handshake message ssl_cli.c:1106: |2| <= write client hello ssl_cli.c:3510: |2| client state: 2 ssl_tls.c:2755: |2| => flush output ssl_tls.c:2767: |2| <= flush output ssl_cli.c:1499: |2| => parse server hello ssl_tls.c:4311: |2| => read record ssl_tls.c:2536: |2| => fetch input ssl_tls.c:2697: |2| in_left: 0, nb_want: 5 ssl_tls.c:2721: |2| in_left: 0, nb_want: 5 ssl_tls.c:2722: |2| ssl->f_recv(_timeout)() returned -80 (-0x0050) ssl_tls.c:4973: |1| mbedtls_ssl_fetch_input() returned -80 (-0x0050) ssl_tls.c:4344: |1| ssl_get_next_record() returned -80 (-0x0050) ssl_cli.c:1506: |1| mbedtls_ssl_read_record() returned -80 (-0x0050) ssl_tls.c:8094: |2| <= handshake failed ! mbedtls_ssl_handshake returned -0x50 Last error was: -0x50 - NET - Connection was reset by peer ssl_tls.c:8934: |2| => free ssl_tls.c:8999: |2| <= free Regards, Srinivas. [cid:e050759f-7151-4fb6-8259-848135ad05b0] ________________________________ From: Hannes Tschofenig <Hannes.Tschofenig(a)arm.com> Sent: 19 June 2020 18:35 To: Srinivasa Rao Ragolu <srinivasa(a)alifsemi.com> Subject: RE: How to enable mbedtls complete debug logs? Hi Srinivas, Here is a good summary: https://tls.mbed.org/kb/development/debugging-tls If you just run the examples (such as ssl_client2 and ssl_server2) on the command line then you just need to use a command line parameter to set the debug level. Ciao Hannes From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of Srinivasa Rao Ragolu via mbed-tls Sent: Friday, June 19, 2020 2:44 PM To: mbed-tls(a)lists.trustedfirmware.org Subject: [mbed-tls] How to enable mbedtls complete debug logs? Hi All, Please help me with the procedure, how to enable complete debug logs in mbedtls. Regards, Srinivas. [cid:image001.jpg@01D6464B.1CC8C6E0] 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.

5 years, 3 months

1
0
0 0

How to enable mbedtls complete debug logs?

by Srinivasa Rao Ragolu

Hi All, Please help me with the procedure, how to enable complete debug logs in mbedtls. Regards, Srinivas. [cid:42424919-ffb4-4795-981d-a54ca257f268]

5 years, 3 months

1
0
0 0

Mutual Authentication in TLS handshake - No client certificate passed

by Abhilash Iyer

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/ [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…, 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, 3 months

1
0
0 0

About raising an issue on mbedTLS forum

by Aditya Patwardhan

Hello Sir/Madam, I work in Espressif Systems. I am currently working on providing an alternate hardware RSA sign implementation for mbedtls software sign for Espressif's new chip ESP32S2. I have gone through mbedTLS API in detail but I dont see any option where I can only replace mbedTLS software sign function with our hardware sign function . I have gone through the issue https://tls.mbed.org/discussions/generic/using-an-external-rsa-private-key I have seen that there is a function named `mbedtls_pk_setup_rsa_alt` where we only register private key related function to the ALT_CTX which mbedtls uses to perform RSA sign. but this is not supported for TLS connections. I have seen that there is MBEDTLS_RSA_ALT option in mbedTLS where we can provide alternate function to many of mbedTLS API, but we do not want to change any of the other functions, just provide alternate implementation of hardware sign. If we go with this way, there will be lot of duplicate code which will be needed to be maintained. can mbedTLS provide option to use mbedtls_rsa_alt context in its file `pkparse.c` so as to allow rsa sign using an extrnal private key. Thanks and Regards, Aditya P.S. - I raised the same issue yesterday, my issue was rejected stating I have not subscribed to the mailing-list. But I had already done that. I tried to subscribe again and it also said you are already subscribed.

5 years, 3 months

1
0
0 0

Re: [mbed-tls] Link error when calling "altcp_tls_create_config_client"

by Janos Follath

These defines are needed when the platform doesn’t have standard functions like `calloc()` and `free()`. (You can find more details on the macros in `config.h`.) Regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of songwei fu via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: "songwei.fu(a)web.de" <songwei.fu(a)web.de> Date: Wednesday, 17 June 2020 at 13:41 To: "Kaul, Martin" <Martin.Kaul(a)leuze.com> Cc: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] Link error when calling "altcp_tls_create_config_client" Thanks Martin. It solved my problem! By adding $(CHIBIOS)/os/various/syscalls.c in the makefile and removing following defines, the linker error is gone. #define MBEDTLS_PLATFORM_C #define MBEDTLS_PLATFORM_MEMORY #define MBEDTLS_PLATFORM_CALLOC_MACRO chHeapAlloc #define MBEDTLS_PLATFORM_FREE_MACRO chHeapFree Now I wonder when these defines are needed? I thought I need to port them to the OS-specific memory allocation. like in freeRTOS, it would be "pvPortCalloc", and for chibios it would be chHeapAlloc. Anybody can give me some hint? -- Songwei Gesendet: Mittwoch, 17. Juni 2020 um 12:12 Uhr Von: "Kaul, Martin" <Martin.Kaul(a)leuze.com> An: "songwei.fu(a)web.de" <songwei.fu(a)web.de> Betreff: AW: [mbed-tls] Link error when calling "altcp_tls_create_config_client" Hi, _sbrk is need when you using heap memory, for example using malloc() – see following discussion in stackoverflow: https://stackoverflow.com/questions/32446814/undefined-reference-to-sbrk-in… Maybe that helps. Best regards Martin Von: mbed-tls [mailto:mbed-tls-bounces@lists.trustedfirmware.org] Im Auftrag von songwei fu via mbed-tls Gesendet: Mittwoch, 17. Juni 2020 11:49 An: mbed-tls(a)lists.trustedfirmware.org Betreff: [mbed-tls] Link error when calling "altcp_tls_create_config_client" Hi guys, I am new to the list and also to mbedTLS. Now I am trying to port mbedTLS to chibiOS. And when I called altcp_tls_create_config_client(cert, sizeof(cert)), I got a link error like following: c:/chibistudio/tools/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m\libg.a(lib_a-sbrkr.o): In function `_sbrk_r': sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk' And these are my settings: #define MBEDTLS_PLATFORM_C #define MBEDTLS_PLATFORM_MEMORY #define MBEDTLS_PLATFORM_CALLOC_MACRO chHeapAlloc #define MBEDTLS_PLATFORM_FREE_MACRO chHeapFree where chHeapAlloc and chHeapFree are the memory allocation functions from chibios. (1) Did I miss some settings? or i did something wrong? (2) I did not find much information about the porting from chibios side. Does anybody know where I can look for reference projects/docs? Any suggestion will be appreciated. Thanks. Songwei

5 years, 3 months

2
1
0 0

Re: [mbed-tls] Link error when calling "altcp_tls_create_config_client"

by songwei.fu＠web.de

5 years, 3 months

1
0
0 0

Re: [mbed-tls] Link error when calling "altcp_tls_create_config_client"

by Janos Follath

Hi Songwei, Welcome to the list and thank you for your interest in Mbed TLS! I found a similar issue on stack overflow: https://stackoverflow.com/questions/28895703/sbrk-function-not-found-when-p… Is this the same issue as yours? Regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of songwei fu via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: "songwei.fu(a)web.de" <songwei.fu(a)web.de> Date: Wednesday, 17 June 2020 at 10:49 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Link error when calling "altcp_tls_create_config_client" Hi guys, I am new to the list and also to mbedTLS. Now I am trying to port mbedTLS to chibiOS. And when I called altcp_tls_create_config_client(cert, sizeof(cert)), I got a link error like following: c:/chibistudio/tools/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m\libg.a(lib_a-sbrkr.o): In function `_sbrk_r': sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk' And these are my settings: #define MBEDTLS_PLATFORM_C #define MBEDTLS_PLATFORM_MEMORY #define MBEDTLS_PLATFORM_CALLOC_MACRO chHeapAlloc #define MBEDTLS_PLATFORM_FREE_MACRO chHeapFree where chHeapAlloc and chHeapFree are the memory allocation functions from chibios. (1) Did I miss some settings? or i did something wrong? (2) I did not find much information about the porting from chibios side. Does anybody know where I can look for reference projects/docs? Any suggestion will be appreciated. Thanks. Songwei

5 years, 3 months

1
0
0 0

Link error when calling "altcp_tls_create_config_client"

by songwei.fu＠web.de

5 years, 3 months

1
0
0 0

mbedtls_ssh_handshake error -0X50 when connecting to AWS

by Srinivasa Rao Ragolu

Hi All, I am working on Renesas RZA2M embedded board with Linux. It has limited memory of 6MB flash(R-Only) I am using mbedtls version 2.16.5 for aws iot sdk for embedded c according to https://docs.aws.amazon.com/iot/latest/developerguide/iot-embedded-c-sdk.ht… When I run sample application, it is taking 15 secs for "Seeding random generator number..." and throwing below error $ ./subscribe_publish_sample AWS IoT SDK Version 3.0.1- DEBUG: main L#159 rootCA /root/../certs/AmazonRootCA1.pem DEBUG: main L#160 clientCRT /root/../certs/774a17950a-certificate.pem.crt DEBUG: main L#161 clientKey /root/../certs/774a17950a-private.pem.key Connecting... DEBUG: iot_tls_connect L#130 . Seeding the random number generator... DEBUG: iot_tls_connect L#138 . Loading the CA root certificate ... DEBUG: iot_tls_connect L#144 ok (0 skipped) DEBUG: iot_tls_connect L#146 . Loading the client cert. and key... DEBUG: iot_tls_connect L#159 ok DEBUG: iot_tls_connect L#161 . Connecting to a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com/443... DEBUG: iot_tls_connect L#180 ok DEBUG: iot_tls_connect L#182 . Setting up the SSL/TLS structure... DEBUG: iot_tls_connect L#223 SSL state connect : 0 DEBUG: iot_tls_connect L#226 ok DEBUG: iot_tls_connect L#228 SSL state connect : 0 DEBUG: iot_tls_connect L#229 . Performing the SSL/TLS handshake... ERROR: iot_tls_connect L#232 failed ! mbedtls_ssl_handshake returned -0x50 ERROR: main L#190 Error(-4) connecting to a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com:443 For detailed debug log using ssl_client2, go through https://pastebin.com/mNXhB0xj<https://github.com/ARMmbed/mbedtls/issues/url> https://pastebin.com/mNXhB0xj my client device specifications $ cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 1 (v7l) BogoMIPS : 1056.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x4 CPU part : 0xc09 CPU revision : 1 Hardware : Generic R7S9210 (Flattened Device Tree) Revision : 0000 Serial : 0000000000000000 $ free total used free shared buffers cached Mem: 7544 4484 3060 40 0 304 -/+ buffers/cache: 4180 3364 Swap: 0 0 0 I am not getting any help to resolve this issue and spending days and days. I am suspecting the issue might be timing related (or) cpu clock related (or) memory footprint related (or) something else I need this forum help badly to resolve the issue. Please ping me if you need any other data. Thanks in advance, Srinivas. Regards, Srinivas. [cid:1eddf249-06f8-4cbd-a3e2-9c22437fd27f]

5 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls