Re: TLS session ID re-use broken in 7.77.0
I've found the same issue on Linux when using OpenSSL with TLS 1.2. I've opened a Github issue for it: https://github.com/curl/curl/issues/7222 Gergely Nagy Head of Core Team Email: n...@tresorit.com<mailto:n...@tresorit.com> Encrypt, Sync, Share, Control. www.tresorit.com<https://www.tresorit.com> [https://prodfrontendcdn.azureedge.net/media-storage/20180601142800960logo.png] Tresorit AG | Minervastrasse 3 | 8032 Zurich | Switzerland The content of this message is confidential. If you are not the intended recipient, please notify us immediately by telephoning or e-mailing the sender and delete this message. You should not copy this email or use it for any purpose nor disclose its contents to any other person. While we have put efforts into ensuring that the message is error and virus-free, the integrity and security of this email cannot be guaranteed over the Internet. Therefore, the sender does not accept any liability for any damage caused by this message. To learn more about how we process your data, please see our Privacy Policy<https://tresorit.com/legal/privacy-policy>. From: curl-library on behalf of Daniel Jeliński via curl-library Sent: Tuesday, June 8, 2021 15:19 To: libcurl development Cc: Daniel Jeliński Subject: Re: TLS session ID re-use broken in 7.77.0 Simple repro: >curl -vI --http1.1 https://example.com/[1-3] -H"Connection:close" output of the old CURL version contains "* SSL re-using session ID"; output of 7.77.0 does not. Wireshark confirms that the old version sent PSK in client hello, the new version did not. curl 7.77 downloaded here: https://curl.se/windows/dl-7.77.0_2/curl-7.77.0_2-win64-mingw.zip Regards, Daniel --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: TLS session ID re-use broken in 7.77.0
Simple repro: >curl -vI --http1.1 https://example.com/[1-3] -H"Connection:close" output of the old CURL version contains "* SSL re-using session ID"; output of 7.77.0 does not. Wireshark confirms that the old version sent PSK in client hello, the new version did not. curl 7.77 downloaded here: https://curl.se/windows/dl-7.77.0_2/curl-7.77.0_2-win64-mingw.zip Regards, Daniel --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
TLS session ID re-use broken in 7.77.0
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