139467 - LDAP over SSL does not canonify CNAMES before validating a server certificate

Status: VERIFIED INVALID

(MailNews Core :: LDAP Integration, defect)

Description

[Vladimír Solnický]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.9+) Gecko/20020422
BuildID:    2002042209

We use a following set-up:

We have a server called web (it has a DNS A record).
We have a DNS alias `ldap' that is aliased to web (using a DNS CNAME record).

We set up netscape 4.x and mozilla to have a direcory server on address ldap.

Server web has a server certificate for SSL services with CN=web.

Now if I want to use LDAP over SSL, netscape 4.x recognizes that ldap is alias
to web and works correctly. But mozilla warns me that server certificates CN
differs from server names ldap.

Reproducible: Always
Steps to Reproduce:
1. Set up a directory server
2. set is as ssl ldap
3. put a dns CNAME alias to your DNS
4. put the alias name to your server as an ldap server to mozillas preferencies
5. create a server certificate wih CN´canonical DNS name
6. sut ssl over ůdap on your server
7. try autocplete or addressbook search.



Actual Results:  You are asked to agree that certificate CN differs from server
name.

Expected Results:  No dialog windows should occur, mozilla should find itself
that a pref name is a DNS alias and find a canonical dns name.

Autocomplete does not work well after the dialog window but I cannot say if it
is because of this or for some other reason (a different bug).

Comment 1

[yulian chang]

Reassign to Dan

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

Nelson, should this be considered a bug in Mozilla, or was 4.x insufficiently
strict?

Comment 3

[Vladimír Solnický]

May I comment it although I was not ask to answer? I think the anwer depends on
the concept of certificates. If they are used on per server bases than my
submission is really a bug. The advantages of this concept are that you can have
two servers providing the same service and if certificates of both are signed by
a regognized authority you can switch the server for users only by changing a
CNAME. On the other way per service certificates (no CNAME canonification) would
require copying of a certificate to the second server if you need to switch them
(or creation of a new certificate). I think Per service certificates may allow a
better granularity but because CN= contains only DNS FQDN and no service (port)
identification, the way of understanding them as per server certificates seems
to be more usable to me.  But all this is only IMHO.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Dan, It sounds like 4.x was insufficiently strict.  

SSL is designed and intended to provide assurances to the client that it 
has reached the server it really wanted, and not some other server, 
without trusting (being vulnerable to) DNS or any other name->address
service.  To achieve that goal, it is necessary to compare the cert
received from the server with the name/identity of the server that the
user/client specified.  The question to be answered is: is this the 
server that the user asked for, NOT is this the server that DNS said to 
use instead of the one the user asked for.  

So, if the user asks for a server named "ldap", and the user doesn't 
indicate that a server named "web" is an acceptable alternative to 
"ldap", then it is wrong, from a security perspective, to substitute
a DNS canonical name for the name the user requested.  Doing so makes
the SSL client subject to various attacks based on rogue name servers.

aside:
The SSL protocol does not specify how the client determines whether the
cert received from the server is the one desired by the client, or not.
The scheme used by the https protocol, where the cert's Common Name is
expected to contain a regular expression that must match the host name
that was specified in the URL, is a convention of https, not of SSL.  
It's up to the higher level protocol (that runs over SSL, e.g. ldap, 
imap, nntp, http) to specify how it decides whether a received server 
cert is the right one or not.

Another protocol (e.g. ldaps) could legitimately allow the client to 
specify a list of acceptable cert Common Names, and check the incoming
cert against all the names in that list.  Or another protocol could
decide that in addition to inspecting the Common Name in the cert's Subject 
Name, it would also inspect the cert for any "Alternate Subject Name" 
extensions and search them for a match.  A cert could then list the names
of the servers that it serves as alternate names.  A protocol could also 
decide to inspect a cert for some value signifying that this cert is valid 
for use with that protocol.  

libSSL calls an application-provided call back function to actually 
validate the server cert.  libSSL also provides a function that the 
application can register for this purpose, so the application doesn't
have to write its own function.  That so-called "default" callback 
function validates the cert chain, then uses the server cert's CN as a
regular expression and determines if the client-supplied host name
matches that expression.  This is the scheme used by https.  Most 
clients of libSSL use that callback, but they're free to write their own.  

And don't forget that CN's of the form domain.TLD match *.domain.TLD.
That is, a cert with a CN of "netscape.com" would match any server 
in the netscape.com domain, e.g. foo.netscape.com.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

Thanks for the explanation, Nelson.  I just did a little RFC reading, and
section 3.6 of RFC 2830 supports your interpretation:

- The client MUST use the server hostname it used to open the LDAP
  connection as the value to compare against the server name as
  expressed in the server's certificate.  The client MUST NOT use the
  server's canonical DNS name or any other derived form of name.

Marking invalid.

Comment 6

[yulian chang]

Verified.