[Date Prev][Date Next]
JLDAP, TLS, and DNS
I wanted to follow up on a subject that came up on the software list
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
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.