Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: TLS connection re-usage on the same hostname with different client certificate
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 2 Dec 2021 09:28:48 +0100 (CET)
On Wed, 1 Dec 2021, Yongkang Huang via curl-library wrote:
> 3. However, A TLS connection built by account A could not share with
> account B because they are built with different client cert, otherwise the
> HTTP username/password authentication will fail.
>
> I’m wondering should user just sharding the CURLM connection pool or we
> should follow-up with distinguish cached connection based on some TLS cert
> information like fingerprint.
libcurl handles this situation automatically.
When finding a connnection to the host name in the pool, and it uses TLS,
libcurl will also make sure that a number of TLS related properties match so
that reusing the connection still follows the options and restrictions set for
current transfer. If a TLS connection uses a client certificate, it can only
be reused by another transfer if that transfer uses the *same* client
certificate. If it uses another client certificate, it will not be a match and
libcurl will continue searching for other connections to reuse or ultimately,
if failing that, create a new one.
In the code you can see this in lib/url.c:ConnectionExists() which is the big
find-a-connection-to-reuse function which in itself calls
lib/vtls/vtls.c:Curl_ssl_config_matches() to make sure the TLS config matches
before the connection is deemed okay to use.
Date: Thu, 2 Dec 2021 09:28:48 +0100 (CET)
On Wed, 1 Dec 2021, Yongkang Huang via curl-library wrote:
> 3. However, A TLS connection built by account A could not share with
> account B because they are built with different client cert, otherwise the
> HTTP username/password authentication will fail.
>
> I’m wondering should user just sharding the CURLM connection pool or we
> should follow-up with distinguish cached connection based on some TLS cert
> information like fingerprint.
libcurl handles this situation automatically.
When finding a connnection to the host name in the pool, and it uses TLS,
libcurl will also make sure that a number of TLS related properties match so
that reusing the connection still follows the options and restrictions set for
current transfer. If a TLS connection uses a client certificate, it can only
be reused by another transfer if that transfer uses the *same* client
certificate. If it uses another client certificate, it will not be a match and
libcurl will continue searching for other connections to reuse or ultimately,
if failing that, create a new one.
In the code you can see this in lib/url.c:ConnectionExists() which is the big
find-a-connection-to-reuse function which in itself calls
lib/vtls/vtls.c:Curl_ssl_config_matches() to make sure the TLS config matches
before the connection is deemed okay to use.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2021-12-02