[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "Certification Authorities are recommended to stop using MD5 altogether"

>>On Wed, 31 Dec 2008, Micah Anderson wrote:                                        
>> Does anyone have a legitimate reason to trust any particular Certificate
>> Authority?
> Yves-Alexis Perez <corsac@debian.org> writes:
> > I may be wrong, but I trust the CAs in ca-certificates. I've followed
> > the add of French Gvt CA Certificates, and the procedure was enough
> > strict to give me this trust impression.
> * Russ Allbery <rra@debian.org> [2009-01-01 10:04-0500]:
> While this exploit is particularly interesting because it's technical
> rather than social and therefore easy to wrap one's mind around, it's not
> been particularly difficult to get a forged certificate since nearly the
> beginning of the commercial CA concept.  Very few of the certificate
> authorities do any sort of real authentication of the requester, so if
> you're willing to simple things like fax them forged letterhead, you can
> probably get a certificate claiming to be just about anyone who isn't
> extremely high-profile.

I agree, and this is why I poised this question. The hierarchical
Certificate Authority model is fundamentally flawed, and easily
exploited. The state of SSL CAs is really dismal in a number of ways,
its trivial to get a certificate issued as someone else, as has been
demonstrated by the recent Comodo example, and as Russ explains
above. Revocations are handled poorly, if at all, and even the protocols
for revocation leak private information about what sites you are
visiting to your friendly neighborhood OCSP provider. Firefox/Iceweasel
doesn't even ship with a default CRL list for the certificates that are
accepted by Mozilla....

It gets worse.... trusting a CA means trusting that one central
"authority" is secure, sure their security protocols have been
independently audited before they are accepted into Mozilla, but that
doesn't mean that they aren't a prime target. Can you imagine the
fallout from when a CA is hacked?

There are other pressures too. What if the authorities of whatever
country the CA resides in decide that they want to snoop the traffic of
some site on the internet that has a certificate from the CA? They would
just need to get the CA to issue a new certificate that looks like yours
and employ a man-in-the middle attack to read all your SSL traffic after
installing a proxy somewhere upstream, using this 'replacement'
certificate for your server. This proxy is installed between you and the
internet, or the target, and the target is presented with the fake
certificate instead of yours. With the key in-hand, the attacker can
decrypt all encrypted traffic that travels the wire. Unless you are
checking the fingerprint of every SSL connection, you will not notice
this because the certificate was issued by a "trusted" CA.

To have faith in your SSL certificate, you need to trust the government
(not recommended), or trust a company who has various interests, such as
commercial and pressures applied to it. In some cases Certificate
Authorities are *sold* to someone who wants to buy the
company. Purchasing a company, whose root is in Mozilla, would be a
great way of compromising a lot of very sensitive data and probably
would recoup the investment in no time. Do you trust the United States
government, the NSA to have a convenient backdoor into your SSL verified
encrypted traffic? What about the company Verisign? They provide a 3rd
party CALEA compliance service, which means that they have NSA/FBI
backdoors built-into their systems. Chances are AOL, wells fargo,
comodo, entrust, equifax, gte, starfieldtech, godaddy, visa, valicert,
hungarian company netlock, the Taiwanese government, SwissComm all have
similar issues.

The architecture and protocols involved here need to be tweaked just a
to change the situation so that this problem will no longer exist[0]. The
Monkeysphere[1] project's broader goals are to make these sorts of
changes, and move us towards a decentralized web-of-trust model, instead
of depending on centralized hierarchical models of control. Currently
the project only works for SSH connections, but there is work ongoing to
make gnutls changes that will eventually lead us to a way out of this
dismal situation. If you are interested, the project could use help.


0. http://lair.fifthhorseman.net/~dkg/tls-centralization/
1. http://monkeysphere.info

Attachment: signature.asc
Description: Digital signature

Reply to: