HackerOne Vulnerability Report: libcurl SSL/TLS Identity Leakage via Insecure Connection Reuse

How it was found

Summary

libcurl contains a critical logic flaw in its connection reuse mechanism where transfers using the CURLOPT_SSL_CTX_FUNCTION (SSL context callback) to establish a specific identity (e.g., via client certificates) can have their connections incorrectly reused by subsequent, unauthenticated transfers to the same host. This leads to identity leakage and authentication bypass between independent easy handles within the same application process.

Technical Description

The Flaw

When a connection is established, libcurl caches it in a connection pool for potential reuse. To ensure safety, libcurl performs a "matching" check to verify that the new request requires the same security-sensitive configuration as the cached connection.

However, the matching logic for SSL/TLS connections in lib/vtls/vtls.c (and the connection data structure itself) only tracks and compares the "primary" SSL configuration (e.g., verify flags, CA paths). It entirely omits the fsslctx field (the callback set via CURLOPT_SSL_CTX_FUNCTION).

Affected Code References

1. Inadequate Data Storage: In lib/urldata.h, the connectdata structure only stores struct ssl_primary_config ssl_config.
2. Incomplete Cloning: In Curl_ssl_conn_config_init, only the primary configuration is cloned from the easy handle to the connection. The fsslctx callback is lost at the connection level.
3. Flawed Matching: In match_ssl_primary_config, the comparison loop only checks fields within the primary config. It has no way to detect if a connection was established using a custom SSL context callback.

Steps to Reproduce (Conceptual PoC)

1. Set up an HTTPS server that requires client certificate authentication.
2. Perform a transfer with Handle 1, using CURLOPT_SSL_CTX_FUNCTION to load a valid client certificate.
3. Perform a second transfer with Handle 2 to the same host/port, but do not specify any client certificate or callback.
4. Observe that libcurl reuses the connection from Handle 1 (verified via CURLINFO_NUM_CONNECTS returning 0 for the second transfer).
5. Observe that the server accepts the second request as authenticated under Handle 1's identity.

Recommended Mitigation

1. Extend struct ssl_primary_config to include the fsslctx callback pointer (or a hash of its identity if the pointer is not sufficient).
2. Update match_ssl_primary_config to include a strict comparison of the fsslctx (and fsslctxp) fields.
3. Ensure that any connection established with a custom SSL_CTX callback is marked as non-reusable by any request that does not share the exact same callback configuration.

Related Observations

During this audit, verified similar matching gaps were found in:

• IMAP/SMTP/POP3/LDAP: conn->options (login options) are ignored in url_match_auth.
• SSH: known_hosts file paths and policies are ignored in ssh_config_matches. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Impact

Summary:

Scenario: Identity Theft / Authentication Bypass

1. Request A: An application uses CURLOPT_SSL_CTX_FUNCTION to load a specific user's client certificate into the SSL context. The connection is established and the user is authenticated by the server.
2. Request B: A second, unauthenticated request (possibly for a different user or an anonymous action) is made to the same host.
3. Vulnerability: libcurl matches Request B to the existing connection of Request A because their "primary" SSL settings (like verifypeer) are identical. Request B reuses the already-authenticated TLS session of Request A.
4. Result: Request B is performed under Request A's identity, bypassing authentication and potentially accessing private data.

This is a High Severity issue in multi-identity applications or services using libcurl as a shared backend.