Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
vtls: compare and clone ssl configs properly #1917
Compare these settings in Curl_ssl_config_matches():
Also copy the setting "verifystatus" in Curl_clone_primary_ssl_config(),
This means that reusing connections that are secured with a client
If you (the reviewers) agree, reusing connections that are secured with a client certificate is now officially possible. It was also possible before because of a bug. I think that it's OK to resume the TLS session if all the TLS settings (including the client certificate) are the same.
I have asked the curl security team whether it's OK to post this as a normal pull request, and they agreed.
These old advisories state that TLS session resumption is disabled when a client certificate is used:
... but that's not true. I have tested with curl 7.55.1:
Source code analysis:
There's this code in Curl_clone_primary_ssl_config(), vtls.c:
This sets the "sessionid" flag in the connection object (struct connectdata). But the code that checks whether TLS session resumption is possible does not look at the connection, it looks at the easy handle (struct Curl_easy).
This pull request cleans things up and allows reusing connections that are secured with a client certificate.
Compare these settings in Curl_ssl_config_matches(): - verifystatus (CURLOPT_SSL_VERIFYSTATUS) - sessionid (CURLOPT_SSL_SESSIONID_CACHE) - random_file (CURLOPT_RANDOM_FILE) - egdsocket (CURLOPT_EGDSOCKET) Also copy the setting "verifystatus" in Curl_clone_primary_ssl_config(), and copy the setting "sessionid" unconditionally. This means that reusing connections that are secured with a client certificate is now possible, and the statement "TLS session resumption is disabled when a client certificate is used" in the old advisory at https://curl.haxx.se/docs/adv_20170419.html is obsolete.
bagder left a comment
What's the argument to require the same random file and egdsocket settings? They're used to seed the PRNG so I don't see how they disqualify reuse if set to different values for different connections. (although I suspect both of them are very rarely used so in reality this change will hardly affect any users)
Interesting point... I think that the security of the SSL encryption depends on these settings. For example, if easy handle A does not use an EGD socket, but easy handle B does (for "extra security"), then A's connection should not be reused for B, because the security properties differ. (the other way round may be OK... it depends on the quality of the EGD)
I don't know whether
If we focus on connection reuse, it's probably also not necessary (or even a bad idea) to compare the