tls: move key and cert_type fields into ssl_primary_config

[MegaManSec]

Description

cert_type, key, key_type, key_passwd and key_blob lived in ssl_config_data but not ssl_primary_config, so they were invisible to both match_ssl_primary_config (connection reuse) and the TLS session cache peer key and auth match. Only clientcert was compared; the rest of the client credential set was silently ignored.

Two concrete consequences:

1. Connection reuse: handles sharing the same certificate but differing in key file, key type, cert type, or key blob could incorrectly reuse each other's connections.

2. Session resumption bypass: a handle configured with the wrong key password would normally fail the TLS handshake — it cannot sign with the key. But if a correctly-configured handle had already cached a session, the misconfigured handle could resume that session without ever performing a handshake, bypassing key authentication entirely. key_passwd is now stored on the session cache peer and compared with Curl_timestrcmp at lookup, following the same pattern as SRP credentials.

Promote all five fields into ssl_primary_config so both the conn-reuse predicate and the session cache cover the complete client credential set. Also replaces the fixed :CCERT session cache marker with the actual client cert and key paths.

Adds unit3303 to verify conn-reuse matching distinguishes handles differing on these fields, and unit3304 to verify the session cache peer key correctly includes key path, key type and cert type but not key password.

[Copilot]

Pull request overview

This PR moves client credential fields into ssl_primary_config so connection reuse and TLS session cache decisions can account for them consistently across TLS backends.

Changes:

• Promotes cert/key type, key path, key password, and key blob fields into ssl_primary_config.
• Updates TLS/SSH backend references to use the new field locations.
• Adds unit3303 for connection config matching of several client credential fields.

Reviewed changes

Copilot reviewed 14 out of 14 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
lib/urldata.h	Moves client credential fields into ssl_primary_config.
lib/vtls/vtls.c	Adds credential fields to config matching, cloning, cleanup, and setup.
lib/vtls/vtls_scache.c	Adds client cert/key path and key blob to TLS session cache peer key.
lib/vtls/openssl.c	Updates OpenSSL credential field accesses.
lib/vtls/gtls.c	Updates GnuTLS credential field accesses.
lib/vtls/mbedtls.c	Updates mbedTLS credential field accesses.
lib/vtls/rustls.c	Updates rustls key field accesses.
lib/vtls/schannel.c	Updates Schannel credential field accesses.
lib/vtls/wolfssl.c	Updates wolfSSL credential field accesses.
lib/vssh/libssh.c	Updates SSH key password access.
lib/vssh/libssh2.c	Updates SSH key password access.
lib/ldap.c	Updates LDAP TLS cert type access.
tests/unit/unit3303.c	Adds a unit test for connection config credential matching.
tests/unit/Makefile.inc	Includes the new unit test in the unit test list.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[icing]

I do not understand what this fixes. Talking about the password, for example. I'd be hesitant to put that into the session id, even as a hash. What is the benefit of matching this?

We are talking about a single user application where a connection/session might get reused after someone configured the wrong key password on a transfer? Why would anyone do this?

[MegaManSec]

@icing

I'd be hesitant to put that into the session id, even as a hash.

Fixed. Now we just do the same as the SRP credentials path, which isto store it as a separate field on Curl_ssl_scache_peer and compare it with Curl_timestrcmp at lookup time.

As for what this PR is actually addressing, it's about two different handles in the same multi-handle sharing a connection pool or TLS session cache, i.e.

• Handle 1: CURLOPT_KEYPASSWD = "secret", performs a successful mTLS handshake, session cached.
• Handle B: CURLOPT_KEYPASSWD = "", looks up the session cache, gets a hit (password not part of the key), resumes the TLS session of handle 1, despite not having access to the correct key password

[icing]

@icing

I'd be hesitant to put that into the session id, even as a hash.

Fixed. Now we just do the same as the SRP credentials path, which isto store it as a separate field on Curl_ssl_scache_peer and compare it with Curl_timestrcmp at lookup time.

As for what this PR is actually addressing, it's about two different handles in the same multi-handle sharing a connection pool or TLS session cache, i.e.

• Handle 1: CURLOPT_KEYPASSWD = "secret", performs a successful mTLS handshake, session cached.
• Handle B: CURLOPT_KEYPASSWD = "", looks up the session cache, gets a hit (password not part of the key), resumes the TLS session of handle 1, despite not having access to the correct key password

So, this protects against a coding mistake in the application, which would fail the connect otherwise because of the wrong password. Hmm...

[MegaManSec]

Is it a coding mistake in an application? Isn't this exactly the intended functionality of a multihandle?

e.g. a server-side application using libcurl to forward requests on behalf of different tenants, each configured with their own mTLS client cert/key on separate handles, all sharing one connection pool. Without this fix, tenant B's handle can resume tenant A's cached TLS session..

[MegaManSec]

sorry, not the cert path itself, but rather the two handles using the same certificate but different private keys or key passwords would be mixed up.

[icing]

sorry, not the cert path itself, but rather the two handles using the same certificate but different private keys or key passwords would be mixed up.

Ah, ok. The key path and blob I understand. Thanks.

[bagder]

sorry, I caused a merge conflict just now when I merged another PR...

[MegaManSec]

@bagder fixed, thanks

@icing thanks for looking. sometimes i press enter without thinking whether the person on the other side of the screen understands what i'm writing in the way i do. my bad

[bagder]

The torture memory leak is probably fixed with this:

diff --git a/tests/unit/unit3303.c b/tests/unit/unit3303.c
index e308085f8b..41bced542d 100644
--- a/tests/unit/unit3303.c
+++ b/tests/unit/unit3303.c
@@ -62,10 +62,12 @@ static CURLcode test_unit3303(const char *arg)
       goto unit_test_abort;
     }
 
     conn = curlx_calloc(1, sizeof(*conn));
     if(!conn || Curl_ssl_conn_config_init((struct Curl_easy *)curl, conn)) {
+      if(conn)
+        Curl_ssl_conn_config_cleanup(conn);
       curlx_free(conn);
       curl_easy_cleanup(curl);
       curl_global_cleanup();
       goto unit_test_abort;
     }

[bagder]

thanks!