|Summary:||<dev-libs/nss-3.12.8: Wildcard Cerficate Validation Weakness (CVE-2010-3170)|
|Product:||Gentoo Security||Reporter:||Tim Sammut (RETIRED) <underling>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Package list:||Runtime testing required:||---|
Description Tim Sammut (RETIRED) 2010-09-02 22:34:56 UTC
From $url: 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 192.168.3.48. The upstream bug _may_ be: https://bugzilla.mozilla.org/show_bug.cgi?id=578697
Comment 1 Tim Sammut (RETIRED) 2010-11-22 03:59:36 UTC
According to the upstream bug (https://bugzilla.mozilla.org/show_bug.cgi?id=578697) this was fixed in NSS 3.12.8, which is already in tree and stable. GLSA Vote: no.
Comment 2 Jory A. Pratt 2010-12-30 03:50:45 UTC
Mozilla team is not needed here.
Comment 3 Sune Kloppenborg Jeppesen (RETIRED) 2011-01-03 20:50:21 UTC
GLSA Vote: no -> Closing. Feel free to reopen if you disagree.