350646 - ldapssl_AuthCertificate fails on hostnames with appended port

Status: NEW

(Directory :: LDAP C SDK, defect)

Description

[Ulf Weltman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

SSL_RevealURL() "[returns] a pointer to a newly allocated string containing the domain name of the desired server" but it can return the port too if we used a compact address like host.example.com:389.  ldapssl_AuthCertificate() passes that string to CERT_VerifyCertName() which fails.

To illustrate:
# ./ldapsearch -3 -h host.example.com -p 636 -Z -P /tmp/cert8.db -s base -b "" "objectclass=*" dn
version: 1
dn:
# ./ldapsearch -3 -h host.example.com:636 -Z -P /tmp/cert8.db -s base -b "" "objectclass=*" dn
ldap_search: Can't contact LDAP server
        SSL error -12276 (Unable to communicate securely with peer: requested domain name does not match the server's certificate.)

There are lots of ways to fix this, any ideas on what's right?

NSS could strip off the port in either SSL_RevealURL() or the standard cert check hook CERT_VerifyCertName() before the strcasecmp() with the CN.

Or LDAP SDK can strip off the port in ldapssl_AuthCertificate() before sending the result of SSL_RevealURL() to CERT_VerifyCertName().

Or the application developer using CNCERT policy can take care to only use the ldapssl_init("host.example.com",636,1) form.  Or the application developer can roll his own certificate validation function.

But it ought to be addressed somewhere especially if bug #153514 is implemented for LDAP SDK 6.0.

Reproducible: Always

Comment 1

[Rich Megginson]

> Or LDAP SDK can strip off the port in ldapssl_AuthCertificate() before
> sending the result of SSL_RevealURL() to CERT_VerifyCertName().

This seems like the right thing to do.  We only care about the hostname in this context.

Comment 2

[Ulf Weltman]

Attachment: Patch proposal, remove port and separator before CERT_VerifyCertName

Does this look OK?

BTW, RFC 4513 it seems section 3.1.3.3 allows for stuff other than hostname in the subjectAltName, like maybe a host:port for certs issued to a particular port on a particular host.  But the code we're looking at is probably only intended for hostname use, so I guess it's still OK to assume we can throw out the port.

Comment 3

[Rich Megginson]

Looks good.

Comment 4

[Mark Smith [:mcs]]

Thanks for the patch.  I do not know of anyone who matches port name as well, but I am not an expert on certificate matching.  Have you asked one of the NSS developers to be sure?

Comment 5

[Ulf Weltman]

It strikes me that this change would be incompatible with IPv6 since colons separate the 8 fields, like fe80:0:0:0:230:6eff:fe4b:703.  I'm pretty sure a server cert with a subject like CN=fe80::230:6eff:fe4b:703,O=Example,C=US is possible.  Or would that be CN=[fe80::230:6eff:fe4b:703],O=Example,C=US maybe?  Or subjectAltName of [fe80::230:6eff:fe4b:703]:389 possibly, I didn't have a chance to check with the NSS guys yet.

Some more logic is needed anyway, back to the drawing board...

Comment 6

[Rich Megginson]

Do we need to worry about wildcard hostnames?  e.g. what if the subject DN contains cn=*.mozilla.org and the peer hostname is www.mozilla.org?

Comment 7

[Mark Smith [:mcs]]

(In reply to comment #5)
> It strikes me that this change would be incompatible with IPv6 since colons
> separate the 8 fields, like fe80:0:0:0:230:6eff:fe4b:703.  I'm pretty sure a
> server cert with a subject like CN=fe80::230:6eff:fe4b:703,O=Example,C=US is
> possible.  Or would that be CN=[fe80::230:6eff:fe4b:703],O=Example,C=US maybe? 
> Or subjectAltName of [fe80::230:6eff:fe4b:703]:389 possibly, I didn't have a
> chance to check with the NSS guys yet.

I suspect your logic is OK.  I am pretty sure IPv6 addresses must be enclosed in [].  See libldap/open.c:ldap_x_hostlist_next().


(In reply to comment #6)
> Do we need to worry about wildcard hostnames?  e.g. what if the subject DN
> contains cn=*.mozilla.org and the peer hostname is www.mozilla.org?

Wildcards are handled by CERT_VerifyCertName().  Hopefully that is not our problem.

Comment 8

[Rich Megginson]

Ulf, did you ever find out how this would work with IPv6 addresses in the CN?

Comment 9

[Rich Megginson]

ping