Re: FD / lists.grok.org - bad SSL cert

[Tim <tim-security () sentinelchicken org>]

> And as browsers usually do not check CRLs, there is no way preventing
> the use of wrongfully signed certificates short of distributing a
> "software update" (as was with the MS case). If browsers had a cert
> cache and checked it similar to SSH, MitM-attacks would be much harder. 

Well, now you're just pushing the problem off on users.  How many of
them would check the certificate the first time?  Does it matter to an
end-user if their credit card info is stolen *only the first time* and
not after that?

Certainly SSL's PKI has major problems.  Many of these problems can be
remedied through simple client software changes.  Why is every CA
treated the same?  Why don't we start assigning levels of trust to
different CAs?  A web-of-trust would be a great way to go, so long as
there's a way to hide it from end users.  Who would be allowed to
participate in the web of trust?  Tough questions.

As a basic first step, perhaps what browsers need to start doing is to
take all of those CAs out of the default install and replace it with
just one.  Their own.  Sign all current CAs as sub-CAs.  Turn on CRL
checks by default to their servers and start tracking all revocations in
one place.  Then, when a CA starts misbehaving, deal with it through the
central CRL or through a trust rating system which is separate from the
standard certificate formats.  Yeah, sure, it centralizes things in a
bad way, but centralized CRLs are still better than none.  Once the
system is solidified, standardize and redistribute.

Some crazy ideas, I know.  Feel free to shred them.

tim

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/