Bug 510202 - differences in handling of SSL Common Names (Kaminsky)
Summary: differences in handling of SSL Common Names (Kaminsky)
Status: NEW
Alias: None
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2009-07-08 10:57 UTC by Mark J. Cox
Modified: 2019-09-29 12:30 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed:

Attachments (Terms of Use)

Description Mark J. Cox 2009-07-08 10:57:10 UTC
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.

Comment 1 Mark J. Cox 2009-07-08 10:58:14 UTC
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:
     cyrus-imapd 2.2.12
     freeradius 1.1.13
     postfix 2.2.10
     fetchmail 6.3.6
     openldap 2.3.27
     gftp 2.0.17
     sendmail 8.13.1
     dovecot 1.0
     postgresql 7.3.19
     curl 7.10.6

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

Comment 3 Mark J. Cox 2009-07-30 15:40:44 UTC
presentation given by Dan yesterday at Blackhat, removing embargo.

Comment 4 Kevin Kofler 2009-07-31 00:37:15 UTC
Also removing EMBARGOED from the title as the embargo has been removed.

Comment 5 Howard Chu 2009-08-21 19:10:45 UTC
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.

Comment 6 Tomas Hoger 2009-08-26 13:09:23 UTC
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!

Comment 7 Howard Chu 2009-08-26 17:03:32 UTC
Yes, those commits also address CVE-2009-2408, tested / confirmed. (Actually our gnutls code was already correct on that issue.)

Comment 8 Tomas Hoger 2009-08-27 06:33:09 UTC
Thank you!  Yes, from the patch, it looked that GnuTLS variant was unaffected.

Note You need to log in before you can comment on or make changes to this bug.