✓ProveIt
Examples / Report #1555796 Saved analysis

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

curl · 2022-05-0112.1s analysis · $0.011 in model calls

What the report claims

Curl reuses TLS connections even when security-related options like CURLOPT_SSL_OPTIONS, CURLOPT_PROXY_SSL_OPTIONS, CURLOPT_CRLFILE, or CURLOPT_PROXY_CRLFILE are changed, leading to incorrect security settings being applied to reused connections.

Compare with curl's recorded outcome

Known vulnerability

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

Shown for comparison after analysis. The pipeline did not see this label.

ProveIt's finding

Needs human review

The available evidence does not settle the report. A maintainer should investigate.

Why this finding?
  • All claims concern whether curl's connection reuse logic compares security-relevant options (SSL_OPTIONS, CRLFILE, AUTO_CLIENT_CERT, etc.) when deciding to reuse a TLS/SSL connection.
  • The provided curl source only contains constant definitions (curl.h lines 876, 880, 897), not the connection cache/comparison code (likely in lib/conncache.c, lib/vtls/*, or lib/ssluse.c) that would determine if these options are checked.
  • Deterministic checks confirm all cited symbols exist at the target revision, and the report includes concrete reproduction steps, making the claims plausible.
  • Without the connection reuse decision code, the claims cannot be confirmed or contradicted from the provided material.
What still needs checking
  • The connection reuse/comparison logic (e.g., lib/conncache.c, lib/ssluse.c, or the TLS backend's connection matching functions) is needed to evaluate whether security options are compared before reusing a connection.
How this analysis ran 6 claims · 0 citations verified

Checked against curl master on 2022-05-01 (a7b29122cb35). Dev evaluation split. Citation verification checks that a referenced line was in the evidence; it does not prove the model interpreted it correctly.

1 · Grounding
grounded
no model · 7 references checked out, 0 did not
2 · Claims
NVIDIA-Nemotron-3-Nano-30B-A3B
6 claims · 1793 tokens · $0.0002
3 · Evidence
3 code snippets
real curl source at a7b29122cb35 · 6 docs via Tavily
4 · Judgment
Nemotron-3-Ultra-550b-a55b
7098 tokens · 9.3s · $0.0108
5 · Receipts
0 of 0 citations verified
every citation must point at code the judge was shown
Review a draft reply to the reporter

Edit and verify before sending.

Thank you for the detailed report with reproduction steps. To evaluate whether curl's connection reuse logic properly compares security options (SSL_OPTIONS, CRLFILE, AUTO_CLIENT_CERT, etc.), we need to examine the connection cache/comparison code (likely in lib/conncache.c, lib/ssluse.c, or the TLS backend's connection matching functions). The provided source only shows the option constants. Could you point to the specific functions/files where connection reuse decisions are made, or would you be able to provide those code sections?

Inspect all claims and source code 6 claims · 3 code excerpts

Report claims

C1flaw not verifiable

Curl fails to consider some security related options when reusing TLS connections

Read the reasoning

The claim is about connection reuse logic not considering CURLOPT_SSL_OPTIONS, CURLOPT_PROXY_SSL_OPTIONS, CURLOPT_CRLFILE, CURLOPT_PROXY_CRLFILE. The provided source code only shows constant definitions in curl.h (lines 876, 880, 897), not the connection cache/comparison code that would decide whether these options are checked during reuse. The deciding code (likely in lib/conncache.c or lib/vtls/*) is not provided.

C2flaw not verifiable

TLS connection with lower security (CURLSSLOPT_ALLOW_BEAST, CURLSSLOPT_NO_REVOKE) is reused when it should no longer be

Read the reasoning

The claim about CURLSSLOPT_ALLOW_BEAST and CURLSSLOPT_NO_REVOKE being ignored during connection reuse requires examining the connection comparison logic. Only the constant definitions are provided (curl.h lines 876, 880), not the reuse decision code.

C3flaw not verifiable

Connection authenticated previously with CURLSSLOPT_AUTO_CLIENT_CERT might be reused for connections that should not be

Read the reasoning

The claim about CURLSSLOPT_AUTO_CLIENT_CERT (curl.h line 897) being ignored during reuse similarly depends on connection comparison logic that is not in the provided source.

C4flaw not verifiable

CRL file use is ignored because previous connection is reused

Read the reasoning

The claim that CURLOPT_CRLFILE is ignored due to connection reuse cannot be verified without the connection cache/comparison code. Only the symbol existence is confirmed.

C5flaw not verifiable

Second connection reuses existing connection even though revocation check is no longer requested

Read the reasoning

The claim about revocation check (CURLOPT_SSL_NO_REVOKE / CURLSSLOPT_NO_REVOKE) being ignored on reuse requires the connection reuse logic, which is not provided.

C6flaw not verifiable

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

Read the reasoning

This summary claim about wrong identity or TLS options being reused depends on the same missing connection reuse logic.

Read the original report

Full report on HackerOne ↗

## 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.

Source code

include/curl/curl.hlines 876–876 · definition of CURLSSLOPT_ALLOW_BEAST
876#define CURLSSLOPT_ALLOW_BEAST (1<<0)
include/curl/curl.hlines 880–880 · definition of CURLSSLOPT_NO_REVOKE
880#define CURLSSLOPT_NO_REVOKE (1<<1)
include/curl/curl.hlines 897–897 · definition of CURLSSLOPT_AUTO_CLIENT_CERT
Show 1 lines (not cited by the judge)
897#define CURLSSLOPT_AUTO_CLIENT_CERT (1<<5)