[nSLUG] GnuTLS certificate bug and Apple certificate bug

Julien Savoie julien.savoie at usainteanne.ca
Tue Mar 18 21:50:27 ADT 2014

On 18/03/14 10:47 AM, Gerald Ruderman wrote:
> My conclusion in the case of the GnuTLS and Apple certificate bugs is
> that there was no test to see that an invalid certificate was rejected.
> Would such a test have caught these bugs?
That's an oversimplification in both cases.  Allow me to describe both

In the case of the IOS/OSX vuln, there was a bypass (goto fail!) of the
check to see if the session key (used for forward secrecy) was signed
correctly by the right long-term private key.  The long-term certificate
still had to be valid, and SSL certificate pinning gave no protection
against this.  This ended up being easy vulnerability to exploit and
mitmproxy was quickly patched to do so.

1.  Offer the right x509 certificate.
2.  Offer a PFS cipher, such as diffie-hellman.
3.  Sign the session key with anything, or don't.
4.  Profit.

Or using Apache:
SSLCertificateFile /etc/ssl/certs/rightcertificate.crt
SSLCertificateKeyFile /etc/ssl/private/wrongkey.key

Potentially any semi-competent bad guy testing iOS banking applications
would have happened on this.  Now the GnuTLS vuln was a bit different,
in this case a properly crafted certificate (just make
_gnutls_x509_get_signed_data() fail) would be accepted as valid, even if
it weren't signed by a certificate authority (ie self-signed).  In this
case the bug was a type mismatch, sending -1 for failure when it
expected a boolean (anything not zero is true).

Coding changes to fix it:

Would a x509 certificate "fuzzer" have found this?  Yes.

On 18/03/14 12:04 PM, George N. White III wrote:
> The certificate system is on a par with airport security checks --
> necessary to keep
> people using planes and online commerce, but they only keep out inept
> bad guys.
Respectively, that's not good enough.  We use ssl/tls/x509 to protect
billions in commerce and confidential communications.  We need to do better.

More information about the nSLUG mailing list