- mbed-tls - lists.trustedfirmware.org

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

4 years, 11 months

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

4 years, 11 months

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

4 years, 11 months

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

4 years, 11 months

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

4 years, 11 months

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

4 years, 11 months

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]

4 years, 11 months

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

4 years, 11 months

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

4 years, 11 months

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

4 years, 11 months

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)

4 years, 11 months

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

4 years, 11 months

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

4 years, 11 months

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

4 years, 11 months

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

4 years, 11 months

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

4 years, 11 months

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

4 years, 12 months

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

4 years, 12 months

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

4 years, 12 months

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

4 years, 12 months

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

Test

by Manu Abraham

Test mail

5 years

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

2025

2024

2023

2022

2021

2020

mbed-tls