[gnutls-devel] SSL certificate validation bugs in GnuTLS

[Andy Lutomirski]

On Feb 12, 2014 7:40 AM, "Nikos Mavrogiannopoulos" <nmav at gnutls.org> wrote:
>
> On Tue, Feb 11, 2014 at 11:35 AM, Suman Jana <suman at cs.utexas.edu> wrote:
> > Hi,
> >
> > We are computer security researchers at UT Austin and UC Davis,
currently
> > testing
> > several SSL/TLS implementations as part of a research project. When
testing
> > GnuTLS,
> > we discovered the following security issues related to SSL/TLS
certificate
> > validation.
> > Some of them may be deliberate violations of the X.509 standard, others
> > appear to be
> > bugs.
>
> Hello,
>  Thank you for the report. Comments inline;
>
> > As far as we know, none of them is documented.
>
> Please feel free to provide patches to improve documentation. That is
> the essence of free software.
>
> > 1. v1 CA certificates should be rejected by default unless validated by
> > external means but GnuTLS accepts it.
>
> You are correct. This is a bug in current code.
>
> > As shown in the code above, after a root v1 certificate has been
accepted, to
> > prevent
> > any further v1 certificates from being accepted, GnuTLS clears the
> > GNUTLS_VERIFY_ALLOW
> > _X509_V1_CA_CRT flag before calling _gnutls_verify_certificate2.
However, the
> > _gnutls_
> > verify_certificate2 function accepts v1 certificates unless a different
flag,
> > GNUTLS_VERIFY_
> > DO_NOT_ALLOW_X509_V1_CA_CRT is set. But the caller
> > (_gnutls_x509_verify_certificate)
> > never sets that flag.
>
> Nice trace of the issue. I've now fixed it in the repository.

This should IMO have a CVE assigned and announcement made.  If I understand
the issue correctly, this will be widely exploited.

If this affects verification of client certs, everyone is fscked.

>
> > 2. Path length constraints in CA certs should be enforced. GnuTLS
ignores
> > Path length constraints.
>
> Which version of gnutls did you use? GnuTLS supports path length
> constraints for quite some time now.
>
> > 3. Name constraints in CA certs should be enforced. GnuTLS ignores name
> > constraints.
>
> I believe that you haven't read RFC5280 :) GnuTLS will support name
> constraints when there is a reasonable profile defined. As it is now,
> the PKIX name constraints are a mess.
>
> > 4. keyUsage and extendedKeyUsage extensions in CA and leaf certificates
> > should be checked
> > correctly. GnuTLS does not check any of them.
>
> We used to check them (the keyUsage) and people were reporting it as a
> bug. See: http://www.gnutls.org/faq.html#key-usage-violation
> Since the keyusage is set by system administrators who have no idea
> what should go there, there is no much point in enforcing it
> (especially when no-else does and your software looks broken when it
> is strict).
>
> > 5. Certificate validation must fail if unknown critical extensions are
> > present in the certificate
> > but GnuTLS accepts certificates with unknown critical extensions.
>
> That is from the time when there was a single company that controlled
> most of the available software generating certificate. It would have
> been very easy for them to lock out gnutls if we have supported this
> rule. I may reconsider if there is any real issue.

Of course there's an issue.  It prevents anyone from *fixing* the disaster
that is PKIX.

Fortunately (?) issue #1 is sufficiently severe that, if you fix both
issues together, old GnuTLS versions won't hold CAs back from issuing
intermediate certs w/ critical constraints for GnuTLS's sake.

--Andy

>
> regards,
> Nikos
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140213/6655a4cc/attachment.html>