<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/22/15 10:07 AM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:6D9E47D1-550F-4AC9-82EB-0E9CC2039440@osu.edu"
type="cite">
<pre wrap="">On 7/22/15, 8:14 AM, "users on behalf of Wolfgang Pempe" <a class="moz-txt-link-rfc2396E" href="mailto:users-bounces@shibboleth.netonbehalfofpempe@dfn.de"><users-bounces@shibboleth.net on behalf of pempe@dfn.de></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">This behaviour seems to go back to a security fix which is described at
<a class="moz-txt-link-freetext" href="http://www.oracle.com/technetwork/java/javase/7u85-relnotes-2587591.html">http://www.oracle.com/technetwork/java/javase/7u85-relnotes-2587591.html</a>
(end of the page).
</pre>
</blockquote>
<pre wrap="">
I thought that bug had to do with an odd quirk that was allowing Java to validate connections to systems based on IP address by looking up the name and then matching that the certificate. Unless your connection URL included an IP address, that wouldn't apply, so one of us is confused.</pre>
</blockquote>
<br>
That's what I thought too. The OP's log seems to be showing the
complete opposite case (URL w/ FQDN, failing validation against the
IP address), and I'm not immediately seeing how they are connected.<br>
<br>
For the original issue in v2 where someone noticed IP address
metadata URLs mysteriously passing validation [1], I'm still not
100% sure why it was. Only thing I can think of is: we evaluate
the cert against what is returned from SSLSession#getPeerHost(). If
*that* is the place (or one of the places) where they were doing the
reverse lookup, then that makes sense. If not, then I still don't
know how it was working there.<br>
<br>
*******************<br>
<br>
But on the changes in 7u85: Researching this made me look into
something that I had recently seen while poking around in JSSE.
This is new to me but: Apparently starting in Java 7, they
introduced the capability for name checking to be done down in the
TLS layer itself, calling it "endpoint identification" [2]:<br>
<br>
"Endpoint verification: An endpoint identification algorithm can be
specified to verify that a remote computer's host address matches
its supplied certificate. Although this type of verification was
previously performed for the HTTPS protocol (see HttpsURLConnection
and HostnameVerifier), such verification can now be optionally
performed at the TLS level."<br>
<br>
I believe it's optional and not active by default. You enable on
the SSLContext and/or SSLSocket. (Don't know yet whether HttpClient
factories or anything else we use is actually enabling this, but I
doubt it). The default supported algorithms are "HTTPS" and "LDAPS"
[3].<br>
<br>
It's implemented (at least) in Oracle's X509ExtendedTrustManager [4]
which I think you get by default with an SSLContext unless you
otherwise specify one. I confirmed the behavior by looking at
OpenJDK source code [5].<br>
<br>
Soooo... My interpretation of the wording of the recent change:<br>
<br>
"
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
With this fix, JSSE endpoint identification does not perform reverse
name lookup for IP addresses by default in JDK."<br>
<br>
is that they are changing what this newer endpoint identification
stuff does. Although maybe they don't mean it quite that literally.
Maybe it also extends to their legacy JDK HostnameVerifier impls
(which we don't use).<br>
<br>
So I am also not sure yet whether, where or how this change even
affects our code (unless as mentioned it also affects the effective
value returned from SSLSession#getPeerHost()).<br>
<br>
<br>
<blockquote cite="mid:6D9E47D1-550F-4AC9-82EB-0E9CC2039440@osu.edu"
type="cite">
<pre wrap="">
Either way, as far as I knew, we're doing our own hostname checking anyway, unless you're running an older version (and even then I thought it was being done by another library, not Java's verifier, but I could be wrong on that).
</pre>
</blockquote>
<br>
That's correct. I'm not seeing how this change affects our hostname
verification process in either v2 or v3, given that we aren't using
AFAIK any JDK code for that, nor does not-yet-commons-ssl nor
HttpClient v4 (modulo SSLSession#getPeerHost() in v2. Not applicable
in v3). Based on the log, the OP seems to be on v2.<br>
<br>
Basically if this new endpoint identification functionality *were*
running, it would be a separate check from ours, I think. So it's
possible that something might pass one check and fail the other, I
guess. <br>
<br>
<br>
<br>
<blockquote cite="mid:6D9E47D1-550F-4AC9-82EB-0E9CC2039440@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Even though the workaround is obvious (-Djdk.tls.trustNameService=true),
</pre>
</blockquote>
<pre wrap="">If that fixes this, then I'm totally lost.
</pre>
</blockquote>
<br>
Yeah, I wasn't clear whether this was confirmed to fix it, or just
assumed. If it does, then I also do not understand why. Possibly
the scope and nature of the change is bigger than what they have
described.<br>
<br>
<br>
<br>
<br>
[1] <a class="moz-txt-link-freetext" href="https://issues.shibboleth.net/jira/browse/JOWS-39">https://issues.shibboleth.net/jira/browse/JOWS-39</a><br>
[2]
<a class="moz-txt-link-freetext" href="http://docs.oracle.com/javase/7/docs/technotes/guides/security/enhancements-7.html">http://docs.oracle.com/javase/7/docs/technotes/guides/security/enhancements-7.html</a><br>
[3]
<a class="moz-txt-link-freetext" href="http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#jssenames">http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#jssenames</a><br>
[4]
<a class="moz-txt-link-freetext" href="https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#X509ExtendedTrustManager">https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#X509ExtendedTrustManager</a><br>
[5]
<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>
<br>
</body>
</html>