This is being discussed in the libcurl mailing list in regard to if curl bugs
or not, but I think that we could always have a talk in here too regarding
the options and how-to-use the curl command line tool.

Tom Zerucha suggests (see the forwarded mail below) that we never should
allow untrusted HTTPS connects without specificly requiring a
--no-cert-verification type option. Instead of the reversed situation that we
have today, that allows untrusted HTTPS connections unless the --cacert or
--capath options are used.

Would do you think about this?

-- 
 Daniel Stenberg -- curl related mails on curl related mailing lists please
---------- Forwarded message ----------
Date: Mon, 19 Aug 2002 03:13:14 -0400
From: Tom Zerucha
To: Daniel Stenberg <daniel_at_haxx.se>
Subject: Re: curl bad verify SSL certificates (fwd)
On Mon, Aug 19, 2002 at 07:11:35AM +0200, 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.
>
> > 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.
I saw them but I thought that was for submitting user certs, which I
think is the -E option.
I do have a problem with having the default behavior as silently allow
anything through even if it is completely invalid.  It should not
connect unless a --no-cert-verification type argument is given or it
can verify the peer.  Allowing curl to connect to spoofed sites should
require user interaction, as opposed to requiring user interaction to
actually make a "secure" protocol actually be secure.
I went through the entire documentation and couldn't find anywhere it
said the default SSL mode has no verification of the peer and thus
offers almost no security.  The --ca... options don't merely set the
paths, they turn on the verification.  After your message and
searching the documentation it became clear.
Right now, Microsoft in their technote on the problem basically says
if the user clicked on the lock icon, he would see that there was
something wrong in the chain.  No one ever does this, especially not
on each connection.  The big problem with Internet Explorer is the
default behavior is that it silently accepts connections from
malsigned sites.  But at least it makes some attempt at checking by
default.
If nothing else, you should clearly state somewhere prominently
(something that most people wouldn't miss including a warning message
when run nonsilently) that SSL/https isn't secure unless you use the
--ca options.  I think the normal assumption of anyone who didn't get
into the development or the source or didn't read between the lines of
the documentation for what is not said is that by specifying https://
that it would be SECURE by default.
-------------------------------------------------------
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