Re: TLS session ID re-use broken in 7.77.0

2021-06-09 Thread Gergely Nagy via curl-library
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

2021-06-08 Thread Daniel Jeliński via curl-library
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

2021-06-07 Thread Paul Groke via curl-library
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