Shib IdP - Metadata Download and Java 1.7.0_85

[Brent Putman]

On 7/23/15 12:26 AM, Takeshi NISHIMURA wrote:
> I think you should not rely on sslSession.getPeerHost() returning
> original hostnames.

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:

if (identityAlg != null && identityAlg.length() != 0) {
    String hostname = session.getPeerHost();
    checkIdentity(hostname, chain[0], identityAlg);
}

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.


> It seems like returning IP addresses on the latest versions of JDK.
>

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.

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.

So that is exactly the problem Wolfgang reported. So mystery solved, at
least.

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.

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...).


> This issue may be resolved if you pass the original hostname to
> verifyHostname() in [1].
>

Yes, I'll confirm, but pretty sure that's what we should do.

Thanks for looking into this.


[1]
http://www.docjar.com/html/api/sun/security/ssl/X509TrustManagerImpl.java.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150723/2543b6e6/attachment.html>