I guess what is lacking here is a detailed analysis of how ssl examines a
cert chain. It generally starts at the bottom and works its way up, and
does a bunch of tests on each certificate and then calls verify_callback
with each error. There are very few which actually relate to a local error
(i.e. can't verify it against a local cert). Curl could just ignore only
this error and fail on all others.
        I do see a problem with making strict server authentication a default. A
lot of ssl connections will fail with this turned on, even with the correct
list of CAs. Its just a pain in the ass to try and make work, particularly
with people doing backups from local machines, in which case there are no
CAs involved, only single depth cert chains. In these cases some local
storing of these certs to ensure that future cronjobs will fail would
probably be very nice.
        In the case of user-interaction, curl would need a 'silent' mode where it
wouldn't prompt and assume a default behavior (no to all yes/no questions).

p.s. Dan, this sort of certificate storage is part of what I did with
curl-lib and the certificate verification callbacks I added to curl last
month.

-----Original Message-----
From: Cris Bailiff [mailto:c.bailiff+curl_at_awayweb.com]
Sent: Monday, August 19, 2002 6:21 PM
To: Bram Whillock; curl-library_at_lists.sourceforge.net
Subject: Re: curl bad verify SSL certificates

On Tue, 20 Aug 2002 10:41, Bram Whillock wrote:
> Cris, though I see and understand the issues you're bringing up, I'm
> suggesting that in order to solve this 'out of the box' issue, curl is
made
> by default to trust everyone that presents what would have otherwise been
a
> good certificate chain, and doesn't trust single length self-signed
> certificate chains.

I guess I don't quite get what you mean by 'otherwise been a good
certificate
chain'. The only thing good about a certificate chain is that it chains to a
trusted root (apart from basic constraint and validity checking). (Also, if
you don't care what the root is, then self-signed certs are just as good as
any other, so I don't think you should treat them specially.)

> Look at an application like ssh or putty, they don't
> store certs for doing ssh connections, they ask about the server they're
> connecting to. In these cases it is damn simple for someone to be a man
in
> the middle and get your user name and password when you try and log in.

Yes, depressingly simple :-( . If you don't check the fingerprint, you take
a
pot-luck gamble when you connect the first time. If your client doesn't then
store the public hostkey, you also get a lucky-dip every time after.

That's why most SSL implementations come with a list of trusted roots. The
idea is that Joe Public will never remember (or even know) to check root
certs or fingerprints, but still must be able to 'spend spend spend' :-) .

> What could be used in addition to this sort of behavior would be some
sort
> of user-interaction and certificate caching. This way curl remembers the
> certificates of sites you've visited, and perhaps prompts when it
> encounters a new site, or one that differs from that of a cached site.

That would be a reasonable approach, I guess, but quite a a diversion from
current curl behaviour. At least, it could cause a lot of cron jobs to stop
and ask /dev/null what it thinks of a site cert :-). Remember, it's only
really the 'default' behaviour we care about. (You could certainly have
these other options as switches. I guess you'd need somewhere writeable to
store the list of trusted certs on a per-user basis and possibly 'rejected'
certs or roots as well. )

> This would be basically identical to the behavior of ssh.

Yes, this is the default openssh behaviour, but it's not good practice (as
discussed above). 'StrictHostKeyChecking' should be off by default, and an
out-of band method should be used to distribute or verify tusted host keys.
Ssh key management is tough to scale to large sites (like 'the whole
internet' ). That's why SSL applications normally use the global PKI.

(You're free to point out the irony that the out-of-band check for SSL then
becomes "I implicitly trust the version of FooExploder I just downloaded,
because 'FooSoft' tell me they are 'trustworthy'"!)

Adding a list of root CA's 'behind the scenes' seems to me to be the best
trade-off for curl, if we conclude that the default behaviour should be
changed at all. This approach impacts on the fewest of installed
curl/libcurl-using clients, and provides default security most similar to
other SSL clients.

I guess it's up to Daniel (when his timezone comes around) to pick apart our
discussion and decide how many 'tuits' he has for this issue.

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