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