CVE-2022-27782: TLS and SSH connection too eager reuse

How it was found

Summary:

Curl fails to consider some security related options when reusing TLS connections. For example:

• CURLOPT_SSL_OPTIONS
• CURLOPT_PROXY_SSL_OPTIONS
• CURLOPT_CRLFILE
• CURLOPT_PROXY_CRLFILE

As a result for example TLS connection with lower security (CURLSSLOPT_ALLOW_BEAST, CURLSSLOPT_NO_REVOKE) connection reused when it should no longer be. Also connection that has been authenticated perviously with CURLSSLOPT_AUTO_CLIENT_CERT might be reused for connections that should not be.

Steps To Reproduce:

1. (echo -ne "HTTP/1.1 200 OK\r\nContent-Length: 6\r\n\r\nHello\n"; sleep 5; echo -ne "HTTP/1.1 200 OK\r\nContent-Length: 6\r\n\r\nAgain\n") | openssl s_server -cert cert.pem -key privkey.pem -cert_chain chain.pem -accept 9443
2. curl -v --ssl-no-revoke --ssl-allow-beast https://targethost.tld:9443 -: https://targethost.tld:9443

Connections are made using the same reused connection even though security settings change.

With curl built against openssl:

1. curl http://cdp.geotrust.com/GeoTrustRSACA2018.crl | openssl crl -out testcrl.pem
2. curl -v https://curl.se -: --crlfile crlfile.pem https://curl.se

The crlfile.pem use should result in curl: (60) SSL certificate problem: unable to get certificate CRL but is ignored since previous connection is reused.

With curl built against Schannel and revoked certificate:

1. curl -v --ssl-no-revoke https://revoked.grc.com -: https://revoked.grc.com

Second connection will reuse the existing connection even though revocation check is no longer requested.

Note:

There may be more options that might have the similar issues. These were the most obvious I could see (ones having obvious security impact).

Impact

Wrong identity (client certificate) or TLS security options being used for subsequent connections to the same hosts.