Shib IdP - Metadata Download and Java 1.7.0_85

[Brent Putman]

On 7/22/15 10:07 AM, Cantor, Scott wrote:
> On 7/22/15, 8:14 AM, "users on behalf of Wolfgang Pempe" <users-bounces at shibboleth.net on behalf of pempe at dfn.de> wrote:
>
>
>
>> This behaviour seems to go back to a security fix which is described at
>> http://www.oracle.com/technetwork/java/javase/7u85-relnotes-2587591.html
>> (end of the page).
> 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.

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.

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.

*******************

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]:

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

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

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

Soooo... My interpretation of the wording of the recent change:

" With this fix, JSSE endpoint identification does not perform reverse
name lookup for IP addresses by default in JDK."

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

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


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

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.

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. 



>
>> Even though the workaround is obvious (-Djdk.tls.trustNameService=true),
> If that fixes this, then I'm totally lost.

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.
 



[1] https://issues.shibboleth.net/jira/browse/JOWS-39
[2]
http://docs.oracle.com/javase/7/docs/technotes/guides/security/enhancements-7.html
[3]
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#jssenames
[4]
https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#X509ExtendedTrustManager
[5]
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/20150722/4493c994/attachment.html>