Shib IdP - Metadata Download and Java 1.7.0_85

[Takeshi NISHIMURA]

Hi Brent,

Thank you for digging deeper.
Preserving mechanism of originalHostName via sun.misc.JavaNetAccess, added in [1], is totally broken. Because putting hostName into InetAddressHolder by constructor or init() never happen.

Only one (or to be more precise 3) successful path is to set this.host directly in [2]. This can be achieved by constructor with argument "String host".

That is,

> SSLSocket sslSocket = (SSLSocket)sslContext.getSocketFactory().createSocket("metadata.gakunin.nii.ac.jp", 443);

will succeed, but

> SSLSocket sslSocket = (SSLSocket)sslContext.getSocketFactory().createSocket(InetAddress.getByName("metadata.gakunin.nii.ac.jp"), 443);

will fail.

Takeshi

[1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/a25640f4e518
[2] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/3eb4e20b34cb/src/share/classes/sun/security/ssl/SSLSocketImpl.java

> On 7/23/15 2:20 AM, Brent Putman wrote:
> > 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.
> 
> Just following up on this:  Depending on how the JSSE SSLSocketFactory
> is called, it doesn't *always* happen.  (To me means more evidence that
> this is a bug).  In v2 our HttpClient factory has:
> 
>           
>         if (timeout == 0) {
>             // Here 'host' is just a String
>             Socket socket = socketfactory.createSocket(host, port,
> localHost, localPort);
>             verifyHostname(socket);
>             return socket;
>         } else {
>             Socket socket = socketfactory.createSocket();
>             SocketAddress localaddr = new InetSocketAddress(localHost,
> localPort);
>             // Here host (String) + port (int) converted to
> InetSocketAddress
>             SocketAddress remoteaddr = new InetSocketAddress(host, port);
>             socket.bind(localaddr);
>             socket.connect(remoteaddr, timeout);
>             verifyHostname(socket);
>             return socket;
>         }
> 
> 
> If you fall into the first block, getPeerHost() behaves as always,
> returning the hostname, and everything works as it should.  If you do
> have a non-zero timeout (which you always want), getPeerHost() returns
> the IP address.
> 
> So in terms of the broader effect of this, it's complicated.  It's
> going to depend on how the caller is using SSLSocketFactory.  I did see
> something about the original IP addr quirk depending on exactly how the
> InetAddress instances passed to the factory are created. [1]  The above
> behavior is probably related.
> 
> An SSLSocketFactory has basically 6 different overloaded
> createSocket(...) methods, plus the above use of Socket#connect(...),
> etc.  We just happen to be unlucky bastards using the bad one and/or in
> the bad way.
> 
> So vt-ldap/ldaptive may not be affected here, it depends on exactly how
> the SSLSocketFactory is being used.
> 
> 
> [1]
> 
> http://mail.openjdk.java.net/pipermail/security-dev/2014-November/011377.html