Open Bug 553754 Opened 12 years ago Updated 11 years ago

Stop honoring string representations of IP addresses in all cert fields from which we take DNS names

Categories

(NSS :: Libraries, defect)

defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: nelson, Unassigned)

References

Details

Today, NSS allows Certificate SubjectAltName dNSNames and Subject CommonNames 
to hold string representations of IP v4 or IP v6 addresses, e.g. strings
such as 192.168.0.1 or 2010:2009:2008:2007:2006:2005:2004:2003 and it will
match them to identical strings found in URLs, e.g. as in

   https://192.168.0.1/index.html

because it is actually matching them as if they were host names.  It should
dishonor names of these forms when found in certificates.
NSS does not honor IP addresses in subjectAltName dNSNames.  cert_VerifySubjectAltName will see that the expected name is an IP address and compare it to the subjectAltName iPAddresses instead.  This is the behavior specified by RFC 2818.

NSS does honor a string IP address in the common name using string comparison.  RFC 2818 says that only subjectAltName iPAddresses should be honored, but I don't see a security problem in honoring an IP address in the common name and people may be currently relying on that, so I would suggest considering its removal as part of bug 552346.
As per comment #1, I don't believe there is anything to do in this bug.  Nelson, if you agree, please close it appropriately.
RFC 2818 is purely informational. The current SSL CA policy of Mozilla does not describe how to secure a IP address. Being able to match a IP address is a hack, and there's no good reason to keep that hack working.
(In reply to comment #3)
> Being able to match a IP address is a
> hack, and there's no good reason to keep that hack working.

...other than that people might be using it on intranets and such?
Duplicate of this bug: 550592
what does an intranet cert for 192.168.x.x mean? NSS can't guarantee the server -- maybe you're temporarily at a coffee shop and connecting to someone else's 192.168.x.x. Or maybe a bad guy has infiltrated your network and is using the 192.168.x.x cert he got for his own network to MITM you on your network.
The situation is exactly the same as for unqualified DNS names (see bug 401317).  Public CAs should never issue certificates for 192.168.x.x, but a CA specific to the intranet could, and machines using that intranet could meaningfully trust that CA to identify other machines on the intranet.
If an internal CA wished to issue a certificate for 192.168.x.x, it could still use the iPAddress subjectAltName, which comment #1 indicates would still be supported. What would be removed would be recognizing the commonName as being a possible match for an IP address when no iPAddress SAN was present.

From a BCP approach, the following behaviours are observed when testing with a certificate with no sAN and with a CN of "127.0.0.1":

Safari 5 on Mac - defers to AppleX509TP module and REJECTs the certificate. If the supplied host name parses as an IPv4 address, it must appear in an iPAddress SAN for the name match to be considered valid. It will NOT be string matched against the common name if no sANs are present.

Chrome 7 on Mac - defers to AppleX509TP, but will override the failure if the hostname was an IPv4 address and a match can be found in either the dNSName SANs or in the common name.

Internet Explorer 8 / Chrome 7 on Windows - ACCEPTs the certificate, matching the literal string to the common name.

Opera 10.53/10.63 on Windows - ACCEPTs the certificate, matching the literal string to the common name.

Chrome 7 on Linux - uses NSS, same behaviour described above.
You need to log in before you can comment on or make changes to this bug.