Plans to upgrade HttpClient to latest ?

[Brent Putman]

On 9/3/15 4:55 PM, Cantor, Scott wrote:
> On 9/3/15, 3:59 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:
>
>> Also IIRC the big thing I saw between 4.3.x and 4.4.x was that business with the public suffix stuff they introduced.  Wanted to really get a handle on that before updating.  We might want to figure out how to turn all that off, if possible:
> At least on the hostname verifier side, aren't we using our own exclusively now? Or am I still screwed up understanding all this?

In v3, no we don't use our own generally speaking right now.  The
HttpClientBuilder does this:

        if (getTLSSocketFactory() != null) {
            builder.setSSLSocketFactory(getTLSSocketFactory());
        } else if (connectionDisregardTLSCertificate) {
           
builder.setSSLSocketFactory(HttpClientSupport.buildNoTrustSSLConnectionSocketFactory());
        } else {
           
builder.setSSLSocketFactory(HttpClientSupport.buildStrictSSLConnectionSocketFactory());
        }


The first case there could be any TLS factory + verifier.  But for the
other 2 we use HC 4.x classes.  For the 3rd default case there we are
using their STRICT one:

org.apache.http.conn.ssl.SSLConnectionSocketFactory.STRICT_HOSTNAME_VERIFIER


The stuff in HC v4.x doesn't suck (as far as we know....) like the HC
3.x stuff did.  So no reason to roll our own hostname verifiers.  So
that's why I really wanted to look at the public suffix stuff. IIRC by
default it tries to download the list automatically and cache it and
other ugly stuff.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150903/f8126f05/attachment-0001.html>