SSL certificate chain validation issues

[Daniel Atallah]

On Mon, Feb 10, 2014 at 11:43 PM, Daniel Atallah <datallah at pidgin.im> wrote:
> 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"

I had a first pass at a fix for this.

I don't think there's a way to fix this without API addition - we need
to get more information about each cert to be able to check the usage
constraints. Fortunately, there are 3 SSL plugin slots available, so
API addition is possible.

The path I went down doesn't fix the certificate validation
implementation in libpurple, instead it allows it to be delegated to
the SSL plugin, which I think is where the validation should occur -
we shouldn't be implementing that ourselves.

I only implemented it for NSS, but hopefully it shouldn't be too
tricky to implement for gnutls and whatever else stuff like adium
uses.

I've only tested this a small amount so far, and haven't yet reviewed
if there are other code paths that would need to be changed too.

I'm not sure what the best thing to do with the existing
implementation is - perhaps the best thing to do would be to cripple
it and have it fail unless the server certificate is explicitly
trusted (another option is to try to use up the last plugin action
slot to actually implement this).

I think this is something we probably should fix sooner rather than later.

-D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nss_ssl_validate.patch
Type: text/x-patch
Size: 12312 bytes
Desc: not available
URL: <https://pidgin.im/cgi-bin/mailman/private/security/attachments/20140419/44b91b06/attachment.bin>