如何在java中设置SSL协议版本？我怎么知道是哪一个？javax.net.ssl.SSLException：收到致命警报：protocol_version

How do I set SSL protocol version in java? And how do I know which one? javax.net.ssl.SSLException: Received fatal alert: protocol_version

提问by yankee

I am using Apache HttpClient 4.3 to interact with the API of hubic.com. My minimal reproducable example is just a one liner:

我正在使用 Apache HttpClient 4.3 与 hubic.com 的 API 进行交互。我的最小可重复示例只是一个衬垫：

HttpClientBuilder.create().build().execute(new HttpGet("https://hubic.com"));

However that throws:

然而，抛出：

Exception in thread "main" javax.net.ssl.SSLException: Received fatal alert: protocol_version
    at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
    at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
    at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1991)
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1104)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1343)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1371)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355)
    at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:275)
    at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:254)
    at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:117)
    at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314)
    at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363)
    at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219)
    at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
    at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
    at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
    at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)

Here is the output if I run with System.setProperty("javax.net.debug", "all");:

如果我运行，这是输出System.setProperty("javax.net.debug", "all");：

trustStore is: /usr/lib/jvm/java-8-oracle/jre/lib/security/cacerts
trustStore type is : jks
trustStore provider is : 
init truststore

adding as trusted cert: [... extremely large list ...]

trigger seeding of SecureRandom
done seeding SecureRandom
Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384
Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for SSLv3
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for SSLv3
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 for SSLv3
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 for SSLv3
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 for SSLv3
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for SSLv3
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 for SSLv3
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 for TLSv1.1
%% No cached client session
*** ClientHello, TLSv1.2
RandomCookie:  GMT: 1402182685 bytes = { 227, 155, 148, 161, 7, 104, 221, 182, 254, 133, 216, 198, 118, 211, 223, 229, 43, 82, 207, 1, 102, 245, 112, 117, 253, 69, 43, 162 }
Session ID:  {}
Cipher Suites: [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_128_GCM_SHA256, 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_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, 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]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA, MD5withRSA
Extension server_name, server_name: [type=host_name (0), value=hubic.com]
***
[write] MD5 and SHA1 hashes:  len = 225
0000: 01 00 00 DD 03 03 54 94   9C 1D E3 9B 94 A1 07 68  ......T........h
0010: DD B6 FE 85 D8 C6 76 D3   DF E5 2B 52 CF 01 66 F5  ......v...+R..f.
0020: 70 75 FD 45 2B A2 00 00   46 C0 23 C0 27 00 3C C0  pu.E+...F.#.'.<.
0030: 25 C0 29 00 67 00 40 C0   09 C0 13 00 2F C0 04 C0  %.).g.@...../...
0040: 0E 00 33 00 32 C0 2B C0   2F 00 9C C0 2D C0 31 00  ..3.2.+./...-.1.
0050: 9E 00 A2 C0 08 C0 12 00   0A C0 03 C0 0D 00 16 00  ................
0060: 13 C0 07 C0 11 00 05 C0   02 C0 0C 00 04 00 FF 01  ................
0070: 00 00 6E 00 0A 00 34 00   32 00 17 00 01 00 03 00  ..n...4.2.......
0080: 13 00 15 00 06 00 07 00   09 00 0A 00 18 00 0B 00  ................
0090: 0C 00 19 00 0D 00 0E 00   0F 00 10 00 11 00 02 00  ................
00A0: 12 00 04 00 05 00 14 00   08 00 16 00 0B 00 02 01  ................
00B0: 00 00 0D 00 1A 00 18 06   03 06 01 05 03 05 01 04  ................
00C0: 03 04 01 03 03 03 01 02   03 02 01 02 02 01 01 00  ................
00D0: 00 00 0E 00 0C 00 00 09   68 75 62 69 63 2E 63 6F  ........hubic.co
00E0: 6D                                                 m
main, WRITE: TLSv1.2 Handshake, length = 225
[Raw write]: length = 230
0000: 16 03 03 00 E1 01 00 00   DD 03 03 54 94 9C 1D E3  ...........T....
0010: 9B 94 A1 07 68 DD B6 FE   85 D8 C6 76 D3 DF E5 2B  ....h......v...+
0020: 52 CF 01 66 F5 70 75 FD   45 2B A2 00 00 46 C0 23  R..f.pu.E+...F.#
0030: C0 27 00 3C C0 25 C0 29   00 67 00 40 C0 09 C0 13  .'.<.%.).g.@....
0040: 00 2F C0 04 C0 0E 00 33   00 32 C0 2B C0 2F 00 9C  ./.....3.2.+./..
0050: C0 2D C0 31 00 9E 00 A2   C0 08 C0 12 00 0A C0 03  .-.1............
0060: C0 0D 00 16 00 13 C0 07   C0 11 00 05 C0 02 C0 0C  ................
0070: 00 04 00 FF 01 00 00 6E   00 0A 00 34 00 32 00 17  .......n...4.2..
0080: 00 01 00 03 00 13 00 15   00 06 00 07 00 09 00 0A  ................
0090: 00 18 00 0B 00 0C 00 19   00 0D 00 0E 00 0F 00 10  ................
00A0: 00 11 00 02 00 12 00 04   00 05 00 14 00 08 00 16  ................
00B0: 00 0B 00 02 01 00 00 0D   00 1A 00 18 06 03 06 01  ................
00C0: 05 03 05 01 04 03 04 01   03 03 03 01 02 03 02 01  ................
00D0: 02 02 01 01 00 00 00 0E   00 0C 00 00 09 68 75 62  .............hub
00E0: 69 63 2E 63 6F 6D                                  ic.com
[Raw read]: length = 5
0000: 15 03 00 00 02                                     .....
[Raw read]: length = 2
0000: 02 46                                              .F
main, READ: SSLv3 Alert, length = 2
main, RECV TLSv1.2 ALERT:  fatal, protocol_version
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLException: Received fatal alert: protocol_version

