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

## **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](file:///d:/curl/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](file:///d:/curl/lib/urldata.h#L412), the `connectdata` structure only stores `struct ssl_primary_config ssl_config`. 2. **Incomplete Cloning:** In [Curl_ssl_conn_config_init](file:///d:/curl/lib/vtls/vtls.c#L395-402), 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](file:///d:/curl/lib/vtls/vtls.c#L193), 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](file:///d:/curl/lib/vtls/vtls.c#193-225) 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](file:///d:/curl/lib/url.c#L1003). - **SSH:** `known_hosts` file paths and policies are ignored in [ssh_config_matches](file:///d:/curl/lib/url.c#L705). @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ ## 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.