Re: JLDAP, TLS, and DNS

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

I'm not familiar with Java's security services, so I'll answer
using more general terms....

A client needs to perform a number of different checks to
ensure security.

In regards to server certificates, there are checks in two
areas.  1) checks to ensure the certificate is valid
(issued by a known CA, not expired, not revoked, etc.)
and 2) check to ensure that valid certificate is being
used properly.

The latter check, commonly done by the program not the TLS
library (at least when using C TLS SDKs), ensures that someone
with a valid certificate doesn't use that certificate to mount an
attack.  A reason why this check is not done in the TLS library
is that the particulars of the check may be application protocol
specific.  For instance, draft-ietf-ldapbis-authmeth details
the LDAP-specifics checking.

If the user is establishing a connection to "host.example.com"
but the valid certificate is not for "host.example.com", the
connection should be rejected.

What the specs say is that in checking that when doing this
check, one should not use alias names (including IP addresses)
unless the transformation between the user-specified name
and the alias is trusted.  For instance, 1) DNSsec says so,
2) the user's administrator says so (for instance, the
alias is provided in the local /etc/hosts, and hence
considered trusted), or the user says so (the program
asks the user "Certificate is for FOO NOT BAR.  Okay?").

DNS transformations, including host-to-IPaddress (for
ipAddress subjects), IPaddress-to-host (for CN or dNSName
looks) and even host-to-IPaddress-to-host lookups, as DNS
is easily spoofed.

Kurt

At 02:44 PM 3/2/2006, Jon Roberts wrote:
>I wanted to follow up on a subject that came up on the software list last month...
>
>Jon Roberts wrote:
>> Kurt D. Zeilenga wrote:
>>>>> Quanah Gibson-Mount wrote:
>>>>>> You have to use the name in your search that matches the name in
>>>>>> the certificate for TLS to work.
>>>>>
>>>>> In JLDAP clients I can connect to a remote ldaps server by using
>>>>> the ip address as hostname, even though I obviously did not use
>>>>> the ip as the name in the certificate.
>>>>
>>>> I'm guessing that JLDAP translates the IP address to the FQDN.
>>>
>>> Which is counter to both general and LDAP-specific
>>> TLS certificate verification rules.  One shouldn't
>>> trust DNS.  Sounds like a JLDAP bug to me.
>>
>> I'll have to continue investigating this later, but it appears it's
>> actually the standard Java JSSE SSL socket factory that's doing this
>> lookup. However, in JLDAP's LDAPJSSEStartTLSFactory the socket
>> creation involves an explicit call to getInetAddress().getHostName().
>> That may be aping what I'll find in the source for
>> javax.net.ssl.SSLSocketFactory.
>
>First, I note JLDAP simply uses standard Java SSL sockets. In other words, this would be an issue with Java rather than JLDAP specifically.
>
>Second, although I understand DNS spoofing is a concern, wouldn't the statement that "DNS cannot be trusted" make this whole process problematic... I mean the client has to resolve the host to find it even before handshake, right? Further, the API documentation for the java.net.InetAddress class involved in hostname resolution involved states:
>
>"The InetAddress class has a cache to store successful as well as unsuccessful host name resolutions. The positive caching is there to guard against DNS spoofing attacks; while the negative caching is used to improve performance. By default, the result of positive host name resolutions are cached forever..."
>
>As for this...
>
>Francis Swasey wrote:
>>> I'm guessing that JLDAP translates the IP address to the FQDN.
>>
>> Either that or JLDAP is not verifying the name on the cert matches the
>> name requested at all -- only that the cert is signed by a root CA the
>> client knows about.
>
>I would have to dig in the javax.net.ssl source files (which I don't have handy) to say for sure, but this might be the case. My CA cert does need to be in a trusted store for any handshake to work. Again though, if it's a bug I think it's really a Java bug.
>
>Jon Roberts
>www.mentata.com