JLDAP, TLS, and DNS

[Jon Roberts <postmaster@jonanddeb.net>]

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