Rich Megginson wrote:
> Nelson B wrote:
>> Below, you seem to be asking how they are stored in certificates.
>>
>> I'll answer the questions about what appear in certs.
>>
>>> 1) Are appended ports actually allowed in the subjectAltName or CN?
>> No.
>
> How about the return value from SSL_RevealURL( fd ) ? Will that contain
> anything except a hostname?
SSL_RevealURL and SSL_SetURL are a pair. SSL_SetURL makes a copy of the
string it is passed and stores that copy in the SSL socket. SSL_RevealURL
makes yet another copy of that string in the SSL socket and returns it to
the caller.
The string can contain anything, a host name, a URL, a favorite recipe.
NSS's SSL library uses the string in the SSL socket in just one place.
When the SSL protocol engine receives a certificate chain from the peer
system, it calls an application-supplied callback function to process that
received cert (chain). The application may supply its own function for
that purpose, or it may choose to use libSSL's own built-in function
SSL_AuthCertificate as that callback function. If the application does
not supply its own function, libSSL will call SSL_AuthCertificate by
default for that purpose. So the use of SSL_AuthCertificate is optional.
The application that uses libSSL is free to provide its own function for
the purpose of validating the received cert chain, and if it does so,
it is free to interpret the SSL socket's "url" string any way it chooses,
and/or not use that string at all.
SSL_AuthCertificate uses the url string stored in the SSL socket as the
source of the host name (or IP address string) that it compares to the
contents of the cert. It passes that string to CERT_VerifyCertName.
In CERT_VerifyCertName, if a SAN is present, the SAN contents are compared
to the string as described below. Otherwise, the string is used to compare
to the Subject Common Name (if any).
While comparing the string to the SubjectAltName, the string is passed to
PR_StringToNetAddr which attempts to see if it is an IPv4 or IPv6 address
(NOT a DNS name) and if so, attempts to convert it to a binary IP address.
Then, if the SAN contains dNSNAmes, they are compared to the string, and
if the SAN contains iPAddresses, they are compared to the IP address
returned by PR_StringToNetAddr.
AFAIK, PR_StringToNetAddr does not ever expect an IPv6 IP address to
contain brackets.
>>> 2) When an IPv6 literal address is in the CN or the subjectAltName, and
>>> if the answer to question 1 is that ports are not allowed, then are the
>>> square brackets that may surround IPv6 addresses still allowed?
>>
>> RFC 2818 only allows IP addresses in SubjectAltNames (SANs), not in
>> Subject name CommonName attributes.
>>
>> As defined in RFC 3280, IP addresses in SANs are stored in binary form as
>> "octet strings", that is, as 4-byte IPv4 or 16-byte IPv6 binary addresses,
>> not as strings of decimal ASCII characters separated by dots, nor
>> hexadecimal ASCII characters separated by colons. So, you won't see
>> brackets around IP addresses in certificates, because they aren't stored
>> as printable strings in certificates.
>
> Does that mean we need to convert them to their string representation
> before we call CERT_VerifyCertName(cert, hostname)?
Short answer: Converting a binary IP address to a string representation,
and passing that string to CERT_VerifyCertName is generally NOT advisable.
Generally, the host name or IP address that the user (or application)
provided (generally in string form) is the authoritative definition of the
server that you're trying to reach, and that's what you want to pass to
CERT_VerifyCertName.
The danger of taking an IP address in binary form and converting it to a
string form, and passing that to CERT_VerifyCertName, is that the binary
form may have come from a DNS lookup (or NIS lookup) and therefore may
already be falsified result. That is, a "poisoned" DNS or NIS server may
have already given you the wrong IP address, the address of an attacker's
system. You don't want to verify that the server's cert matches the
attacker-supplied IP address, because the attacker's server's cert will
undoubtedly match the attacker-supplied IP address. You want to verify
that the server's cert matches the authoritative "name" (host name or IP
address) of the intended server, supplied by the user. That acts as a
double-check that the DNS/NIS lookup did not send you to a attacker's server.
>> But even though the RFCs define how IP addresses are represented in
>> certificates, I think you'll not find any real CAs that issue certs with
>> IP addresses in them. There are a lot of reasons for that.
And now I've stated some of those reasons. There are still others.
>> And it's
>> not safe to use DNS lookups or reverse DNS lookups as part of the server
>> identity verification process. So, IMO, your best bet is to compare
>> the host names with the host names in the certs, and leave IP addresses
>> out of the server ide
