PolarSSL is now part of ARM Official announcement and rebranded as mbed TLS.

Sharing SSL data between threads and multiple connections

Oct 27, 2013 15:30
Evgeny Baskakov

Hi guys,

I have a server app that keeps multiple connected clients each working through SSL. It also has 2 threads: 1st one accepts connections, performs SSL handshake, stores new clients and reads incoming data via SSL; the 2nd one writes data back (also via SSL).

My question is: what PolarSSL data can be shared between connected clients in multi-threaded environment? Clearly, ssl_context must be private to a connection and race-protected.

What about the rest of the control data? My server uses these to establish a connection:

entropy_context entropy;
ctr_drbg_context ctr_drbg;
x509_crt srvcert;
pk_context pkey;
ssl_cache_context cache;

Can I re-use these variables for handshaking new connections while there are existing clients reading/writing via SSL?


Oct 28, 2013 14:49
Paul Bakker

If you use the PolarSSL 1.3 branch and have POLARSSL_THREADING_C enabled (and either the pthread implementation or your own), most race issues are handled already. And they are mentioned in the API documentation.

All calls manipulating those contexts should be made 'thread-safe'. The following are guarded if you use POLARSSL_THREADING_C:

  • entropy_func() on a entropy_context
  • operations on a pk_context that modify the internal cached values of the key
  • ssl_cache_get() and ssl_cache_set() on a ssl_cache_context

Not handled by default:

  • ctr_drbg_random()
  • x509_crt as they are not changed after parsing and thus thread-safe
Oct 28, 2013 15:02
Evgeny Baskakov

Thank you, Paul.

Am I right that these global variables can be used for handshaking new connections, while there are existing SSL connections?


Oct 28, 2013 15:27
Paul Bakker

Yes, as long as you use POLARSSL_THREADING_C with a proper threading implementation AND you mutex the function you give to ssl_set_rng() (probably a selfmade mutexed version of ctr_drbg_random()).