前端之家

  1. 首页
  2. 问答

JDK 11上的RabbitMQ客户端SSL握手问题

• 问答

我们有一个RabbitMQ客户端正在运行，一旦切换到JDK 11，就开始在SSL握手中收到以下错误：

Caused by: java.io.EOFException: SSL peer shut down incorrectly

我们的环境是：

Rabbitmq java client version: 5.7.3
OpenJDK 11.0.4
MacOS - 10.14.6
  • 我们一直在运行测试，并因EOF异常而不断失败。
  • 对于工作和不工作测试的客户端代码都没有更改。唯一的变化是不同的服务器端点。
  • rabbitmq代理端点均适用于JDK版本8、9和10。
  • 我还将代理的公共证书也添加到客户端JDK密钥库中。

下面是测试的堆栈跟踪：

javax.net.ssl|DEBUG|01|ScalaTest-run-running-RabbitMqConsumerTest|2019-11-07 13:57:41.429 GMT|ClientHello.java:653|Produced ClientHello handshake message (
"ClientHello": {
  "client version"      : "TLSv1.2","random"              : "3E 14 77 54 AB A2 BF 3D E0 56 F8 85 60 32 77 35 35 AC CB 71 D9 14 19 D9 0F 7C 93 C6 F7 DF 68 9D","session id"          : "","cipher suites"       : "[TLS_ecdhe_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C),TLS_ecdhe_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B),TLS_ecdhe_RSA_WITH_AES_256_GCM_SHA384(0xC030),TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D),TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(0xC02E),TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(0xC032),TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F),TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3),TLS_ecdhe_RSA_WITH_AES_128_GCM_SHA256(0xC02F),TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C),TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D),TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031),TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E),TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2),TLS_ecdhe_ECDSA_WITH_AES_256_CBC_SHA384(0xC024),TLS_ecdhe_RSA_WITH_AES_256_CBC_SHA384(0xC028),TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D),TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(0xC026),TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(0xC02A),TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B),TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A),TLS_ecdhe_ECDSA_WITH_AES_256_CBC_SHA(0xC00A),TLS_ecdhe_RSA_WITH_AES_256_CBC_SHA(0xC014),TLS_RSA_WITH_AES_256_CBC_SHA(0x0035),TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(0xC005),TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(0xC00F),TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039),TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038),TLS_ecdhe_ECDSA_WITH_AES_128_CBC_SHA256(0xC023),TLS_ecdhe_RSA_WITH_AES_128_CBC_SHA256(0xC027),TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C),TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025),TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029),TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067),TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040),TLS_ecdhe_ECDSA_WITH_AES_128_CBC_SHA(0xC009),TLS_ecdhe_RSA_WITH_AES_128_CBC_SHA(0xC013),TLS_RSA_WITH_AES_128_CBC_SHA(0x002F),TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004),TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E),TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033),TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032),TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]","compression methods" : "00","extensions"          : [
    "status_request (5)": {
      "certificate status type": ocsp
      "OCSP status request": {
        "responder_id": <empty>
        "request extensions": {
          <empty>
        }
      }
    },"supported_groups (10)": {
      "versions": [secp256r1,secp384r1,secp521r1,sect283k1,sect283r1,sect409k1,sect409r1,sect571k1,sect571r1,secp256k1,ffdhe2048,ffdhe3072,ffdhe4096,ffdhe6144,ffdhe8192]
    },"ec_point_formats (11)": {
      "formats": [uncompressed]
    },"signature_algorithms (13)": {
      "signature schemes": [ecdsa_secp256r1_sha256,ecdsa_secp384r1_sha384,ecdsa_secp512r1_sha512,rsa_pss_rsae_sha256,rsa_pss_rsae_sha384,rsa_pss_rsae_sha512,rsa_pss_pss_sha256,rsa_pss_pss_sha384,rsa_pss_pss_sha512,rsa_pkcs1_sha256,rsa_pkcs1_sha384,rsa_pkcs1_sha512,dsa_sha256,ecdsa_sha224,rsa_sha224,dsa_sha224,ecdsa_sha1,rsa_pkcs1_sha1,dsa_sha1]
    },"signature_algorithms_cert (50)": {
      "signature schemes": [ecdsa_secp256r1_sha256,"status_request_v2 (17)": {
      "cert status request": {
        "certificate status type": ocsp_multi
        "OCSP status request": {
          "responder_id": <empty>
          "request extensions": {
            <empty>
          }
        }
      }
    },"extended_master_secret (23)": {
      <empty>
    },"supported_versions (43)": {
      "versions": [TLSv1.2,TLSv1.1,TLSv1]
    }
  ]
}
)
javax.net.ssl|ERROR|01|ScalaTest-run-running-RabbitMqConsumerTest|2019-11-07 13:57:41.724 GMT|TransportContext.java:312|Fatal (HANDSHAKE_FAILURE): Couldn't kickstart handshaking (
"throwable" : {
  javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
    at java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1322)
    at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1160)
    at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
    at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
    at java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:716)
    at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:970)
    at java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81)
    at java.base/java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142)
    at java.base/java.io.DataOutputStream.flush(DataOutputStream.java:123)
    at com.rabbitmq.client.impl.SocketFrameHandler.sendHeader(SocketFrameHandler.java:160)
    at com.rabbitmq.client.impl.SocketFrameHandler.sendHeader(SocketFrameHandler.java:170)
    at com.rabbitmq.client.impl.AMQConnection.start(AMQConnection.java:305)
    at com.rabbitmq.client.impl.recovery.RecoveryAwareAMQConnectionFactory.newConnection(RecoveryAwareAMQConnectionFactory.java:64)
    at com.rabbitmq.client.impl.recovery.AutorecoveringConnection.init(AutorecoveringConnection.java:156)
    at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:1106)
    at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:1063)
    at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:1021)
    at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:1182)
    at generator.RabbitMQ$.getMQConnection(RabbitMQ.scala:58)
    at generator.RabbitMqConsumerTest.$anonfun$new$2(RabbitMqConsumerTest.scala:50)
  Caused by: java.io.EOFException: SSL peer shut down incorrectly
    at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:167)
    at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
    at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
    ... 80 more}
)
Working error logs:
javax.net.ssl|DEBUG|01|ScalaTest-run-running-RabbitMqConsumerTest|2019-11-07 13:32:26.482 GMT|ClientHello.java:653|Produced ClientHello handshake message (
"ClientHello": {
  "client version"      : "TLSv1.2","random"              : "58 45 2D 14 80 18 D7 96 51 01 8A 87 6C 74 5F D3 D9 A7 2B F8 4C EF 9C D7 0E EB 77 0F 99 1D 79 15",TLSv1]
    }
  ]
}
)
javax.net.ssl|DEBUG|01|ScalaTest-run-running-RabbitMqConsumerTest|2019-11-07 13:32:36.811 GMT|ServerHello.java:871|Consuming ServerHello handshake message (
"ServerHello": {
  "server version"      : "TLSv1.2","random"              : "5D C4 1C EA CB 34 AD BF FE E1 91 89 40 4C 04 7A FF F1 A7 D2 0F C6 92 C6 F3 7B 20 C0 84 C2 B7 24","session id"          : "32 E8 61 CF D7 89 E7 47 EC 00 2C A2 4D 78 86 07 6B 8E E8 B3 AC C5 41 E3 89 B8 DE 9C 93 A9 3A 5E","cipher suite"        : "TLS_ecdhe_RSA_WITH_AES_256_GCM_SHA384(0xC030)","extensions"          : [
    "renegotiation_info (65,281)": {
      "renegotiated connection": [<no renegotiated connection>]
    },"ec_point_formats (11)": {
      "formats": [uncompressed]
    }
  ]
}
)

