-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
###########################################################################
###########################################################################
URL: <http://nils.toedtmann.net/pub/subjectAltName.txt>
Version: 2007-11-16-07
Author: Nils Toedtmann <[email protected]>
License: Dual Creative Commons BY-ND & BY-NC-SA (see below)
This is not an advisory but a reproval. These issues have been discussed for
years now at mozilla.org. But the developers seem to underestimate or ignore
their severeness, particularly when being combined. Additionally i found
(probably not at first) that more browsers are affected.
Modern browsers accept more than one (wildcard) domain name within a X.509
certificate, although displaying only one of them (the DN's CN) to the user.
It is essential for preventing TLS-enriched domain name spoofing to bind
user-approved certificates from unknown CAs to the presenting hostname.
Mozilla based browsers, Konqueror and Safari 2 fail that binding, so once a
user accepted a certificate issued by a CA unknown to the browser, he is
vulnerable to certificate spoofing.
To make things worse, some browsers match generic wildcard domain names
like *.com or even *.
There's a demonstration at <http://test.eonis.net/>, check it out.
There were and are and will be many ways to trap browser to a false web server
with a spoofed hostname. For example DNS spoofing [1], domain name hijacking
[2] or other man-in-the-middle attacks [3].
Domain name authentication through X.509 certificates is an additional line of
defense against browser-external phishing attempts as the phisher cannot spoof
the TLS-handshake with the original certificate. But this defense only holds
if browser and user handle certificates properly.
B.t.w: Even correctly handled certificates do not protect against similar-
hostname-attacks [4] or in-browser attacks like location bar manipulation [5].
The X.509 standard [6] defines the certificate extension "subjectAltName". It
can be used to supply additional information about the certificate's subject.
When used for TLS, certificates can carry only one domain name in the
subject's DN ("distinguished name") field CN ("common name"), so additional
domain names are stored as subjectAltName:dNSName. (Some implementations
accept more than one CN in a DN, but that's uncommon.)
Modern browsers respect this. They consider a X.509 certificate valid for
a web server only if the CN part of the certificate's subject DN or one of
the subjectAltName:dNSName extensions matches the web server's hostname
(Some browsers ignore the CN if a subjectAltName:dNSName is present). As long
as the TLS extension "server name indication" (SNI) [7] is not widely adopted
by clients and servers, this is a useful method for virtual HTTPS hosting.
If a HTTPS-server presents a certificate during the TLS handshake but its
issuer is not in the browser's list of accredited trustworthy CAs, the browser
raises a warning. The user may decide to accept the certificate (temporarily
or permanently by installing it into the browser's certificate storage) and
to proceed.
Unfortunately, no major browser displays existing subjectAltName:dNSName fields
in the standard certificate view dialog, although subjectAltName:dNSName has
become equivalent to the displayed subject's CN. The user has do dive deeply
into the "certificate details" to detect bogus subjectAltNames.
When a second (virtual) HTTPS-server (different hostname, same or different IP
address) presents the same certificate, the browser SHOULD raise the "unknown
issuer" warning again, even if the hostname matches one of the certified
domain names. If the browser fails in binding user-approved certificates to the
originating hostname the user won't notice certificate spoofing. Unfortunately,
RFC 2818 (HTTPS) [8] does not cover this case.
Subject's CN and subjectAltName may be wildcard domain names like
*.example.com. Wildcard matching is not specified in RFC 3280 but RFC 2818:
"Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., .a.com matches foo.a.com but
not bar.foo.a.com. f.com matches foo.com but not bar.com."
So "loose matching" like www.test.example.com=.example.com or
www.example.com=.com or example.com=* violates RFC 2818.
And though standard compliant, matching "generic wildcards" like top- or
second-level wildcards (museum.=, example.com=.com) or third-level wildcards
within generic SLDs (example.co.uk=*.co.uk) should be considered bad practice.
If a user visits a HTTPS server with a unknown-issuer-cert regularly, she may
wish to avoid the "unknown issuer" warning. A browser SHOULD offer the option
to store the web server's certificate permanently. Both alternatives -
accepting the cert on each connect temporarily or storing and trusting the
parent CA certificate permanently - are less secure. The former does not
protect against certificate spoofing on subsequent connects, the latter also
trusts all other certificates issued by that CA.
Of course the web server's certificate should be bound to it's hostname again.
[loose-wildcard-match]
Matching the wildcard "*" with the dot (which is a violation of standards)
and/or matching SLD and TLD wildcards is a minor security issue, but it
aggravates the next two.
Results: Mozilla based browsers, Safari 2 and Opera suffer from it. All
major browsers match wildcards in generic SLDs like "*.co.uk".
[subjectAltName-not-shown]
Not displaying existing subjectAltNames in the standard certificate view
is - alone - a slight security issue. But it worsens the next one as the
user has almost no chance to notice a spoofing attempt.
Results: All tested browsers suffer from this.
[no-cert-name-binding]
Not binding user-approved certificates to the originating hostname is a
major bug which enables certificate spoofing. Results:
Results: Browsers based on Mozilla <=1.9a8, Konqueror, and Safari 2 are
affected.
[servercert-storage]
Lacking this feature is not a bug but leads to less secure certificate
handling. Results:
Opera cannot store web server certificates. MSIE and Safari can, but that
does not eliminate the "unknown issuer" warnings.
This time the points go to Mozilla & Konqueror, at least ;)
Mozilla based
loose-wildcard-match: Affected [9, #159483 from 07/2002]
subjectAltName-not-shown: Affected [9, #238142 from 03/2004]
no-cert-name-binding: AFFECTED! (>=1.9 not) [9, #240261 from 04/2004]
servercert-storage: Yes
Note: Mozilla 1.9 (>= M9) incorporates a new, sophisticated version of its
certificate manager "Personal Security Manager" (PSM) which binds certs to
hostnames. Upcoming Firefox 3 will be based on this.
Vendor status: #402347 filed on 2007/11/03, declared DUPE of #240261
(filed 2004/04/11), fixed in Mozilla-1.9/Firefox-3 [#327181], declared
WONTFIX for Mozilla-1.8/Firefox-2 [#402347 comment #4].
Konqueror
loose-wildcard-match: - (but matches wildcards in generic SLDs)
subjectAltName-not-shown: Affected
no-cert-name-binding: AFFECTED!
servercert-storage: Yes
Note: Konqueror does not show any certificate extension (like
subjectAltName), not even in the details.
Vendor status: Bug report sent to <[email protected]> on 2007/11/06,
issue under investigation at kde.org.
Safari
loose-wildcard-match: - [ToDo: S3/MacOS] [Safari2: Affected]
subjectAltName-not-shown: Affected
no-cert-name-binding: - [Safari2: AFFECTED!]
servercert-storage: See note
Note: Safari actually can store webserver certs, but without trusting
the parent CA cert that does not eliminate "unknown issuer" warnings.
Safari 3 Public Beta for Windows has no own certificate storage but uses
Windows' certificate list and validation mechs, so see MSIE instead.
Vendor status: Reply from the Apple Product Security team: "There is no
plan to address this in Safari 2. Safari 3 is recommended for all Safari 2
users and is available as a free upgrade as part of 10.4.11."
Opera
loose-wildcard-match: Affected
subjectAltName-not-shown: Affected
no-cert-name-binding: -
servercert-storage: Missing
Note: Opera has no option to install a web server certificate but makes
installing the parent CA cert very easy (2 clicks). This misleads users
annoyed by warnings to do so.
MSIE
loose-wildcard-match: - (but matches wildcards in generic SLDs)
subjectAltName-not-shown: Affected
no-cert-name-binding: -
servercert-storage: Missing (see note #1)
Note 1: MSIE can actually store web server certificates, but without
trusting the parent CA cert that does not eliminate "unknown issuer"
warnings.
Note 2: If there is a problem with the web server's certificate, MSIE7
just says that "there is some problem". If you want to view the cert, or
to know the nature of the problem (maybe the cert just expired?) you have
to proceed. When you then realize that the CA is wrong, the cookie is
stolen already.
Note 3: Microsoft's attitude "There's a problem, but you do not need
to know what kind of a problem. Abort (recommended) or proceed?" is really
counterproductive and will not raise security awareness amongst users. In
fact, users get trained to ignore security alerts. But that's another
story…
[1] Recent DNS spoofing issues
CVE-2007-2930: <http://www.trusteer.com/docs/bind8dns.html>
CVE-2007-2926: <http://www.trusteer.com/docs/bind9dns.html>
MS07-062 <http://www.microsoft.com/technet/security/bulletin/ms07-062.mspx>
[2] DE-registry press releases about the hijacking of eBay.de and google.de
<http://www.denic.de/en/denic/presse/press_60.html>
<http://www.denic.de/de/denic/presse/press_79.html> (German)
[3] dsniff <http://monkey.org/~dugsong/dsniff/>
ettercap <http://ettercap.sourceforge.net/>
[4] IDN homograph spoofing
<http://www.shmoo.com/idn/homograph.txt>
[5] Recent URL spoofing issues CVE-2007-3656, CVE-2007-3826, CVE-2007-3819
<http://www.heise-security.co.uk/news/92725>
[6] RFC 3280: "Internet X.509 Public Key Infrastructure"
<http://www.ietf.org/rfc/rfc3280.txt>
[7] RFC 3546: "Transport Layer Security (TLS) Extensions" (SNI)
<http://www.ietf.org/rfc/rfc3546.txt>
[8] RFC 2818: "HTTP Over TLS" (HTTPS)
<http://www.ietf.org/rfc/rfc2818.txt>
[9] Mozilla bugtracker
#159483: "cert name matching: RFC 2818 vs. backwards compatibility"
<https://bugzilla.mozilla.org/show_bug.cgi?id=159483>
#238142: "server mismatch dialog doesn't show subject alt names"
<https://bugzilla.mozilla.org/show_bug.cgi?id=238142> (not public)
#240261: "peer-trusted certs can use alt names to spoof"
<https://bugzilla.mozilla.org/show_bug.cgi?id=240261>
#327181: "Improve error reporting for invalid-certificate errors"
<https://bugzilla.mozilla.org/show_bug.cgi?id=327181> (#28, #51, #72)
#402347: "Not binding X.509 certificate to originating domain name allows
certificate spoofing" (dupe of #240261, but public)
<https://bugzilla.mozilla.org/show_bug.cgi?id=402347>
Peter Gutmann: "X.509 Style Guide"
<http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt>
Peter Gutmann: "Security Usability Fundamentals"
<http://www.cs.auckland.ac.nz/~pgut001/pubs/usability.pdf>
Geotrust: "Vulnerability of First-Generation Digital Certificates […]"
<http://www.antiphishing.org/sponsors_technical_papers/SSLVulnerabilityWPcds.pdf>
subjectAltName test site <http://test.eonis.net/>
This document is dual licenced under the Creative Commons licenses BY-ND 3.0
and BY-NC-SA 3.0, so you may distribute it unaltered. For noncommercial
purposes you may do anything you want unless you credit me and keep the
BY-NC-SA license. See
<http://creativecommons.org/licenses/by-nd/3.0/>
<http://creativecommons.org/licenses/by-nc-sa/3.0/>
My name is Nils, and i am yet another paranoid network admin. Contact:
<[email protected]>
$ whois toedtmann.net | grep owner-c
123456789|123456789|123456789|123456789|123456789|123456789|123456789|123456789
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHQFtVWSNYFlGcTrMRAuinAJ4zinO74OeoEhGnRU9TAOsZXgSmxQCfb3wr
Ob8/FNQThEHekHFjhdne9N8=
=3jmj
-----END PGP SIGNATURE-----