Apache Httpclient 4.4: HostnameVerifier Übergang von 4.3.x

Question

Httpclient 4.3 hatte drei statische Variablen in org.apache.http.conn.ssl.SSLConnectionSocketFactory:

1. STRICT_HOSTNAME_VERIFIER
2. BROWSER_COMPATIBLE_HOSTNAME_VERIFIER
3. ALLOW_ALL__HOSTNAME_VERIFIER

Wenn die Abhängigkeit auf Version Upgrade 4.4 von HttpClient, sehe ich, dass alle oben genannten Konstanten veraltet sind. Der Depretion-Hinweis in JavaDoc, der für die Verwendung von org.apache.http.conn.ssl.DefaultHostnameVerifier verwendet wird. Wenn ich die Dokumente lese, gehe ich davon aus, dass DefaultHostnameVerifier ein direkter Ersatz für STRICT_HOSTNAME_VERIFIER ist. Auch die ALLOW_ALL__HOSTNAME_VERIFIER ist einfach zu implementieren:

package org.wiztools.restclient.http; 

import javax.net.ssl.HostnameVerifier; 
import javax.net.ssl.SSLSession; 

/** 
* 
* @author subwiz 
*/ 
public class AllowAllHostnameVerifier implements HostnameVerifier { 

    @Override 
    public boolean verify(String string, SSLSession ssls) { 
     return true; 
    } 

} 

Es gibt einen feinen Unterschied zwischen den STRICT_HOSTNAME_VERIFIER und BROWSER_COMPATIBLE_HOSTNAME_VERIFIER (von JavaDoc):

Der einzige Unterschied zwischen BROWSER_COMPATIBLE und UNABHäNGIGER ist, dass ein Platzhalter (wie "* .foo.com") mit BROWSER_COMPATIBLE passt auf alle Subdomains, einschließlich "abfoo.com".

Haben wir eine BROWSER_COMPATIBLE Hostname Verifier für httpclient 4.4?

Answer 1

BrowserCompatHostnameVerifier war im Wesentlichen IE 5/6 kompatible Implementierung. Ich bin mir nicht sicher, ob es tatsächlich mit moderneren Browser-Anwendungen kompatibel ist. BrowserCompatHostnameVerifier hätte eigentlich nie existieren sollen und sollte nicht mehr verwendet werden.

Answer 2

Tatsächlich gibt die Javadoc von AllowAllHostnameVerifier einen direkten Ersatz für ALLOW_ALL__HOSTNAME_VERIFIER, die NoopHostnameVerifier ist.

Answer 3

Sie benötigen keine neue Implementierungsklasse für AllowAllHostnameVerifier und brauchen keine weitere Implementierung für BrowserCompatHostnameVerifier, einfach eine Instanz auf die neue DefaultHostnameVerifier passieren,

SSLConnectionSocketFactory sslsf = new SSLConnectionSocketFactory(sslcontext, new DefaultHostnameVerifier()); 

diese Klasse die neccesary Verifikationsmethoden für beide mit die folgenden Methodensignaturen

public final boolean verify(String host, SSLSession session) (Override) 

und

public final void verify(String host, X509Certificate cert) throws SSLException 

in der zweiten Methode werden die Httpcomponents eine Überprüfung zur Anpassung Subdomains

public final void verify(String host, X509Certificate cert) throws SSLException { 
    boolean ipv4 = InetAddressUtils.isIPv4Address(host); 
    boolean ipv6 = InetAddressUtils.isIPv6Address(host); 
    int subjectType = ((ipv4) || (ipv6)) ? 7 : 2; 
    List subjectAlts = extractSubjectAlts(cert, subjectType); 
    if ((subjectAlts != null) && (!(subjectAlts.isEmpty()))) { 
     if (ipv4) 
      matchIPAddress(host, subjectAlts); 
     else if (ipv6) 
      matchIPv6Address(host, subjectAlts); 
     else { 
      matchDNSName(host, subjectAlts, this.publicSuffixMatcher); 
     } 
    } else { 
     X500Principal subjectPrincipal = cert.getSubjectX500Principal(); 
     String cn = extractCN(subjectPrincipal.getName("RFC2253")); 
     if (cn == null) { 
      throw new SSLException("Certificate subject for <" + host + "> doesn't contain " + "a common name and does not have alternative names"); 
     } 

     matchCN(host, cn, this.publicSuffixMatcher); 
    } 
} 

einen Blick auf den Quellcode nehmen, um weitere Klärung

org.apache.http.conn.ssl.DefaultHostnameVerifier

Hoffnung, das hilft.

Answer 4

ich das alles lesen und für mich nichts gearbeitet, hier ist was meinen Tag gerettet: https://stackoverflow.com/a/36507502/3090309

Ich war mit:

compile group: 'org.apache.httpcomponents', name: 'httpclient', version: '4.5.2'