Bug 510202 - differences in handling of SSL Common Names (Kaminsky)
differences in handling of SSL Common Names (Kaminsky)
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On:
  Show dependency treegraph
Reported: 2009-07-08 06:57 EDT by Mark J. Cox
Modified: 2010-03-04 04:37 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mark J. Cox 2009-07-08 06:57:10 EDT
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 06:58:14 EDT
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 11:40:44 EDT
presentation given by Dan yesterday at Blackhat, removing embargo.
Comment 4 Kevin Kofler 2009-07-30 20:37:15 EDT
Also removing EMBARGOED from the title as the embargo has been removed.
Comment 5 Howard Chu 2009-08-21 15:10:45 EDT
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 09:09:23 EDT
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 13:03:32 EDT
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 02:33:09 EDT
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.