当前位置: 首页 > 面试题库 >

所有信任的HostnameVerifier都会导致HttpURLConnection发生SSL错误

融渊
2023-03-14
问题内容

我正在使用HttpURLConnection连接到SSL网站。有时这些会使用自签名证书/否则会表现不佳的SSL,因此我有一种可以访问这些证书的方式。我在网上许多地方都使用推荐的典型代码:

        // Create a trust manager that does not validate certificate chains
        TrustManager[] trustAllCerts = new TrustManager[]{
            new X509TrustManager() {
                public java.security.cert.X509Certificate[] getAcceptedIssuers() {
                    return null;
                }
                public void checkClientTrusted(java.security.cert.X509Certificate[] certs, String authType) {}
                public void checkServerTrusted(java.security.cert.X509Certificate[] certs, String authType) {}
            }
        };

        // Install the all-trusting trust manager
        SSLContext sc = SSLContext.getInstance("SSL");
        sc.init(null, trustAllCerts, new java.security.SecureRandom());
        HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());


        // Don't verify host names
        HostnameVerifier hv = new HostnameVerifier() {
            public boolean verify(String urlHostName, SSLSession session) {
                return true;
            }
        };
        HttpsURLConnection.setDefaultHostnameVerifier(hv);

问题是,这会导致许多站点出现SSL错误,例如:

https://cong-shalom.org/ 原因:

javax.net.ssl.SSLException: Received fatal alert: internal_error

启用javax.net.debug = all时的输出:

    [java] Thread-8, READ: TLSv1.2 Alert, length = 2
    [java] Thread-8, RECV TLSv1.2 ALERT:  fatal, internal_error
    [java] Thread-8, called closeSocket()

https://www.territrespicio.com 原因:

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

启用javax.net.debug = all时的输出:

         [java] Thread-13, READ: TLSv1.2 Alert, length = 2
         [java] Thread-13, RECV TLSv1.2 ALERT:  fatal, handshake_failure
         [java] Thread-13, called closeSocket()

这些问题均与TrustManager无关,注释掉HostnameVerifier部分始终可使连接正常工作。

笔记:

  • Java版本:1.8.0_111
  • 不幸的是,我无法切换到Apache httpclient(围绕HttpURLConnection构建了很多代码)

问题答案:

您的问题是由于JDK
自定义HostnameVerifier中的错误导致禁用了SNI扩展。您还可以在此线程中看到,扩展服务器名(SNI扩展)不是随jdk1.8.0发送的,而是随jdk1.7.0发送的

从jdk 8u66开始,使用自定义HostnameVerifier功能不会Extended server_name在握手期间发送扩展名。此错误将在版本8u152中修复。

这是https://www.territrespicio.com您的代码调用握手的痕迹

