ldapssl_AuthCertificate fails on hostnames with appended port

NEW
Assigned to

Status

Directory
LDAP C SDK
12 years ago
11 years ago

People

(Reporter: Ulf Weltman, Assigned: mcs)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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

12 years ago
> 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.
(Reporter)

Comment 2

12 years ago
Created attachment 236098 [details] [diff] [review]
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

12 years ago
Looks good.
(Assignee)

Comment 4

12 years ago
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?
(Reporter)

Comment 5

12 years ago
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

12 years ago
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?
(Assignee)

Comment 7

12 years ago
(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

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

Comment 9

11 years ago
ping
You need to log in before you can comment on or make changes to this bug.