Buy commercial curl support. 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 Daniel himself.
systematic loading of ca-certificates.crt
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Sorin Manolache via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 14 Feb 2025 15:16:06 +0100
Hello,
I'm using libcurl in multi-handle mode on linux machine. Libcurl is linked
with openssl.
I notice that /etc/ssl/certs/ca-certificates.crt is loaded every time I
open a connection to a https URL.
I've browsed the code and it seems that the SSL_CTX is freed when the
connection is closed. The destruction of the SSL_CTX seems to trigger the
destruction of the X509_STORE, but as these structures are
reference-counted I am not really sure that they are destroyed by just
looking at the code.
It seems that the only "state" in a multi-handle is the connection cache
structure. But this structure contains only connections, I have not seen a
structure holding SSL data. But maybe the connections to the same host
share some SSL data, I couldn't tell.
I've run the following test: I perform 10 iterations. In each iteration I
make 10 requests in parallel (via the multi-interface) to the same URL. I
set the connection cache size to 8. I then run strace and count the number
of times ca-certificates was read. It's 28 times. 10 times for the first
iteration, in which I open the 10 connections. As the connection cache size
is 8, I lack 2 connections in each iteration. So for the remaining 9
iterations I have to open two connections per iteration. 1x10 + 9x2 = 28.
But the opening of a connection in iterations 2-10 could have used the
certificate store of one of the already opened connections in the
connection cache.
Is there a way to use libcurl such that the certificate store is cached and
shared with a connection upon the connection's creation?
ca-certificates.crt has about 270 kB and loading it every time we open an
SSL connection has an impact on the connection time, especially in a
multi-handle setup in which we could open tens of connections
simultaneously.
Is there a reason why it does not currently happen? A security risk?
Thank you,
Sorin
Date: Fri, 14 Feb 2025 15:16:06 +0100
Hello,
I'm using libcurl in multi-handle mode on linux machine. Libcurl is linked
with openssl.
I notice that /etc/ssl/certs/ca-certificates.crt is loaded every time I
open a connection to a https URL.
I've browsed the code and it seems that the SSL_CTX is freed when the
connection is closed. The destruction of the SSL_CTX seems to trigger the
destruction of the X509_STORE, but as these structures are
reference-counted I am not really sure that they are destroyed by just
looking at the code.
It seems that the only "state" in a multi-handle is the connection cache
structure. But this structure contains only connections, I have not seen a
structure holding SSL data. But maybe the connections to the same host
share some SSL data, I couldn't tell.
I've run the following test: I perform 10 iterations. In each iteration I
make 10 requests in parallel (via the multi-interface) to the same URL. I
set the connection cache size to 8. I then run strace and count the number
of times ca-certificates was read. It's 28 times. 10 times for the first
iteration, in which I open the 10 connections. As the connection cache size
is 8, I lack 2 connections in each iteration. So for the remaining 9
iterations I have to open two connections per iteration. 1x10 + 9x2 = 28.
But the opening of a connection in iterations 2-10 could have used the
certificate store of one of the already opened connections in the
connection cache.
Is there a way to use libcurl such that the certificate store is cached and
shared with a connection upon the connection's creation?
ca-certificates.crt has about 270 kB and loading it every time we open an
SSL connection has an impact on the connection time, especially in a
multi-handle setup in which we could open tens of connections
simultaneously.
Is there a reason why it does not currently happen? A security risk?
Thank you,
Sorin
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-02-14