On Fri, 30 Aug 2002 17:39, Daniel Stenberg wrote:

(referring to the ca-bundle from mod_ssl)
> For the moment I'm assuming that we can use the package without problems
> and I'm setting up configure, make install stuff etc to get this to work.

This seems like the hard part to me!

> Right. Options to:
> 4. whether the path in 3 is a directory for capath or a file for cafile
>
> I think I'll save option 4 for later and only use cafile right now.

Seems fine by me - certainly simpler.

> > > I don't see that as much problem, as any libcurl-using program could
> > > always just set CAPATH or CAFILE to point to the CA cert of their
> > > choice. In fact, they should do that and not blindly trust whatever we
> > > would go ahead and install for them.
> >
> > OK - this means a library API change (to call setting a CA bundle).
>
> I can't see why this requires an API change.

I mean that if the library sets CURLOPT_SSL_VERIFYPEER and
CURLOPT_SSL_VERIFYHOST to true by default (i.e. secure settings), without
setting CURLOPT_SSL_CAINFO by default (e.g. cainfo is set up in the curl tool
instead), then library users *must* change & re-compile their existing code
to add a call to set CURLOPT_SSL_CAINFO before they can use the new libcurl,
otherwise all SSL connections will fail. I would call this an API change, at
least of a sort.

If it was libcurl, not curl that set the default CAINFO, then in most cases
no libcurl client code changes would be required - just adding to or
replacing the installed ca-bundle.

> > Perhaps the choice to setup using the default curl CA bundle could be
> > another flag to curl_global_init. (It does seem lonely with only 2 at the
> > moment).
>
> Well, that could be an option if we changed the *DEFAULT to use this option
> and we hope that most people use this... I can't really see why we would
> like to have this a curl_global_init() option though.

I just suggested it as a simpler change for client code than adding a new
setopt - it's probably a wash, so feel free to ignore it.

> > One final issue worth considering: If you set up a default store, make
> > sure it's initialised during the first request, rather than when setting
> > up the curl handle. If a user specifies a different cafile, openssl will
> > load and add it to the certificates it has already loaded - it doesn't
> > normally replace the old certificate store. This would mean it would be
> > impossible for a user to decide *not* to trust the certificate supplied
> > with curl, but only to trust 'extra' certs on top of those supplied.
>
> I'm not following you here. I was thinking to do it more like this:

My fault - I hadn't read that part of the code in detail - this is already
what happens. SSL_CTX_load_verify is called during SSL_Connect, so if the
caller changes cafile before making a connection, libcurl will correctly use
only the new cafile.

<snip>

> I don't want the default installed certs to always be used in addition to
> the ones pointed out by the user, as it would give our installed CA bundle
> too much power, imho.

Yes, that's what I was trying to say. The current code will do the right
thing in this case, as long as the client sets a new cainfo before the first
'perform'.

(It's really a performance bug to do load_verify on every SSL_connect, the
way it's done at the moment. There's no need to repeatedly load the same
certs - if it's been done before (at least on the same handle) they'll
already be in the store.

I think I raised this in a 'suggestions' or TODO email a while back, but
never got enough tuits to look at fixing this properly. I'll try and get
around to submitting a patch to prevent this - I was thinking of setting a
flag for each of cafile/capath when they are changed by setopt, and clearing
the flag when the string is passed to load_verify, so that each new cafile
would only be loaded once.)

Cris

-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
Received on 2002-08-30