Hi Team
I am investigating the move from MbedTLS 2.25 to 3.6, however, our client uses the 2.25 currently (looks like they prefer to stay with it) and I need to provide convincing proof to move to 3.6 considering the upgrade issues that might arise. Any suggestions here that is convincing proof to do the migration to 3.6? I would appreciate your comments. Thanks
Michael
Hi Michael,
Mbed TLS 2.25 has many known bugs, including security vulnerabilities. You can find them listed in the changelog at https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-2.28/ChangeLog
Those bugs are fixed in the backward-compatible branch mbedtls-2.28, which is still receiving patches for now. However, the end-of-life of this branch is this month. (I expect we'll make one last release with bug fixes that we haven't released yet.) So it's not worth upgrading to 2.28 at this point, and you should move directly to mbedtls-3.6 (long-time support branch maintained until at least March 2027).
You can find a guide to the incompatible changes between Mbed TLS 2.x and 3.x at https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-3.6/docs/3.0-migration-guid... . In addition, the Mbed TLS 3.6 branch is the last one that has mbedtls_xxx legacy APIs for cryptography: starting with Mbed TLS 4.0, only PSA APIs will be available for cryptography. In 3.6, both APIs are present. So if you're going to do a nontrivial migration, you might as well migrate to something that can then work in 4.x. You can find a guide to migrating to PSA crypto APIs in https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-3.6/docs/psa-transition.md
Best regards,
Send them this link: https://mbed-tls.readthedocs.io/en/latest/security-advisories/ -Michael
From: Michael Khoyilar via mbed-tls mbed-tls@lists.trustedfirmware.org Sent: Tuesday, December 3, 2024 10:45 AM To: mbed-tls@lists.trustedfirmware.org Subject: [mbed-tls] MbedTLS 2.5 vs MbedTLS 3.6
Hi Team
I am investigating the move from MbedTLS 2.25 to 3.6, however, our client uses the 2.25 currently (looks like they prefer to stay with it) and I need to provide convincing proof to move to 3.6 considering the upgrade issues that might arise. Any suggestions here that is convincing proof to do the migration to 3.6? I would appreciate your comments. Thanks
Michael
Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not an intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you.
Hello All,
I have a product which uses MbedTLS 2.16.2.
How different is 2.28? Is it just a case of dropping in new files, with the same API so everything should still work?
We see no functional issues at all with 2.16.2.
I also have a note on the project:
=== Note that MbedTLS cannot be updated beyond 2.16 due to this https://github.com/OpenVPN/openvpn/commit/110eee0288cff0720952a2cf16c4fb191d... although there is a disagreement on this: Why would the Apache2.0 license be a problem? It is more permissive than GPLv2 and does not have a copy left requirement as the GPL licenses do. It does not require that you redistribute the source code and any modifications that you have made to it, only that you include a description of those changes in any copies of the code that you do distribute. It may be used commercially without any requirement that the rest of the project in which it is used is covered by the same license. ===
Is the above relevant? The product is a commercial one.
Thank you in advance.
Peter
Hi Peter,
Mbed TLS 2.28 is fully API-compatible with 2.16 and has many bug fixes including security fixes. But as noted earlier, 2.28 reaches its end-of-life this month (or whenever we do that last 2.28 release, which I suspect will happen in early 2025).
Regarding the license, we stopped offering the GPLv2 for a while, but we've gone back to offering a dual license (GPLv2 or Apache 2.0, at your choice). I can't offer any legal advice, but generally Apache is suitable for use in commercial products, whereas GPL is very constraining.
Best regards,
Hello!
As the person who added that warning in OpenVPN, I can talk a bit about the second half of your e-mail.
=== Note that MbedTLS cannot be updated beyond 2.16 due to this https://github.com/OpenVPN/openvpn/commit/110eee0288cff0720952a2cf16c4fb 191d0bd616 although there is a disagreement on this: Why would the Apache2.0 license be a problem? It is more permissive than GPLv2 and does not have a copy left requirement as the GPL licenses do. It does not require that you redistribute the source code and any modifications that you have made to it, only that you include a description of those changes in any copies of the code that you do distribute. It may be used commercially without any requirement that the rest of the project in which it is used is covered by the same license. ===
My very layman understanding that is absolutely not legal advice: The problem is that if you link a GPLv2-licensed program with a library, you would have to distribute the whole thing under the GPLv2 license. But the Apache2.0 license is not compatible with GPLv2 due to the patent clause. OpenVPN has a special exemption that allows linking with OpenSSL but not for mbed TLS.
However, starting from OpenVPN v2.6.4, an exemption has been added so that under certain conditions, you may link OpenVPN with Apache2.0 libraries. See https://github.com/OpenVPN/openvpn/blob/v2.6.4/COPYING (and as of 2.6.10 I remembered to remove the warning from README.mbedtls)
Of course, now that newer versions of mbed TLS can be licensed under GPLv2 again, you could also just do that.
If you have further questions, you should probably address them to the OpenVPN project.
Best regards, Max Fillinger
mbed-tls@lists.trustedfirmware.org
-
Gilles Peskine -
Maximilian Fillinger -
Michael Khoyilar -
Michael Thomas -
Peter