Session renegotiation

Mbed TLS Generic
1

Dear All,

I would like to perform DTLS session renegotiation on the server and the client side.
Is it possible to perform the renegotiation and exchange data with the currently available context at the same time?
Could anyone provide an example for client and server code?

Thanks a lot.
Best regards,
Okba

2

Dear @okba,
Mbed TLS is supplied with several sample applications.
It contains sample applications for dtls_server and dtls_client, which are simple use cases for dtls negotiation, without rebegotiation. You could simply add to the dtls_client a call to mbedtls_ssl_renegotiate(), and configure your client to support renegotiation, and it should work.
Regards,
Mbed TLS Team member
Ron

3

Dear Ron,

I called mbedtls_ssl_renegotiate() after that the data is not being sent.
Here is my code:

Client code after establishing the first handshake:

mbedtls_ssl_renegotiate(&ssl);

    while (1) {
      do ret = mbedtls_ssl_write( &ssl, (unsigned char *) MESSAGE, len );
      while( ret == MBEDTLS_ERR_SSL_WANT_READ ||
             ret == MBEDTLS_ERR_SSL_WANT_WRITE );
    }

Server code after establishing the first handshake :

while (1) {
      do ret = mbedtls_ssl_read( &ssl, buf, len );
      while( ret == MBEDTLS_ERR_SSL_WANT_READ ||
             ret == MBEDTLS_ERR_SSL_WANT_WRITE );
    }

I am expecting with this code that after establishing the first handshake, the client and the server will renegotiate
and the client will keep always sending messages with the new provided keying material.

This is what I get on wireshark, the data is not being sent after the renegotiation :

image

Best regards,
Okba

4

Hi okba,
Have you configured your client to support renegotiation?

mbedtls_ssl_conf_renegotiation( &conf, MBEDTLS_SSL_RENEGOTIATION_ENABLED );

Note that renegotiation, once TLS handshake is established, is encrypted, so you won’t see the renegotiation message in WireShark.
It is better you enable SSL logs in your client, as described in this article.

5

Dear Ron,

Thank you very much it is working now.
In my application I have a constraint that while renegotiating, in a parallel way the client and the server need to keep exchanging data. At the moment where the renegotiation is finished, they switch to use the new keying material.

Is it possible to do that?

for example in the client I create two threads one for the renegotiation and one for sending data like the following :

Renegotiation Thread :
mbedtls_ssl_renegotiate(&ssl);
Sending Data Thread:

while (1) {
do ret = mbedtls_ssl_write( &ssl, (unsigned char *) MESSAGE, len );
while( ret == MBEDTLS_ERR_SSL_WANT_READ ||
ret == MBEDTLS_ERR_SSL_WANT_WRITE );
}

Best regards,
Okba

6

Hi Okba,
If I understand your use case, there shouldn’t be an issue when you use multithreadin with Mbed TLS. As long as you define MBEDTLS_THREADING_C and you define your mutex.
You should,however, protect your ssl context, as it is being accessed from both renegotiation and data writing. I do see a possible issue, that you are writing data to the server with one keying material, and the server already changed the keying material after renegotiation. This is probably why you need to protect the whole ssl context, and not just your write \ read callbacks.
Regards,
Mbed TLS Team member
Ron