In a wildcard certificate, the wildcard character should not be embedded within the U-label of an internationalized domain name. This was not properly implemented in NSS, as a result it did not handle IDNA domain prefixes according to RFC 6125, section 6.4.3 "Checking of Wildcard Certificates". http://tools.ietf.org/html/rfc6125#section-6.4.3

Upstream patch: https://hg.mozilla.org/projects/nss/rev/15ea62260c21 https://hg.mozilla.org/projects/nss/rev/2ffa40a3ff55 https://hg.mozilla.org/projects/nss/rev/709d4e597979

Upstream bug (not public): https://bugzilla.mozilla.org/showbug.cgi?id=903885

This issue was fixed upstream in NSS 3.16: https://developer.mozilla.org/en-US/docs/NSS/NSS3.16releasenotes

The Network Security Services (NSS) library before 3.12.3, as used in Firefox; GnuTLS before 2.6.4 and 2.7.4; OpenSSL 0.9.8 through 0.9.8k; and other products support MD2 with X.509 certificates, which might allow remote attackers to spoof certificates by using MD2 design flaws to generate a hash collision in less than brute-force time. NOTE: the scope of this issue is currently limited because the amount of computation required is still large.

In his upcoming Blackhat paper and presentation Dan Kaminsky highlights some more issues he has found relating to SSL hash collisions and related vulnerabilities.

His second issue is all about inconsistencies in the interpretation of subject x509 names in certificates. Specifically "issue 2, attack 2c" regarding NULL terminators in a Common Name field. An attacker could create a malicious certificate containing a NULL, which, if they were able to get it signed, could confuse a client into accepting it by mistake.

According to the paper this is said to affect Firefox.