No exception is thrown if I try to access e.g. https://google.com. So it guess SSL with Java cannot be completely broken on my system but it has to do with the combination with hubic.com.

如果我尝试访问例如https://google.com ，则不会引发任何异常。所以它猜测 SSL with Java 在我的系统上不能完全破坏，但它与与 hubic.com 的组合有关。

The error protocol_versionis not very helpful, but in this questionit is suggested that my client uses another protocol version than the server (I guess "server and client could not agree on a protocol" would be more accurate).

该错误protocol_version不是很有帮助，但在这个问题中，建议我的客户端使用另一个协议版本而不是服务器（我猜“服务器和客户端无法就协议达成一致”会更准确）。

How do I figure out which protocol versions the server will agree on and how do I enable those in my client? And should I worry about the issue (e.g. like does hubic only allow an old unsupported protocol? (Firefox certainly does not complain about anything unsecure).

我如何确定服务器将同意哪些协议版本以及如何在我的客户端中启用这些版本？我是否应该担心这个问题（例如，hubic 是否只允许使用不受支持的旧协议？（Firefox 当然不会抱怨任何不安全的东西）。

采纳答案by Steffen Ullrich

I see from the debug that Java does a TLS1.2 handshake instead of the more common SSLv23 handshake:

我从调试中看到 Java 进行了 TLS1.2 握手，而不是更常见的 SSLv23 握手：

main, WRITE: TLSv1.2 Handshake, length = 225
[Raw write]: length = 230
0000: 16 03 03 00
         ^^^^^ - TLS1.2 (SSL3.3)

The server itself can do only TLS1.0 and fails to just announce this older version. I'm not familiar with Java, but you either need set the protocol version to TLSv1 or SSLv23 to speak with this server.

服务器本身只能做 TLS1.0 并且不能只是宣布这个旧版本。我不熟悉 Java，但您需要将协议版本设置为 TLSv1 或 SSLv23 才能与此服务器通信。

The following code would set only TLSv1 with Apache HttpClient:

以下代码将仅使用 Apache HttpClient 设置 TLSv1：

HttpClientBuilder
  .create()
  .setSslcontext(SSLContexts.custom().useProtocol("TLSv1").build())
  .build()
  .execute(new HttpGet("https://hubic.com"));

EDIT to include question from comment:

编辑以包括评论中的问题：

If you say that the server "fails to just announce this older version", does that mean that the server is misconfigured? In this case, why don't Firefox&Chromium have any problems?

如果您说服务器“无法仅发布此旧版本”，是否意味着服务器配置错误？在这种情况下，为什么 Firefox&Chromium 没有任何问题？

If the client announces TLS1.2 in the ClientHello and the server can do only TLS1.0 it should announce this, i.e. reply with TLS1.0. The client can then close the connection if TLS1.0 is not good enough or continue with TLS1.0. But, in this case the server just told the client that it does not like this version and closed the connection. Firefox and others instead do a SSLv23 announcement, where they do a TLS1.0 handshake but also announce the best protocol version they support. This usually works good for older servers starting from SSL3.0 but also for newer servers.

如果客户端在 ClientHello 中宣布 TLS1.2 而服务器只能做 TLS1.0，它应该宣布这一点，即回复 TLS1.0。如果 TLS1.0 不够好，客户端可以关闭连接或继续使用 TLS1.0。但是，在这种情况下，服务器只是告诉客户端它不喜欢这个版本并关闭了连接。Firefox 和其他公司改为发布 SSLv23 公告，他们在其中进行 TLS1.0 握手，但也发布了他们支持的最佳协议版本。这通常适用于从 SSL3.0 开始的旧服务器，但也适用于较新的服务器。

You can check the behavior of the server with a recent Perl/IO::Socket::SSL and this script.

您可以使用最近的 Perl/IO::Socket::SSL 和此脚本检查服务器的行为。

$ perl analyze-ssl.pl hubic.com
-- hubic.com port 443
 * maximum SSL version  : TLSv1 (SSLv23)
 * supported SSL versions with handshake used and preferred cipher(s):
   * handshake protocols ciphers
   * SSLv23    TLSv1     AES256-SHA
   * TLSv1_2   FAILED: SSL connect attempt failed error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
   * TLSv1_1   FAILED: SSL connect attempt failed error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
   * TLSv1     TLSv1     AES256-SHA
   * SSLv3     FAILED: SSL connect attempt failed because of handshake problems error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version

Here you can see, that the hosts supports SSLv23 and TLSv1 handshakes, but not the used TLSv1_2 handshake.

在这里您可以看到，主机支持 SSLv23 和 TLSv1 握手，但不支持使用的 TLSv1_2 握手。

回答by Powerlord

HttpClient can take an SSLContextfor its SSLConnectionSocketFactory.

HttpClient 可以SSLContext为其SSLConnectionSocketFactory.

You can set the appropriate TLS version in the properties for the SSLContextwith the getInstancestatic method.

您可以SSLContext使用getInstance静态方法在属性中设置适当的 TLS 版本。

Something like SSLContext context = SSLContext.getInstance("TLSv1");

就像是 SSLContext context = SSLContext.getInstance("TLSv1");

If you need to force just one protocol (as getInstancecan return one that supports multiple protocols), you can use the setEnabledProtocolsmethod (which takes a String[]) on the contextyou retrieved using getInstance.

如果您需要强制只是一个协议（如getInstance可以返回一个支持多协议），则可以使用setEnabledProtocols方法（这需要一个String[]对）context你使用取出了getInstance。

回答by user3376448

I have also come across this issue. Certain sites are not accessible, throwing the mysterious: javax.net.ssl.SSLException: Received fatal alert: protocol_version

我也遇到过这个问题。某些站点无法访问，抛出神秘的：javax.net.ssl.SSLException: Received fatal alert: protocol_version

I have tried to mend it, following some of the hints given here, but without success. At one point the usual thought “it used to work before..”, really started nagging me.

我试图按照这里给出的一些提示来修复它，但没有成功。有一次，通常的想法“它以前可以工作......”，真的开始唠叨我。

Initially I had assumed something had changed in the site I tried to connect to. However, as this is a legacy kind of site, it wasn't so likely. So, what else could it be..? At one point I thought “Java version”. Unlikely, but maybe worth a try.

最初，我认为我尝试连接的站点发生了一些变化。然而，由于这是一个遗留类型的网站，它不太可能。那么，还能是什么..？一度我想到了“Java 版”。不太可能，但也许值得一试。

As it is, I can get the content from previously error-throwing sites, if I compile my code with SDK 1.6.0_25. Newer versions gives me problems: 1.7.0_51, and 1.8.0.

事实上，如果我使用 SDK 1.6.0_25 编译我的代码，我可以从以前抛出错误的站点获取内容。较新的版本给我带来了问题：1.7.0_51 和 1.8.0。

I have boiled it down to the smallest piece possible, if effect reproducing the one-liner initially posted by “Yankee” above. I have used the same line, including the same URL.

如果效果重现上面最初由“Yankee”发布的单线，我已将其归结为尽可能小的部分。我使用了同一行，包括相同的 URL。

Compiling with SDK 1.6 it works.

使用 SDK 1.6 编译它可以工作。

I am not sufficiently skilled in Java and SSL to understand the root issue behind this. But, someone ought to be able to put the code side by side, and track it down..

我在 Java 和 SSL 方面不够熟练，无法理解这背后的根本问题。但是，应该有人能够将代码并排放置，并对其进行追踪。

This may save someone a few wasted hours.

这可能会节省一些人浪费的几个小时。

回答by Samrat K

It looks like you are not using java 1.8

看起来您没有使用 java 1.8

In Java 1.8 the default TLS protocol version is v1.2, whereas in Java 1.6,1.7 default is TLS1.0. As you can see in logs ClientHello, TLSv1.2 it means you are either using java 1.6 or 1.7 now you can either switch to 1.8 or Just add

在 Java 1.8 中，默认 TLS 协议版本为 v1.2，而在 Java 1.6、1.7 中默认为 TLS1.0。正如您在日志ClientHello, TLSv1.2 中看到的那样 ，这意味着您现在使用的是 java 1.6 或 1.7，现在您可以切换到 1.8 或只需添加

static { System.setProperty("https.protocols", "TLSv1.2"); }

静态{ System.setProperty("https.protocols", "TLSv1.2"); }

in your application class before main class keeping you current java version
.. hope this helps !!

在主类之前的应用程序类中，让您保持当前的 Java 版本
.. 希望这会有所帮助！