[Date Prev][Date Next] [Chronological] [Thread] [Top]


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