I’m trying to patch this bug, see you in https://github.com/curl/curl/pull/8141!
Yongkang Huang From: curl-library <curl-library-boun...@lists.haxx.se> on behalf of Yongkang Huang via curl-library <curl-library@lists.haxx.se> Date: Sunday, December 5, 2021 at 8:42 PM To: libcurl development <curl-library@lists.haxx.se> Cc: Yongkang Huang <yk...@fb.com> Subject: Re: TLS connection re-usage on the same hostname with different client certificate For some more context, we use client cert mTLS for both https proxy and remote server. So If 2 different TLS to remote go through the same TL connection to https proxy, it would trigger the issue described above. Best Yongkang Huang From: curl-library <curl-library-boun...@lists.haxx.se> on behalf of Yongkang Huang via curl-library <curl-library@lists.haxx.se> Date: Sunday, December 5, 2021 at 8:39 PM To: libcurl development <curl-library@lists.haxx.se> Cc: Yongkang Huang <yk...@fb.com> Subject: Re: TLS connection re-usage on the same hostname with different client certificate > 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. Thanks for the reply! I didn’t receive the email reply for some reason but was able to find it in the web archive, sorry for the belated reply I checked the code pointer https://github.com/curl/curl/blob/a5f5687368a5f95415d58d37e8dfb10c6b6d44c5/lib/url.c#L1283-L1310 It seems when a https proxy is presented (in my use case it indeed presented), the code would only check the proxy_ssl_config of the connecton to proxy instead of checking the ssl_proxy config when there’s tls-over-tls. Is it deliberate or we need to file an issue for that? Best Yongkang Huang From: curl-library <curl-library-boun...@lists.haxx.se> on behalf of Yongkang Huang via curl-library <curl-library@lists.haxx.se> Date: Wednesday, December 1, 2021 at 3:53 PM To: curl-library@lists.haxx.se <curl-library@lists.haxx.se> Cc: Yongkang Huang <yk...@fb.com> Subject: TLS connection re-usage on the same hostname with different client certificate Hi! I’m not sure this is something need to be handled by the application or libcurl. When I reuse the TLS connection for a big payment company with different account we integrate in our application, we call a hostname api.bigcompany.com with the client cert of these accounts for mTLS. After the TLS connection is built, a username/password will be used for authentication in the following HTTP request. However, this company enforces the match of the username/password and the client cert, we hit an issue that 1. All the request go through the same CURLM so connection could be reused 2. CURLM will search the cached connection based on hostname, in this case api.bigcompany.com 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. Thanks Yongkang Huang
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
