Shib IdP - Metadata Download and Java 1.7.0_85

[Brent Putman]

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


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