cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: curl bad verify SSL certificates (fwd)

From: Cris Bailiff <c.bailiff+curl_at_awayweb.com>
Date: Mon, 19 Aug 2002 17:49:52 +1000

I can sort of see what Tom is getting at here, though I think his proposed
solution is a bit prescriptive. Alternatives below.

The issue is, I think, that 'by default' curl is happy to connect to SSL
sites without checking the certificate details, whereas good security
practice (and most 'end-user' apps) would suggest that SSL certificate chains
should be validated by default, and only ignored/overriden by an explicit
user action.

On Mon, 19 Aug 2002 15:11, Daniel Stenberg wrote:
> On Sun, 18 Aug 2002, Tom Zerucha wrote:
> > > What kind of warning are you refering to that curl should display? When
> > > we're running SSL without verifying the remote's certificate, how can
> > > we warn and for what?
> >
> > The callback should not simply return 'ok', in fact it should return the
> > opposite unless it properly validates the certificate chain or is
> > explicitly overridden (or, more properly, has a correct certificate
> > installed in the openssl certs directory).
>
> That's because you don't use curl with the --cacert or --capath options.
> Without those, it really can't verify that peer's cert. And it doesn't
> attempt to do so either. *With* those arguments, you are right that it
> shouldn't allow any operation unless the remote cert turns out to be
> correct.

So, if we follow best security practice, curl should refuse to connect to
https sites unless a --cacert or --capath is specified (and the certificate
chain verifies properly). Because curl can't verify, perhaps it shouldn't
connect (and save the dumb user from themselves...)

> > Solution: Rewrite the certificate verify callback to actually check the
> > certificate chain properly. Don't connect without an override.
>
> So, this is what happens when you use the above mentioned options. In
> libcurl, those options are named CURLOPT_CAINFO and CURLOPT_CAPATH.

Curl does 'the right thing' (at least, it does what Tom wants) when you
specify one of those options. The real issue is what is 'correct' when you
don't specify one of those options.

Alternatives for consideration:

a) Disallow connections to https sites without one of --cacert or --capath
(unless overidden with something like --no-sslverify or something)

b) Compile a default --capath or --cacert into curl (based on what ca
path/file ./configure manages to extract from the installed openssl). Leave
it up to the user to populate the openssl cert file/path if their
distro/vendor doesn't supply any 'trusted' CA certs.

c) Compile a curl-specific default --capath or --cafile
(/usr/lib/curl/ssl-ca?). Allow the user to either populate the curl ca file
with CA's they trust, or override with --capath/--cafile as usual.

d) Compile a curl-specific default (as above) and populate it at install time
with a list of 'trusted' well known CA's, such as those listed in
'ca-bundle.crt' (which is, in turn, extracted from a public release of
Netscape). Could be overriden with capath/cafile, or turned off with
--no-sslverify or whatever.

e) Do nothing, except maybe make the command line tool put out a big warning
(on stderr) when using https to an un-verified site. Library users can take
care of themselves.

Pros & Cons:
a) means all curl/libcurl users using https must modify their scripts to
specify a CA file, or they break. This is not necessarily a bad thing, at
least it alerts those users that they are mis-using ssl, and gaining no
protections from it.

b) + c) mean the admin/installer of curl needs to do some extra manual effort
to install a list of trusted certificates, but scripts and applications don't
need to change.

d) Is pretty much what 'consumer' apps like web browsers do - each browser
comes with an emedded internal list, to save the user needing to make
intelligent security decisions. This is the most 'drop in' solution, and
provides immediate improvements to those using SSL to connect to sites signed
by 'well known' CA's. Connecting to sites signed by private CA's or
self-signed certs will still break without admin intervention (or script
changes) . This bloats the curl distribution a little, and also nicely
extends the verisign monopoly :-)

e) Is the trivial solution, but won't please Tom much! Library users should
be more able to remember to set CAfile themselves, but here too, a more
secure default might save some developers/users from misfortune.

Take comfort, also, in the fact that SSL verification in Internet Exploder
(and all Windows SSL applications using CAPI, it seems) is presently useless,
as Microsoft broke/forgot to implement Basic Constraint checking, meaning
anyone can use any existing certificate to 'fake' up a cert for any website
they choose. :-)

Comments welcome...

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-19