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.
Re: systematic loading of ca-certificates.crt
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Stefan Eissing via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 14 Feb 2025 16:31:25 +0100
Hi Sorin,
you are correct that the x509 store is populated again for every *new* connection. But the connection cache keeps *live* connections and, when a connection from there is reused, does not create a new SSL_CTX or load the x509 certs again.
In your tests, something seems to prevent the connections from being reused.
I assume that you have tested a recent curl. If you run that with `-vvvv` you will get trace output that shows you exactly how reuse happens or not and when the store is loaded.
If you can create an example program which does not behave as you think it should, let's have a look at that.
Hope this helps,
Stefan
> Am 14.02.2025 um 15:16 schrieb Sorin Manolache via curl-library <curl-library_at_lists.haxx.se>:
>
> 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.html
Date: Fri, 14 Feb 2025 16:31:25 +0100
Hi Sorin,
you are correct that the x509 store is populated again for every *new* connection. But the connection cache keeps *live* connections and, when a connection from there is reused, does not create a new SSL_CTX or load the x509 certs again.
In your tests, something seems to prevent the connections from being reused.
I assume that you have tested a recent curl. If you run that with `-vvvv` you will get trace output that shows you exactly how reuse happens or not and when the store is loaded.
If you can create an example program which does not behave as you think it should, let's have a look at that.
Hope this helps,
Stefan
> Am 14.02.2025 um 15:16 schrieb Sorin Manolache via curl-library <curl-library_at_lists.haxx.se>:
>
> 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.html
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-02-14