Red Hat Bugzilla – Bug 510202
differences in handling of SSL Common Names (Kaminsky)
Last modified: 2010-03-04 04:37:00 EST
In his upcoming Blackhat paper and presentation Dan Kaminsky
highlights some more issues he has found relating to SSL hash
collisions and related vulnerabilities.
This issue is about how Common Names are checked for validity by applications. For example if a server presents a certificate with two CN entries, how does the app validate those. Does it use the first one, the last one, or all of them?
It turns out that OpenSSL applications do things in different ways. However as the research continued it was noted that the general rule is that a certificate authority must validate all the CN in a certificate they sign. So it's not the case that you could sneak a certificate request past a CA with a legitimate and malicious CN in such a way that an application would be fooled with a security context.
The consensus of the meetings with Dan Kaminsky is that applications should validate all CN in a presented certificate (if there is no subjectAltName, SAN).
Although RFC2818 states that if there is no SAN you should use the 'most specific CN'.
No OpenSSL code change will be made, OpenSSL already provides an API that allows an application to check multiple CN if it so wishes.
Multiple Common Names handled differently
I've been looking at various applications that use OpenSSL to check CN
and how they deal with multiple CNs. So I found things we ship in Red
Hat products (not necessarily the latest versions of each):
Just uses least specific CN:
neon: the code quoted in the draft Kaminsky paper is from a very old (more than 5 years old) version of neon. Neon since 0.22 at least has used the most specific CN if there is no subjectAltName (using different function X509_NAME_get_index_by_NID)
curl 7.12.1: uses most specific CN if no subjectAltName, but older versions (7.10.6) used least specific
w3m 0.5.1: uses least specific CN if no subjectAltName
squid 2.6: uses any CN if no subjectAltName
wget 1.10.2: uses least specific CN but code notes it should be 'most specific'
libesmtp 0.8.12: uses least specific CN, but code notes it should be 'any'
pam_pkcs11 0.5.3: gets all CN
presentation given by Dan yesterday at Blackhat, removing embargo.
Also removing EMBARGOED from the title as the embargo has been removed.
Just fyi, this was fixed in OpenLDAP CVS on August 10 for our OpenSSL and GnuTLS support. It was fixed on July 30 for our MozNSS support.
Hey Howard, thanks for heads-up. I presume you are referring to following commits:
I presume those fixes should also address CVE-2009-2408-like problem where they existed before (from quick testing, it seems at least OpenSSL variant had issues with NULs in CNs). Have you looked at / tested that too? Thanks!
Yes, those commits also address CVE-2009-2408, tested / confirmed. (Actually our gnutls code was already correct on that issue.)
Thank you! Yes, from the patch, it looked that GnuTLS variant was unaffected.