*** ClientHello, TLSv1.2
RandomCookie:  GMT: 1467981635 bytes = { 253, 197, 8, 192, 170, 180, 230, 6, 212, 233, 219, 201, 182, 39, 204, 176, 49, 215, 43, 41, 112, 204, 188, 29, 115, 235, 191, 74 }
Session ID:  {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA256withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA
***
main, WRITE: TLSv1.2 Handshake, length = 233
main, READ: TLSv1.2 Alert, length = 2
main, RECV TLSv1.2 ALERT:  fatal, handshake_failure
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
Exception in thread "main" javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

这是删除(工作)的痕迹

HttpsURLConnection.setDefaultHostnameVerifier(hv);
*** ClientHello, TLSv1.2
RandomCookie:  GMT: 1467981305 bytes = { 187, 36, 131, 239, 148, 148, 198, 107, 89, 74, 67, 33, 127, 76, 24, 17, 108, 254, 79, 104, 242, 239, 51, 36, 180, 244, 181, 45 }
Session ID:  {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA256withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA
Extension server_name, server_name: [type=host_name (0), value=www.territrespicio.com]
***
main, WRITE: TLSv1.2 Handshake, length = 264
main, READ: TLSv1.2 Handshake, length = 89
*** ServerHello, TLSv1.2
RandomCookie:  GMT: -2137263708 bytes = { 105, 47, 249, 171, 64, 55, 195, 235, 198, 159, 46, 193, 42, 65, 156, 243, 134, 177, 35, 221, 75, 16, 222, 103, 42, 55, 103, 231 }
Session ID:  {42, 151, 108, 66, 43, 195, 53, 201, 234, 24, 245, 14, 183, 242, 185, 128, 66, 115, 60, 35, 167, 159, 178, 238, 93, 155, 20, 195, 95, 155, 11, 79}
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
Extension ec_point_formats, formats: [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2]
***

您可以看到在ClientHello中添加了所需的扩展名

Extension server_name, server_name: [type=host_name (0), value=www.territrespicio.com]

没有记录的解决方法。 因此,请考虑使用JDK版本 <8u66或> = 8u152

更新-解决方法

使用Java8在SNI客户端之谜中查看@Dawuid的答案

如果您使用自定义SSLSocketFactory而没有覆盖createSocket()
(不带html" target="_blank">参数的方法),则会使用参数化了的createSocket,并且所有操作都按预期进行(带有客户端sni扩展名)。

您可以在此处找到类似的解决方法。我已经尝试了一个包装器,它的工作原理。

HttpsURLConnection.setDefaultSSLSocketFactory(
   new SSLSocketFactoryWrapper(sc.getSocketFactory()));

SSLSocketFactoryWrapper(完整代码)

package test;

import java.io.IOException;
import java.net.InetAddress;
import java.net.Socket;
import java.net.UnknownHostException;

import javax.net.ssl.SSLSocketFactory;

public class SSLSocketFactoryWrapper extends SSLSocketFactory {

    private SSLSocketFactory factory;

    public   SSLSocketFactoryWrapper(SSLSocketFactory factory){
        this.factory = factory;
    }

    /* 
    @Override
    public Socket createSocket() throws IOException {
        return  factory.createSocket();
    }
    */

    @Override
    public Socket createSocket(Socket s, String host, int port, boolean autoClose) throws IOException {         
        return factory.createSocket(s, host, port, autoClose);
    }

    @Override
    public String[] getDefaultCipherSuites() {
        return factory.getDefaultCipherSuites();
    }

    @Override
    public String[] getSupportedCipherSuites() {
        return factory.getSupportedCipherSuites();
    }

    @Override
    public Socket createSocket(String host, int port) throws IOException, UnknownHostException {
        return factory.createSocket(host, port);
    }

    @Override
    public Socket createSocket(InetAddress host, int port) throws IOException {
        return factory.createSocket(host, port);
    }

    @Override
    public Socket createSocket(String host, int port, InetAddress localHost, int localPort)
            throws IOException, UnknownHostException {
        return factory.createSocket(host, port, localHost, localPort);
    }

    @Override
    public Socket createSocket(InetAddress address, int port, InetAddress localAddress, int localPort) throws IOException {
        return factory.createSocket(address, port, localAddress, localPort);
    }

}


 类似资料:
  • 我已经看到了一些使用X509TrustManager实现TrustManager的示例,尽管显然Java7不支持这些约定,X509TrustManager本身也被弃用。 感谢您的建议和任何在Java7上工作的代码示例。

  • 我有一个简单的java程序,它以并行线程向服务器发送10,000个HTTP请求。 我的服务器是一个amazon ec2实例,运行在ubuntu、apache Tomcat7、30G RAM、4个CPU上。

  • 问题内容: 有谁知道为什么以下代码无法编译?add()和addAll()均无法按预期工作。删除“?extends”部分可以使所有工作正常,但是我将无法添加Foo的子类。 错误1: IntelliJ说: 编译器说: 错误2: IntelliJ给我 而编译器只是说 问题答案: (我在这里假设和都是的子类型。) 表示 某种类型的元素的列表,这是Foo的子类型,但我们不知道哪种类型 。此类列表的示例为a

  • 我已经在我的spring boot应用程序中启用了ssl,并且任何时候我想使用像GooglePis或facebook这样的Rest服务,我都必须在TrustStore中添加证书。 我使用openssl获取证书: openssl s_client-connect googleapis.com:443 并将其导入truststore: keytool.exe-import-noprompt-trust