Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
TLS session ID re-use broken in 7.77.0
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Paul Groke via curl-library <curl-library_at_cool.haxx.se>
Date: Mon, 07 Jun 2021 12:12:27 +0200
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
Received on 2021-06-07
Date: Mon, 07 Jun 2021 12:12:27 +0200
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
Received on 2021-06-07