Products > Embedded Computing

Anyone here familiar with MbedTLS?

<< < (4/4)

Siwastaja:
Maybe I'll just update here if someone's interested.

Got MbedTLS running and working, obviously it was non-trivial, but no more than 2-3 days of extra work. This is partial list of issues I faced:
* As usual, the few important interface functions user needs to supply are completely or partially undocumented. Would have been 10 minutes job: for example: mbedtls_hardware_poll (RNG callback): function prototype is non-trivial and the four arguments are completely undocumented, you need to guess
* Examples are either too simple or too complex. You have to shuffle between ssl_client1 and ssl_client2 examples.
* PSA is mandatory in TLS1.3, which means both enabling it and remembering psa_crypto_init()
(I still have no freaking idea what PSA is. I Google every stupid acronym for 2-3 minutes after which I timeout myself. For PSA, the best explanation was that it exists for "demystification".)
* With read callback functions, timeout of 0 does not mean instant return, but infinite timeout (blocking call) instead.
* Many different errors return the same error code, so you need to either write a logging system suitable for your use case, or modify the code to spread the error codes out
* Documentation makes it appear like TLS1_3_COMPATIBILITY MODE is for some weird middlebox thing. In reality, OpenSSL (so basically all servers) seem to require compatibility mode enabled. Enable it.
* SESSION TICKETS must be enabled; documentation makes it appear like some sort of optional feature. Doesn't work without. No need to write any callbacks.
* MbedTLS returns various error codes from mbedtls_ssl_read even when there is no error. You need to treat them as valid zero count reads. There is no maintained list of all possible "FYI" "errors". MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET is one of the fun ones; called experimental error code which might get modified or removed any time. MBEDTLS_ERR_SSL_WANT_READ is at least understandable and somewhat analogous to WOULDBLOCK from the POSIX world.
* With the limited RAM in embedded, it's a good idea to enable SSL_MAX_FRAGMENT_LENGTH extension, and configure MBEDTLS_SSL_IN_CONTENT_LEN and _OUT_CONTENT_LEN to something less than the default 16384.

But hey, the thing seems to work. And I can now confirm that with all EC keys, none of the RSA stuff is required.

Siwastaja:
Another random comment.

For ****s sake, I have been banging my head on the wall about the incompatibility of EC curve support, as mbedTLS and openssl seemingly do not agree at all what is available. This was supposed to be standardized.

Turns out, people have just invented different nicknames for the exact same curves, and those who know are either lazy or sadistic not to ever mention it anywhere.

Now I truly hope Google will find this ****ing post when the next victim googles this:
Keywords: TLS, EC curves, ECDHE, ECDSA, secp256r1, prime256v1
Fact: secp256r1 IS THE SAME AS prime256v1

No wonder how all the key generation tutorials used this mysterious "nonstandard" prime256v1 curve. It was standard after all, and definitely supported by mbedtls.

Nominal Animal:

--- Quote from: Siwastaja on January 19, 2023, 04:38:33 pm ---For ****s sake, I have been banging my head on the wall about the incompatibility of EC curve support, as mbedTLS and openssl seemingly do not agree at all what is available. This was supposed to be standardized.
--- End quote ---
I feel your pain.  I have felt this exact pain too.

Pretty exactly a decade ago I had issues with OpenSSL and GnuTLS cipher suite compatibility selection (on the server software side, software supporting both libraries).  I even went as far as look into rewriting GnuTLS's cipher suite listing spec and selection algorithm, but as the proper cipher selection was more important to me than my users, and there was no way in hell the OpenSSL folks would have accepted any suggestions from me no matter how small or backwards-compatible, I decided I had to let it go.

(The GnuTLS devs were very nice and friendly, though.)

Navigation

[0] Message Index

[*] Previous page