Java 7 的 SSL 连接失败

【问题标题】：SSL connection failing for Java 7Java 7 的 SSL 连接失败
【发布时间】：2013-10-14 06:20:04
【问题描述】：

我正在尝试使用 Java 7 创建与远程服务器的 SSL 连接，但收到以下异常：

javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:946)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
    at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702)
    at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122)
    at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
    at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
    at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
    at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
    at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
    at java.io.BufferedWriter.flush(BufferedWriter.java:254)
    at ssl7.Client.main(Client.java:22)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
    at sun.security.ssl.InputRecord.read(InputRecord.java:482)
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)

当我使用 Java 6 重新运行代码时，也不例外。我在 StackOverflow 的其他地方找到了对这个问题的引用，但我的情况有所不同。使用 Java 7 失败的客户端代码是

public class Client {

    public static void main(String[] args) throws FileNotFoundException, IOException, ClassNotFoundException {
        try {
            SSLSocketFactory sslsocketfactory = (SSLSocketFactory) SSLSocketFactory.getDefault();
            SSLSocket sslsocket = (SSLSocket) sslsocketfactory.createSocket("login.solon.com", 443);    
            OutputStream outputstream = sslsocket.getOutputStream();
            OutputStreamWriter outputstreamwriter = new OutputStreamWriter(outputstream);
            BufferedWriter bufferedwriter = new BufferedWriter(outputstreamwriter);
                bufferedwriter.write("hello\n");
                bufferedwriter.flush();
        } catch (Exception exception) {
            exception.printStackTrace();
        }
    }
}

当我添加行时

sslsocket.setEnabledCipherSuites(new String[] {"SSL_RSA_WITH_RC4_128_MD5"});

创建套接字后，它就可以工作了。

现在，SSL_RSA_WITH_RC4_128_MD5 存在于原始密码套件集中，所以我所做的只是添加限制。从长远来看，限制密码套件不是一个可行的解决方案。谁能解释这里发生了什么？

完整的调试日志是：

keyStore is : 
keyStore type is : jks
keyStore provider is : 
init keystore
init keymanager of type SunX509
trustStore is: C:\Temp\keystore\clientkeystore
trustStore type is : jks
trustStore provider is : 
init truststore
adding as trusted cert:
  Subject: CN=W, OU=D, O=S, L=H, ST=I, C=IL
  Issuer:  CN=W, OU=D, O=S, L=H, ST=I, C=IL
  Algorithm: DSA; Serial number: 0x4a6e05b7
  Valid from Mon Oct 07 10:22:54 EEST 2013 until Sun Jan 05 09:22:54 EET 2014

adding as trusted cert:
  Subject: CN=login.solon.com, OU=Domain Validated, OU=Thawte SSL123 certificate, OU=Go to https://www.thawte.com/repository/index.html
  Issuer:  CN=Thawte DV SSL CA, OU=Domain Validated SSL, O="Thawte, Inc.", C=US
  Algorithm: RSA; Serial number: 0x3012ec22473f20aa2cdc4bf7fe2d22f4
  Valid from Wed Feb 13 02:00:00 EET 2013 until Thu Apr 14 02:59:59 EEST 2016

adding as trusted cert:
  Subject: CN=W, OU=D, O=S, L=H, ST=I, C=IL
  Issuer:  CN=W, OU=D, O=S, L=H, ST=I, C=IL
  Algorithm: RSA; Serial number: 0x5864235a
  Valid from Mon Oct 07 10:28:06 EEST 2013 until Sun Jan 05 09:28:06 EET 2014

trigger seeding of SecureRandom
done seeding SecureRandom
Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256
Allow unsafe renegotiation: true
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
%% No cached client session
*** ClientHello, TLSv1
RandomCookie:  GMT: 1381093608 bytes = { 221, 239, 107, 239, 150, 213, 224, 210, 101, 229, 42, 58, 92, 9, 151, 0, 128, 105, 0, 55, 53, 224, 90, 111, 130, 175, 61, 121 }
Session ID:  {}
Cipher Suites: [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_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, 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, SSL_RSA_WITH_RC4_128_MD5, 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]
***
[write] MD5 and SHA1 hashes:  len = 149
0000: 01 00 00 91 03 01 52 52   D1 E8 DD EF 6B EF 96 D5  ......RR....k...
0010: E0 D2 65 E5 2A 3A 5C 09   97 00 80 69 00 37 35 E0  ..e.*:\....i.75.
0020: 5A 6F 82 AF 3D 79 00 00   2A C0 09 C0 13 00 2F C0  Zo..=y..*...../.
0030: 04 C0 0E 00 33 00 32 C0   07 C0 11 00 05 C0 02 C0  ....3.2.........
0040: 0C C0 08 C0 12 00 0A C0   03 C0 0D 00 16 00 13 00  ................
0050: 04 00 FF 01 00 00 3E 00   0A 00 34 00 32 00 17 00  ......>...4.2...
0060: 01 00 03 00 13 00 15 00   06 00 07 00 09 00 0A 00  ................
0070: 18 00 0B 00 0C 00 19 00   0D 00 0E 00 0F 00 10 00  ................
0080: 11 00 02 00 12 00 04 00   05 00 14 00 08 00 16 00  ................
0090: 0B 00 02 01 00                                     .....
main, WRITE: TLSv1 Handshake, length = 149
[Raw write]: length = 154
0000: 16 03 01 00 95 01 00 00   91 03 01 52 52 D1 E8 DD  ...........RR...
0010: EF 6B EF 96 D5 E0 D2 65   E5 2A 3A 5C 09 97 00 80  .k.....e.*:\....
0020: 69 00 37 35 E0 5A 6F 82   AF 3D 79 00 00 2A C0 09  i.75.Zo..=y..*..
0030: C0 13 00 2F C0 04 C0 0E   00 33 00 32 C0 07 C0 11  .../.....3.2....
0040: 00 05 C0 02 C0 0C C0 08   C0 12 00 0A C0 03 C0 0D  ................
0050: 00 16 00 13 00 04 00 FF   01 00 00 3E 00 0A 00 34  ...........>...4
0060: 00 32 00 17 00 01 00 03   00 13 00 15 00 06 00 07  .2..............
0070: 00 09 00 0A 00 18 00 0B   00 0C 00 19 00 0D 00 0E  ................
0080: 00 0F 00 10 00 11 00 02   00 12 00 04 00 05 00 14  ................
0090: 00 08 00 16 00 0B 00 02   01 00                    ..........
main, received EOFException: error
main, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
main, SEND TLSv1 ALERT:  fatal, description = handshake_failure
main, WRITE: TLSv1 Alert, length = 2
[Raw write]: length = 7
0000: 15 03 01 00 02 02 28                               ......(
main, called closeSocket()
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:946)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
    at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702)
    at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122)
    at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
    at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
    at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
    at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
    at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
    at java.io.BufferedWriter.flush(BufferedWriter.java:254)
    at ssl7.Client.main(Client.java:22)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
    at sun.security.ssl.InputRecord.read(InputRecord.java:482)
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
    ... 10 more

