<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/23/15 2:20 AM, Brent Putman wrote:<br>
    </div>
    <blockquote cite="mid:55B08792.8080208@georgetown.edu" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      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.<br>
    </blockquote>
    <br>
    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:<br>
    <br>
               <br>
    <tt>        if (timeout == 0) {</tt><tt><br>
                  // Here 'host' is just a String<br>
    </tt><tt>            </tt><tt>Socket socket =
      socketfactory.createSocket(host, port, localHost, localPort);</tt><tt><br>
    </tt><tt>            verifyHostname(socket);</tt><tt><br>
    </tt><tt>            return socket;</tt><tt><br>
    </tt><tt>        } else {</tt><tt><br>
    </tt><tt>            </tt><tt>Socket socket =
      socketfactory.createSocket();</tt><tt><br>
    </tt><tt>            SocketAddress localaddr = new
      InetSocketAddress(localHost, localPort);</tt><tt><br>
                  // Here host (String) + port (int) converted to
      InetSocketAddress<br>
    </tt><tt>            SocketAddress remoteaddr = new
      InetSocketAddress(host, port);</tt><tt><br>
    </tt><tt>            socket.bind(localaddr);</tt><tt><br>
    </tt><tt>            socket.connect(remoteaddr, timeout);</tt><tt><br>
    </tt><tt>            verifyHostname(socket);</tt><tt><br>
    </tt><tt>            return socket;</tt><tt><br>
    </tt><tt>        }</tt><br>
    <br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    So vt-ldap/ldaptive may not be affected here, it depends on exactly
    how the SSLSocketFactory is being used.<br>
    <br>
    <br>
    [1]
<a class="moz-txt-link-freetext" href="http://mail.openjdk.java.net/pipermail/security-dev/2014-November/011377.html">http://mail.openjdk.java.net/pipermail/security-dev/2014-November/011377.html</a><br>
    <br>
    <br>
  </body>
</html>