[yegorich]

Fixes #1181.

Mbed TLS 4.0 moved the cryptography into TF-PSA-Crypto, and the random generator is now internal to
PSA:

• the entropy and CTR-DRBG APIs are private;
• mbedtls_ssl_conf_rng() was removed;
• mbedtls_pk_parse_keyfile() no longer takes RNG arguments.

So ext/tls/tls-mbed.c no longer compiles against 4.x. This PR adds 4.x support and keeps Mbed TLS
2.x and 3.x working. The 4.x changes are selected with MBEDTLS_VERSION_MAJOR.

Commits

1. rfc.tls - Support Mbed TLS 4.x
   • With 4.x, the per-connection entropy and CTR-DRBG contexts are not set up, and
     mbedtls_ssl_conf_rng() is not called.
   • With 4.x, the 3-argument mbedtls_pk_parse_keyfile() is used.
   • psa_crypto_init(), which 4.x requires, was already called at module initialization.
   • configure finds the crypto library with psa_crypto_init() instead of
     mbedtls_ctr_drbg_init(), which is private in 4.x, and also tries libtfpsacrypto.
2. rfc.tls - Add an AES-encrypted test key for Mbed TLS 4.x
   • The server key in ext/tls/data/test-key.pem is encrypted with PBES2 + 3DES. Mbed TLS 4.x
     removed DES/3DES, so it can't load the key, the handshakes fail, and the test then waits forever
     in the server thread.
   • Mbed TLS 2.x can't decrypt AES-encrypted keys, so I didn't replace the key. Instead,
     data/test-key-aes.pem contains the same key encrypted with AES-256-CBC. The test tries it
     first and falls back to test-key.pem, and data/README explains how to regenerate it.

Key encryption	2.28	3.6	4.1
test-key.pem (3DES)	ok	ok	not supported
test-key-aes.pem (AES-256-CBC)	not supported	ok	ok

Testing

Built from this branch with ./DIST gen and ./configure --with-tls=mbedtls on Linux x86_64 (gcc
11), against Mbed TLS 2.28.0 (Ubuntu), 3.6.7 and 4.1.1. There are no warnings in tls-mbed.c, and
with 4.1.1 the module links libtfpsacrypto.

make check in ext/tls passes with all three versions: bind, loading the private key and
certificate, connect with certificate verification, the 64 KiB transfer, server shutdown, and poll.

Note on CI: Homebrew's mbedtls formula is already 4.2.0, with 3.6 now in mbedtls@3. The macOS
jobs install mbedtls and still pass, so I suspect configure doesn't find Mbed TLS there and
builds without TLS support. I couldn't check the job logs to confirm. With this PR, the macOS jobs
should build and test the TLS module with 4.x again.

Not changed: --with-tls=mbedtls-internal still downloads Mbed TLS 3.6.4. Moving it to 4.x would
need changes in tools/tls, because the include layout has changed (tf-psa-crypto/); that seemed
better as a separate step.

I didn't add a ChangeLog entry, since you usually write those yourself.

[bitbloxhub]

https://lists.trustedfirmware.org/archives/list/mbed-tls@lists.trustedfirmware.org/thread/YPIGCB7WN6GCHOGEGKOJXUYAP7OK527W/#BSRM3JY6JFNWWEHKMY4JQQON5QB3LP5U
MbedTLS may stop development in April 2027, so we may want to move off of it entirely.
See also: NixOS/nixpkgs#574931.

[shirok]

Wow, thanks for the info @bitbloxhub . It's sad that even such important OSS is struggling to secure resources.

I still intend to merge this. Our TLS layer is already written to support multiple subsystems, so we can simultaneously develop alternatives (maybe openSSL?)

[omasanori]

OpenSSL and LibreSSL would be primary candidates. If the footprint is important, wolfSSL or s2n may be suitable. Other candidates are NSS (Mozilla), GnuTLS, Schannel (Windows), Secure Transport (macOS), etc.