rabbitmq服务器日志-

2019-11-07 17:59:32.639 [info] <0.25302.1> TLS server: In state certify at ssl_connection.erl:757 generated SERVER ALERT: Fatal - Handshake Failure
code8945 回答：JDK 11上的RabbitMQ客户端SSL握手问题

JDK 11包含的功能之一是TLSv1.3的实现。

请参见JEP 332和JDK 11 features。 在this issue中有更多详细信息。

在测试的堆栈跟踪中，TLSv1.2,TLSv1.1,TLSv1是受支持的版本，TLSv1.2是服务器和客户端的版本，这很自然，因为当今的RabbitMQ TLS支持的版本是1.1和1.2。 （请参见docs）。令人惊讶的是应该有一个

所有这些都是基于日志的假设，因此我为您提供了一些可以尝试的方法：

  • 尝试添加以下配置，然后重新运行测试。这是为了验证问题确实与TLS兼容性有关。 
SslContextFactory sslContextFactory = new SslContextFactory();
sslContextFactory.setExcludeProtocols("TLSv1.3");

  • 使用以下命令在Java上启用SSL握手调试 -Djavax.net.debug=ssl:handshake:verbose

  • 验证TLSv1.3中没有消除您的算法和密码。

如果您对此问题有新见解，请告诉我，也许我可以提供进一步的帮助:)

,

我不确定您的问题是什么，因为没有足够的数据来确定它，但这看起来像是我的问题。

我认为您的问题始于jdk 11.0.3，因此，如果您尝试11.0.2必须可行...

就我而言：

问题在于，JDK 11.0.3更改了ClientAuthManager.chooseClientAlias（）的调用。

在JDK 11.0.2中：

choseClientAlias({"EC","RSA","DSA"},socket);

在JDK 11.0.3中：

for (String keyType : {"EC","DSA"}) { 
    choseClientAlias({ keyType },socket);
}

因此，当您必须测试有效证书时，仅在第一次调用时有效：

choseClientAlias({"EC"},socket);

也许您可以在selectedClientAlias对其进行调试，通过“ RSA”或“ DSA”更改第一个keyType，并证明这是否是您的问题。

javajava-11rabbitmqscala
本文链接：https://www.f2er.com/3138604.html

大家都在问