[gnutls-devel] SSL certificate validation bugs in GnuTLS
luto at amacapital.net
Thu Feb 13 09:48:37 CET 2014
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,
> > testing
> > several SSL/TLS implementations as part of a research project. When
> > GnuTLS,
> > we discovered the following security issues related to SSL/TLS
> > validation.
> > Some of them may be deliberate violations of the X.509 standard, others
> > appear to be
> > bugs.
> 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 certiﬁcate has been
> > prevent
> > any further v1 certiﬁcates from being accepted, GnuTLS clears the
> > GNUTLS_VERIFY_ALLOW
> > _X509_V1_CA_CRT ﬂag before calling _gnutls_verify_certificate2.
> > _gnutls_
> > verify_certificate2 function accepts v1 certiﬁcates unless a different
> > 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
> > 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.
> Gnutls-devel mailing list
> Gnutls-devel at lists.gnutls.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnutls-devel