-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ########################################################################### # # # Phishing for Confirmations # # # # Certificate spoofing with subjectAltName and domain name wildcards # # # ########################################################################### URL: Version: 2007-11-27-13 Author: Nils Toedtmann License: Dual Creative Commons BY-ND & BY-NC-SA (see below) Disclaimer ============ 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. Abstract ========== 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 , check it out. Introduction ============== 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]. subjectAltName ================ 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. Domain name wildcards ======================= 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. Accepting certificates permanently ==================================== 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. The real world: results by bug ================================ * [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 ;) Results by browser ==================== * 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 M8) [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]. Affected by [no-cert-name-binding] (Mozilla <= 1.8, Mozilla 1.9 <= M8) * Firefox 2.0.0.10 (Linux), 2.0.0.9 (Win32), 2.0.0.8 (FreeBSD) * Firefox 3.0 Alpha (3.0a8/Linux, 3.0a7/Win32) * Iceweasel 2.0.0.7 * IceApe 1.1.5 * Netscape 9.0 (Win32) * SeaMonkey 1.1.5 (Win32) * Epiphany 2.18.1 * K-Meleon 1.12 Not affected by [no-cert-name-binding] (Mozilla >= 1.9 M9) * Minefield 3.0a9pre * Firefox 3.0 Beta 1 * SeaMonkey 2.0a1pre >= 2007101002 (maybe earlier) * 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 on 2007/11/06, issue under investigation at kde.org. * Konqueror 3.5.5 [ToDo: 3.5.8], 3.95.00 (=4.0 Beta4) * 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." * Safari 2.0.4 (MacOS 10.4.10/WebKit 419.3) * Safari 3.0.4 (MacOS 10.4.11/WebKit 523.12, MacOS 10.5/WebKit 523.10.3) * Safari Public Beta for Windows 3.0.4 (Win32/WebKit 523.12.9) * 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. * Opera 9.0.23 (Linux) * Opera 9.0.24 (Win32) * 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... * MSIE 6.0.2900.2180 (WinXP Pro SP2) * MSIE 7.0.5730.11 (WinXP Pro SP2) * MSIE 7 (Windows Vista Ultimate) [ToDo: exact version] Sources ========= [1] Recent DNS spoofing issues CVE-2007-2930: CVE-2007-2926: MS07-062 [2] DE-registry press releases about the hijacking of eBay.de and google.de (German) [3] dsniff ettercap [4] IDN homograph spoofing [5] Recent URL spoofing issues CVE-2007-3656, CVE-2007-3826, CVE-2007-3819 [6] RFC 3280: "Internet X.509 Public Key Infrastructure" [7] RFC 3546: "Transport Layer Security (TLS) Extensions" (SNI) [8] RFC 2818: "HTTP Over TLS" (HTTPS) [9] Mozilla bugtracker #159483: "cert name matching: RFC 2818 vs. backwards compatibility" #238142: "server mismatch dialog doesn't show subject alt names" #240261: "peer-trusted certs can use alt names to spoof" (now public) #327181: "Improve error reporting for invalid-certificate errors" (#28, #51, #72) #402347: "Not binding X.509 certificate to originating domain name allows certificate spoofing" (dupe of #240261) * Peter Gutmann: "X.509 Style Guide" Peter Gutmann: "Security Usability Fundamentals" * Geotrust: "Vulnerability of First-Generation Digital Certificates [...]" * subjectAltName test site * Full-disclosure posting ToDo ====== * Translate into proper English * Test more browsers (Camino) and other TLS clients like MUAs * Check MSIE for reg-hacks to alter cert handling * Actually read the referenced sources ;) * Find a braindead major-browser-accredited CA which signs my certificate request with hidden TLD-wildcard subjectAltName. Take over the internet. License ========= 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 About me ========== My name is Nils, and i am yet another paranoid network admin. Contact: $ whois toedtmann.net | grep owner-c Credits ========= * Finding: John G. Myers reported this first to mozilla.org [9, #240261] 04/2004, Frank Benkstein rediscovered it 09/2005 [9, #308244] * Testing: Joerg Baach, Oliver Regehr, Uli Groene, Ingo Luetkebohle, Oliver Schonefeld, Marcus Grieger * Hosting: Fargonauten , Marcant * Wordproc: Vim , Aspell, LEO * Birthing: Mami 123456789|123456789|123456789|123456789|123456789|123456789|123456789|123456789 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTBGrWSNYFlGcTrMRAgG8AKCcPxGJdNogFoDKuOr2Tys1DBvmrwCdHRyJ HPUcPcoEhJfu1oT7pUKgoM0= =5BUs -----END PGP SIGNATURE-----