Mbedtls_ssl_config structure in multi-threaded/multi-user environment

We are using mbedTLS in a multi-threaded/multi-user server (Linux/ARM) environment. My understanding is that the mbedtls_ssl_config structure is a global structure and mbedtls_ssl_context is per connection.

However, the mbedtls_ssl_config structure also seems to contain per-connection data (PSK, identity hint, etc).

Does the mbedTLS library guarantee that these values are thread-safe? Or do we need to implement our own locking to guarantee that only a single connect request is accessing these values. If mbed is protecting these fields, can you point me to the relevant areas where this is done?

Hi @ddemoney
Thank you for your question and I apologize for delay in reply.

Your understanding is correct that mbedtls_ssl_config is a global structure and that mbedtls_ssl_context is a per connection struct.
As mentioned in the function description:

 * \note           Currently clients can only register one pre-shared key.
 *                 In other words, the servers' identity hint is ignored.
 *                 Support for setting multiple PSKs on clients and selecting
 *                 one based on the identity hint is not a planned feature but
 *                 feedback is welcomed.

It is probably because the assumption was that a client would register only to one server using PSK.
Note that it is not recommended to modify the configuration while it is in use, as it may result in undefined behavior.

If your device is a server, you can use mbedtls_ssl_conf_psk_cb() so you can register your own callback for parsing the client identity hint and choose the relevant PSK accordingly.

If your device is a client, and you must absolutely need to support several connections with servers using several PSKs, then the current solution is for you to have a separate mbedtls_ssl_config structure per connection. This is not optimal obviously, and you may file an enhancement request in our github repository to support server identity hint.

I hope this answers your question, and again, I apologize for delay.

Regards,
Mbed TLS Team member
Ron