Rich Megginson wrote:
Nelson B wrote:
Ulf Weltman wrote:
Hi all. I'm writing some code that prepares compact host:port
addresses for certificate CN checking. This is to handle an
application that keeps a host list like "foo.example.com
192.168.1.1:2389 [fe80::230:6eff:fe4b:703]
[fe80::230:6eff:fe4b:703]:3389".
After browsing through various RFCs I'm still not sure what rules my
address parsing should follow. Does anyone know the answers or have
a pointer to where I can find them?
Above, you seem to be asking how to store addresses in your application.
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?
To answer my own question - yes, it looks as though it can. It looks as
though it gives back whatever was set with SSL_SetURL. Looking at the
NSS code, every place SSL_RevealURL is called expects just a simple
hostname to be returned (or at least one that CERT_VerifyCertName() will
accept). Every place in the code where SSL_SetURL is called, a simple
hostname is passed in.
In the LDAP C SDK code, we call SSL_SetURL with the hostlist argument
which is passed in to ldapssl_connect(). So I suppose the real fix for
the ldap c sdk is to make sure we call SSL_SetURL with a simple
hostname. I think the hostlist parameter can be formatted like this:
"host:port host:port ...." This is set if you attempt to use one of the
API functions which takes an LDAP URL, which can be in the form
"ldap://host:port host:port ... host:port/"
The functions ldap_x_hostlist_first/ldap_x_hostlist_next are used to
parse and iterate through these host/port combinations. I think the
real problem is that we can't figure out which of these hostnames was
the one we actually connected to. In the LDAPSSL case, prldap_connect
does the hostlist parsing, but it doesn't save the hostname anywhere, so
I'm not sure how ldapssl_connect() is supposed to figure that out.
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)?
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 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 identity verification picture.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
