systematic loading of ca-certificates.crt

Sorin Manolache via curl-library <[email protected]>
Newsgroups gmane.comp.web.curl.library
Message-ID <CACVM4zPoRqJUSHb_4Dkn5m4wG7s4y-h+AHhgg_ux7EEBMdqCsg@mail.gmail.com>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.