Hi,

after updating to libcurl 7.77.0, TLS session ID re-use stopped working for our 
application. With older libcurl versions only the first transfer to an HTTPS 
server would do the full TLS handshake and later ones would reuse the session 
ID. With libcurl 7.77.0 we see a full handshake every time.

This seems to be related to the changes made for 
https://hackerone.com/reports/1180380

What our application does is relatively simple:
* Create a "share" object with CURL_LOCK_DATA_SSL_SESSION and 
CURL_LOCK_DATA_DNS enabled.
* In multiple threads:
  * Create an "easy" object which is using the one central "share" object.
  * Use the "easy" object to do HTTPS transfers (same server in all threads).

We have a simple test which checks if TLS session re-use works, which does 
(almost) the same, only with a single thread:
* Create a "share" object with CURL_LOCK_DATA_SSL_SESSION and 
CURL_LOCK_DATA_DNS enabled.
* Create two "easy" objects using that "share".
* Do a transfer to an HTTPS server using the first easy object.
* Do a transfer to the same HTTPS server using the second easy object.
* Verify that we see a "SSL re-using session ID" debug message for the 2nd 
transfer.
* Destroy both "easy" objects.

With libcurl 7.77.0 this test fails.

The repeated full TLS handshakes are causing a non-trivial amount of CPU load 
on our servers. If I understand the code correctly, the session ID cache entry 
is deleted when the "easy" is detached from the "multi" (in our case: the 
private "multi" instance owned by the "easy" object). So I wouldn't know how to 
work around this. We could create & use our own "multi" object, but the way the 
API works we would still have to detach the "easy" object after every transfer 
(or at least when starting a new transfer). Which means the entry would still 
be removed from the session ID cache.

Is there any way to work around this? And if not, would it be possible to fix 
this in libcurl so that session ID re-use works again?

Regards,
Paul Groke
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Reply via email to