Westpoint Security Advisory

Title:        Multiple Browser Wildcard Cerficate Validation Weakness
Risk Rating:  Low
Author:       Richard Moore <rich@westpoint.ltd.uk>
Test Cases:   Simon Ward <simon@westpoint.ltd.uk>
Date:         14 July 2010
Advisory ID#: wp-10-0001
URL:          http://www.westpoint.ltd.uk/advisories/wp-10-0001.txt
CVE:          not yet assigned


RFC 2818 covers the requirements for matching CNs and subjectAltNames in
order to establish valid SSL connections. It first discusses CNs that are
for hostnames, and the rules for wildcards in this case. The next paragraph
in the RFC then discusses CNs that are IP addresses:

'In some cases, the URI is specified as an IP address rather than a
hostname. In this case, the iPAddress subjectAltName must be present
in the certificate and must exactly match the IP in the URI.'

The intention of the RFC is clearly that you should not be able to use
wildcards with IP addresses (in order to avoid the ability to perform
man-in-the-middle attacks). Unfortunately our testing showed that this
rule is not adhered to by some browsers.

We created a certificate with the CN '*.168.3.48' this meets the various
rules for wildcards in CNs, but should be treated as invalid since it is
not a hostname. We then observed the errors reported by browsers when
connecting to an https server using this certificate run on IP address

We imported the test CA used to sign the certifcate in order to perform
the test.

The results we saw were as follows:

        Regarded the IP address as matching the CN (VULNERABLE)
        Regarded the IP address as matching the CN (VULNERABLE)

Firefox 3.6.6
        Regarded the IP address as matching the CN (VULNERABLE)
        Regarded the IP address as matching the CN (VULNERABLE)
        Reported the IP address did not match the CN (NOT VULNERABLE)
Safari 5 (win32)
        Reported the IP address did not match the CN (NOT VULNERABLE)

Qt (4.7 git development branch)
        Regarded the IP address as matching the CN (VULNERABLE)
Mitigating Factors

Obviously a good CA should refuse to issue a certificate with the CN as
indicated, however there only need be one CA to issue one in error for
this issue to result in the user getting no warning at all and being
vulnerable to MITM.

The rules for hostname matching mean that only the first octet of the
IP address can contain a wildcard. This means that you must be able to
control a server that matches the remainder of the IP address of your
target which reduces the risk of this attack being used dramatically.


If exploited then a MITM attack can be performed allowing the guarantees
SSL provides to be circumvented.


14 July 2010    Limited disclosure to browser developers.
14 July 2010    Added Safari result.
15 July 2010    Disclosure to official browser security contacts.
15 July 2010    Microsoft confirm receipt.
15 July 2010    Mozilla fix ready.
18 July 2010    Google confirm that Chrome will be fixed by the fix to NSS
                on linux, and any fix provided by Microsoft on Windows. They
                will therefore not be adding a work-around to the Chrome code.
4 August 2010   Microsoft confirm the issue will be fixed in a future service
                pack, and that the issue is low enough risk that they are not
                asking the information to be withheld.
10 August 2010  Patch sent to Nokia for Qt.
27 August 2010  At the time of writing the NSS (Firefox) and Qt repositories
                both contain fixes for this issue that will be included in
                their releases.

Designed & Built by e3creative