Just a word for those who have been living under a rock for the last
ten years: SSL, or at least HTTPS, is based upon an oligocracy of
"trusted CA". Their certificates are hard coded in all web browsers, or
hidden in some [undocumented] file.
(On my Redhat, those trusted CA are stored in
/usr/share/ssl/certs/ca-bundle.crt ; OpenSSL loads those certificates
with SSL_CTX_set_default_verify_paths)

Discussing about this and the risks with colleagues, we started to
wonder how the web browsers verified the CA certificates.
We supposed that the browser checked every field, or at least the
certificate hash. That's what any SSL library should do (and does,
AFAIK).
However, you sometimes need specific information that the high level
functions cannot return. You then have to use low level functions, and
that becomes rather complicated. The risk would be that a programmer
only looked at the DN, because he is lazy or did not understand the
cryptographic concepts.

Creating a certificate with exactly the same fields as some trusted
root CA (e.g. Verisign) is very easy.
IE 6 and Mozilla display an "unknown CA" warning. So far so good. The
danger here is that a user would install the fake Verisign certificate,
but this was not my topic.

Does somebody know a broken software that would fail to identify the
fake CA certificate?

___________________________________________________________
Do You Yahoo!? -- Une adresse yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]