SSL HostnameVerifier

  • Follow


Was getting "hostname wrong" when connecting via HttpsURLConnection.
Setup my own HostnameVerifier, returned true, and problem went away.

However, exactly what problem did I solve, and did I introduce a
security risk? When the substitute HostnameVerifier was called, first
argument "String urlHostName" was identical to second argument
"SSLSession session.getPeerHost()", i.e., the IP address of the server
from whom the certificate was obtained. What mismatch triggered the
call to the substitute HostnameVerifier?

Thanks.

0
Reply FrankNatoli 11/18/2005 3:37:11 PM

> did I introduce a security risk?

Yes. You effectively disabled authentication.

The hostname contained in the cert must match the hostname in the URL.

0
Reply Mr 11/19/2005 9:20:42 PM


Mr. Skeptic wrote:
> > did I introduce a security risk?
>
> Yes. You effectively disabled authentication.
>
> The hostname contained in the cert must match the hostname in the URL.

Right. But what information available to HostnameVerifier should be
used to test the match? In my particular case, the urlHostname, i.e.,
the first argument to HostnameVerifier, is the IP address of the Sun
ONE server I am connecting to. And the second argument to
HostnameVerifier, calling getPeerHost(), returns that exact same data,
i.e., the IP address of the Sun ONE server that I am connecting to. If
they are identical, why was HostnameVerifier called in the first place?

I believe the problem is that the "common name" of the certificate is
NOT the same as the IP address of the Sun ONE server. If I call
getPeerPrincipal and then getName, I get all the certificate data,
including the "common name".

I ask again, if HostnameVerifier urlHostName is identical to
HostnameVerifier session.getPeerHost(), why is HostnameVerifier called
in the first place?

Thanks.

0
Reply FrankNatoli 11/20/2005 12:46:31 AM

I'm not really sure where the heck getPeerHost() gets it's value from,
but the JSSE reference and javadocs make it fairly clear that its not
from the certificate. So getPeerHost() is worthless.

> I believe the problem is that the "common name" of the certificate is
> NOT the same as the IP address of the Sun ONE server. If I call
> getPeerPrincipal and then getName, I get all the certificate data,
> including the "common name".

The comparison is even simpler than the IP address. The common name in
the certificate must match the the hostname you gave in the URL
exactly. That means if your URL is https://www.mydomain.com/, the
common name must be www.mydomain.com. If the URL is
https://192.168.1.131/, then the common name must be 192.168.1.131.
This is necessary because DNS is not secure and a man-in-the-middle can
"easily" give you a valid certificate with a different hostname, for
various values of "easily".

It appears the best way to extract the CN is as you mentioned, by
called SSLSession.getPeerPrincipal ().getName() and then I guess using
some of the string extraction classes. I haven't tried it, but it may
be better to feed the output of getName() into the constructor for
LdapName, and then using its methods to extract the CN.

0
Reply Mr 11/22/2005 11:27:27 PM

3 Replies
287 Views

(page loaded in 0.138 seconds)

Similiar Articles:











7/25/2012 2:44:00 AM


Reply: