SSL certificate chain validation issues

Daniel Atallah datallah at pidgin.im
Mon Feb 10 23:43:05 EST 2014


Folks,

I got a private report from Jacob Appelbaum about way that our certificate
chain validation works.

I haven't actually tested this, but it appears that libpurple is vulnerable
to the Basic Constraints validation issue that Moxie Marlinspike originally
discovered in IE in 2002.

Specifically, this means that any cert that has a valid path back to a
trusted CA be used to issue additional certs even if they're unrelated.

The following describes the scenario in detail:
http://www.thoughtcrime.org/ie-ssl-chain.txt
http://www.thoughtcrime.org/blog/strongtrustmanager-mitm/

We rely on the SSL library's implementation to do the checking in the
x509_signed_by function.

In the case of the NSS implementation, we don't appear to be using any of
the functionality that looks at the certificate constaints - it's just
checking that there is a valid signature by the issuer.
There are NSS functions that would validate the whole chain appropriately
(e.g. CERT_VerifyCertChain), but we'd need to interface our certificate
store with the NSS Cert Database API somehow (which doesn't seem too
horrible).
Alternatively, we can do more work ourselves to duplicate what
CERT_VerifyCertChain does, but it seems like ideally we'd delegate this
type of thing to the library.

In the case of the gnutls implementation, by default,
gnutls_x509_crt_verify would do some checking, but since we're using the
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT flag, the checking appears to be
bypassed.

I guess that Jacob discovered it working with a friend who would like to
remain anonymous - the request was that the credit be something like the
following:
"Credit should be attributed to anonymous and Jacob Appelbaum of the Tor
Project with a nod to Moxie Marlinspike"

He suggested that we look at the Chrome certificate validation code -
apparently it is a good thorough example (not sure how easy to read it is
or where the specific code is).

He also mentioned some other items to look at:

* In addition to Basic Constraints, we should look at Extended Key Usage
checking
* We should disallow Renegotiation (
http://www.thoughtcrime.org/blog/sslsniff-anniversary-edition/ has details)

-D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/cgi-bin/mailman/private/security/attachments/20140210/47963767/attachment.html>


More information about the security mailing list