<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 7/23/15 12:26 AM, Takeshi NISHIMURA
wrote:<br>
</div>
<blockquote cite="mid:55B06CE4.6040406@nii.ac.jp" type="cite">I
think you should not rely on sslSession.getPeerHost() returning
original hostnames.</blockquote>
<br>
Well, hindsight is 20/20. But I think I modeled that code on
something "official" at the time, although I don't remember what.
And I'd note that that's exactly what they do in their own
X509TrustMangerImpl [1] for the new endpoint identification stuff
that I earlier mentioned: <br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<tt>if (identityAlg != null && identityAlg.length() != 0) {</tt><tt><br>
</tt><tt> String hostname = session.getPeerHost();</tt><tt><br>
</tt><tt> checkIdentity(hostname, chain[0], identityAlg);</tt><tt><br>
</tt><tt>}</tt><br>
<br>
So I thought this was the right way. I do know however that the
HttpClient v4 socket factories don't do that, they use the hostname
originally passed.<br>
<br>
<br>
<blockquote cite="mid:55B06CE4.6040406@nii.ac.jp" type="cite"> It
seems like returning IP addresses on the latest versions of JDK.
<br>
<br>
</blockquote>
<br>
I really did not believe that they could do something so egregious.
So I had to test it (on "old" vs. "new" Java 8, since I don't have
and can't currently get the last Java 7 with this change). And in
fact that is exactly what they have done. By default
SSLSession#getPeerHost() now returns the IP address, at least in
conjunction with how the socket factory is used in HttpClient v3. I
think I read something earlier this evening that said the old quirky
IP address behavior you experienced was only tripped if you used the
socket factory methods that take an InetAddress as opposed to a
String, or something. So that's probably what the HttpClient is
doing. <br>
<br>
I'm flabbergasted. I don't know if they intended this change or
not. It's certainly not what they were talking about in the release
note, it's something different. However, it's almost certainly
related to the same set of changes because: Setting
'jdk.tls.trustNameService=true' causes getPeerHost() to return the
hostname rather than the IP address. <br>
<br>
So that is exactly the problem Wolfgang reported. So mystery solved,
at least.<br>
<br>
Setting jdk.tls.trustNameService=true' would be the workaround for
the short term for v2, but looks like we'll have to issue a v2 patch
update for this. I don't think v3 would be affected, but we'll
confirm.<br>
<br>
As an aside, I don't see how their own X509TrustManagerImpl endpoint
identification stuff (above) can work with this change, which is
partly why I think it might have been an unintentional side effect
of other changes. (Unless they do something even more egregious,
like resolve the hostname(s) from the cert to IP addresses and match
against those. Surely they can't be that daft...).<br>
<br>
<br>
<blockquote cite="mid:55B06CE4.6040406@nii.ac.jp" type="cite">This
issue may be resolved if you pass the original hostname to
verifyHostname() in [1].
<br>
<br>
</blockquote>
<br>
Yes, I'll confirm, but pretty sure that's what we should do.<br>
<br>
Thanks for looking into this.<br>
<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="http://www.docjar.com/html/api/sun/security/ssl/X509TrustManagerImpl.java.html">http://www.docjar.com/html/api/sun/security/ssl/X509TrustManagerImpl.java.html</a><br>
<br>
</body>
</html>