On Tue, 27 Aug 2002, Cris Bailiff wrote:

> > $ curl https:[URL hidden to save the innocent]
> > curl: (58) Insecure SSL connect attempted without explicit permission

> Did you plan to add a ca-bundle file into the curl distribution? I know
> it's a bit large (although it zips well), and it re-enforces the "global CA
> monopoly"

I've thought about it, but I haven't really made up my mind yet. I greatl
appreciate your input on this.

> * With a default set of CA's, users wouldn't need to use '-k' when going to
> sites that other SSL software (mozilla, ie, konqueror, opera etc.) normally
> 'trusts'.
>
> * Finding and adding CA certs for many sites could be a bit tricky for many
> users - they'll just use -k instead of finding their own ca-bundle, so
> they'll basically turn off security when they didn't really need to.

These are certainly good points arguing *for* the inclusion of a CA bundle.

The cons then? What are the drawbacks (disk and package space not taken into
account)?

Can we get our hands on a good certificate package and include it? I mean
copyright wise? I've noticed that for example the modssl package has a huge
bundle included. Would we be allowed to ship that or would we need to dig up
another version somehow/somewhere?

It'll add an annoying installation procedure that'll cause us grief. Of
course, we'll have some lib/ca-bundle.h file that gets generated properly
with the to-become installed path for the CA cert bundle so that the library
finds it smoothly. The curl-config tool should also know about the path if
the CA cert bundle is installed.

> * You wouldn't necessarily need a new libcurl option - just set the
> defaults for CURLOPT_VERIFY_PEER=1 and CURLOPT_VERIFY_HOST=2 in the
> library, and let the library user provide a CA file/path. If they don't
> provide one, and don't change the verify options, they can't make secure
> connections.

Hey, you're good! Me like this very much!

> * The command line tool can set CURLOPT_SSL_CACERT to the bundled one, and
> '-k' could then just set CURLOPT_VERIFY_PEER=0 and CURLOPT_VERIFY_HOST=0.

Yes.

> * You could even have the library itself install the default CACERT file,
> which would reduce the impact on existing library-using code. This would
> remove any forced code changes for existing library using clients.

Right, if we use this approach many users wouldn't even notice the upgrade to
CA cert using connections from the previous insecure ones. At least those
that are connecting to sites using "real" certificates.

> Certainly a verbose error message is important - like the numerous popups
> in a good browser - users should find it more convenient to use the
> security, rather than to ignore it. The error could just be displayed,
> though, when SSL verification fails with the included certs.

There's no reason to even attempt an SSL connect if an insecure connect isn't
allowed and we don't have any certificates. It would be a waste of time.

> If you think it ugly that curl would need to reference a movable external
> file, you can actually embedd default certs in the code, though this makes
> changing certs prety inflexible. I have code for this somewhere if it's of
> interest.

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.

-- 
 Daniel Stenberg -- curl related mails on curl related mailing lists please
-------------------------------------------------------
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