谢谢。

【问题讨论】：

  • 问题格式特别好！继续加油！
  • 也许你的代码需要更牢固的握手。我知道我拒绝所有与弱握手的连接。
  • 您使用的是哪个特定的 java 版本？在客户端和服务器上。
  • 我在 Java 1.7.0_21 vs 1.6.0_25 上运行代码
  • 服务器运行1.7.0_21

标签： java ssl


【解决方案1】：

我之前在使用 Ubuntu 12.04 服务器运行基于 Java 的服务器时遇到过此类问题，该服务器使用 OpenJDK 包。 （这可能已经打了补丁，因为我无法用最新更新重现问题，但我的配置可能略有不同，我不记得了。）

这本质上是this Ubuntu issue中描述的问题。

服务器端的 EC 计算本质上存在问题，导致无法正确建立连接。

Java 6 和 Java 7 之间的密码套件的优先顺序有所不同（请参阅两个表）。

因为TLS_RSA_WITH_AES_128_CBC_SHA 在 Java 6 中的优先顺序中高于任何 EC 密码套件（并且客户端和服务器都支持），所以当您连接 Java 6 客户端时会选择它。

当您使用 Java 7 客户端连接时，将选择一些 EC 密码套件（例如 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 或 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA）并且服务器将开始执行此操作（您需要查看握手调试日志服务器端确认这一点）。然后服务器将完成密码套件选择过程，但由于尝试使用此密码套件时出现后续错误而无法继续进行。

如果您对服务器有一定的控制权（并且如果它确实在运行基于 Java 的服务器），请尝试升级到最新的 JRE 包。您还可以尝试 Ubuntu 问题中建议的修复（特别是如果它不使用 PKCS#11）或在服务器配置中禁用 ECDHE 密码套件。

【讨论】：

    【解决方案2】：

    从您的服务器配置 (https://www.ssllabs.com/ssltest/analyze.html?d=login.solon.com) 与 Java7 中可用密码套件列表的对比来看，您的密码套件似乎只有两个可接受的选项：

    TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA

    现在，TLS_DHE_RSA_WITH_AES_128_CBC_SHA 被认为是弱的，但由于您的服务器声明不偏好顺序，它可能会选择它然后握手失败。对于 Java6，它完全有可能只是碰巧选择了一个更强大的套件。你给它的选项越多，你给它选择弱密码的机会就越大，所以当你指定一个要使用的套件时，它就会成功。 （虽然在查看您的服务器配置时，我不确定您是如何让 SSL_RSA_WITH_RC4_128_MD5 成功的，因为它显然不受支持。）按照这种思路，也许您应该尝试将您的密码套件限制为：

    TLS_RSA_WITH_AES_128_CBC_SHA

    或者更具体地说：

    sslsocket.setEnabledCipherSuites(new String[] {"TLS_RSA_WITH_AES_128_CBC_SHA"});

    【讨论】：

    • 为什么 DHE_RSA 密码很弱？ TLS_DHE_RSA_WITH_AES_128_CBC_SHA 具有完美的前向保密性，TLS_RSA_WITH_AES_128_CBC_SHA 没有，否则它们是相同的。
    • 回答我自己的评论，无论出于何种原因，Java 6 和 Java 7 中的 SunJSSE 加密提供程序使用 768 位 DH 密钥，似乎没有办法改变它，这很遗憾，因为唯一的解决方法是禁用 DHE 套件。
    • 很高兴您能够回答自己的评论，因为我不知道这一点。 =)
    【解决方案3】：

    这是 Java 7 与密钥库的兼容性问题。将您的密钥库文件转换为 .p12 。它应该可以使用它。

    【讨论】：

    • 你从哪里得到这个想法的？这里的客户端没有密钥库。
    【解决方案4】：

    您在执行客户端时是否包含了信任库？ 

    java -Djavax.net.ssl.trustStore=${resources}/localhost.truststore \
-Djavax.net.ssl.trustStorePassword=TRUSTSTORE_PASSWORD -jar client.jar com.acme.RunClient

    【讨论】：

    • 阅读问题。从痕迹中可以明显看出他有一个信任库。无论如何，一个问题是。这是一个答案。
    猜你喜欢
    • 2016-08-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-06-22
    • 2018-12-30
    • 2013-10-10
    • 1970-01-01
    • 2011-09-12
    相关资源
    最近更新 更多
    热门标签
    Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode