HTTPS 发送请求出现TLS握手失败
最近在工作中，调外部接口，发现在clientHello步骤报错，服务端没有返回serverHello。
从网上找了写方法，都没有解决；
在idea的vm options加上参数：
-Djavax.net.debug=SSL,handshake 把SSL和handshake的日志打印出来；
看到的异常日志如下：
"ClientHello": {
"client version" : "TLSv1.2",
"random" : "6A 07 F0 0E B6 96 23 B2 35 2D CD 3E 2B 7B D2 E5 14 B8 43 A9 44 24 0C B8 62 29 AD C5 7A C4 EE 16",
"session id" : "82 48 DC 04 FA CF 39 4B BF 38 52 7F 4E B7 42 ED DD 48 4F 38 CA 9E 68 96 39 79 AA 2E B4 A4 2E FB",
"cipher suites" : "[TLS_AES_256_GCM_SHA384(0x1302), TLS_AES_128_GCM_SHA256(0x1301), TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]",
"compression methods" : "00",
"extensions" : [
"server_name (0)": {
type=host_name (0), value=
},
"supported_groups (10)": {
"versions": [ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]
},
"ec_point_formats (11)": {
"formats": [uncompressed]
},
"signature_algorithms (13)": {
"signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_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_sha1, rsa_pkcs1_sha1, dsa_sha1]
},
"signature_algorithms_cert (50)": {
"signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_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_sha1, rsa_pkcs1_sha1, dsa_sha1]
},
"extended_master_secret (23)": {
<empty>
},
"supported_versions (43)": {
"versions": [TLSv1.3, TLSv1.2]
},
"psk_key_exchange_modes (45)": {
"ke_modes": [psk_dhe_ke]
},
"key_share (51)": {
"client_shares": [
{
"named group": ffdhe2048
"key_exchange": {
0000: 48 B1 7A 2B B0 D1 81 13 EB E1 76 E2 29 8C 1A E3 H.z+......v.)...
0010: 04 24 17 44 45 25 F0 1B 07 18 49 D8 5E 33 1D B1 .$.DE%....I.^3..
0020: B8 EC 51 29 AA 33 4B 2C 2A 61 BB 45 E7 F4 E2 94 ..Q).3K,*a.E....
0030: 95 31 7C 9E B7 28 78 75 C1 68 10 82 E5 77 0C 98 .1...(xu.h...w..
0040: 8E F2 69 4A DB 37 0C B7 AE B4 3E D4 A6 6D 79 2B ..iJ.7....>..my+
0050: C7 80 B4 C0 BB C9 AD A1 EF B8 C5 B1 66 75 68 9E ............fuh.
0060: F9 F4 F0 C4 2F E7 E2 4C 12 FC 68 66 59 5D B7 D2 ..../..L..hfY]..
0070: 35 0F D2 8E 37 90 1B F0 FD EC 9C 60 16 0C 83 FA 5...7......`....
0080: BB 8E 2B 7E F9 C2 5E 06 85 76 95 A1 52 04 EF CB ..+...^..v..R...
0090: EF 44 07 58 2F 2A D5 B2 8D B9 32 11 4D D9 07 65 .D.X/*....2.M..e
00A0: D1 C6 F3 40 54 4F 92 48 E5 07 D9 23 42 BE AD 9A ...@TO.H...#B...
00B0: 2D AD 9D AB C0 CA D4 4A 37 5F CC DF B6 3B D2 D8 -......J7_...;..
00C0: D0 CE 4F F1 74 92 81 53 C2 B6 77 2C 76 D1 66 A5 ..O.t..S..w,v.f.
00D0: 14 21 1A 2B F7 E3 E1 F4 9D 98 D6 8D 9E 32 35 80 .!.+.........25.
00E0: 1F 6A 01 D1 DE 31 42 E5 0D 19 F7 67 85 77 4C CC .j...1B....g.wL.
00F0: 2B 62 FD F0 DE 27 68 1D B1 09 40 83 C7 E4 47 7C +b...'h...@...G.
}
},
]
}
]
}
)
javax.net.ssl|FINE|B4|http-nio-8099-exec-1|2024-07-07 10:20:42.945 CST|Alert.java:238|Received alert message (
"Alert": {
"level" : "fatal",
"description": "handshake_failure"
}
)
最终报出来的错误是：javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure；
握手失败。
在别的项目中使用相同的工具类进行调用，使用相同的jdk版本，是可以正常调用的；对比两者的clienthello报文，发现客户端所支持的加密套件是不一样的，调用失败的请求明显少了一些套件；
这是正常请求的报文：
"ClientHello": {
"client version" : "TLSv1.2",
"random" : "A6 F3 8F E9 EA 8C 1C 91 D8 33 EC E9 70 3C 12 05 96 63 EF B0 24 7E 09 65 08 50 74 98 A8 65 F3 08",
"session id" : "02 31 3F 18 F0 35 E3 B9 15 87 D3 D1 A1 A7 59 E7 DD ED 28 07 1D 56 DF 28 64 B6 82 21 D7 9C 79 E6",
"cipher suites" : "[TLS_AES_256_GCM_SHA384(0x1302), TLS_AES_128_GCM_SHA256(0x1301), 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_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), 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_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(0xC02E), TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(0xC032), TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(0xC026), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(0xC02A), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(0xC005), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(0xC00F), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]",
"compression methods" : "00",
"extensions" : [
"server_name (0)": {
type=host_name (0), value=
},
"supported_groups (10)": {
"versions": [secp256r1, secp384r1, secp521r1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]
},
"ec_point_formats (11)": {
"formats": [uncompressed]
},
"signature_algorithms (13)": {
"signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_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_sha1, rsa_pkcs1_sha1, dsa_sha1]
},
"signature_algorithms_cert (50)": {
"signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_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_sha1, rsa_pkcs1_sha1, dsa_sha1]
},
"extended_master_secret (23)": {
<empty>
},
"supported_versions (43)": {
"versions": [TLSv1.3, TLSv1.2]
},
"psk_key_exchange_modes (45)": {
"ke_modes": [psk_dhe_ke]
},
"key_share (51)": {
"client_shares": [
{
"named group": secp256r1
"key_exchange": {
0000: 04 64 F2 B7 51 E2 D6 1B 11 00 7D 59 58 62 90 3E .d..Q......YXb.>
0010: 03 8F 7C 16 92 D7 EA 81 D3 D1 3C 58 4E 4F 29 20 ..........<XNO)
0020: 1B 49 EA AD 84 D1 B6 60 77 77 77 90 60 C5 50 98 .I.....`www.`.P.
0030: 50 CC 48 D3 8E 12 B6 11 A3 AE 43 24 7F 66 AE 9B P.H.......C$.f..
0040: EB
}
},
]
}
]
}
)
javax.net.ssl|FINE|01|main|2024-07-07 10:26:02.678 CST|ServerHello.java:863|Consuming ServerHello handshake message (
"ServerHello": {
"server version" : "TLSv1.2",
"random" : "D4 8E 8D 8D D9 07 97 2B 7E 17 55 36 14 D3 14 9D 77 20 55 13 67 0E F1 61 B9 AA 1F 49 3D B6 A4 07",
"session id" : "4E EE F7 CA B5 B1 AB C9 7D 79 0B 9E AC 21 84 1D EE C7 E8 66 C7 E3 D9 F3 DC 61 79 FF 7D 59 05 72",
"cipher suite" : "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030)",
"compression methods" : "00",
"extensions" : [
"renegotiation_info (65,281)": {
"renegotiated connection": [<no renegotiated connection>]
},
"server_name (0)": {
<empty extension_data field>
},
"ec_point_formats (11)": {
"formats": [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2]
},
"extended_master_secret (23)": {
<empty>
}
]
}
)两者对比可以发现，服务端选择了TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384加密套件，正常请求是有这个套件的，而失败的请求是没有这个套件的；
解释一下这个加密套件：TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 是一个提供强安全性的加密套件，它结合了ECDHE密钥交换的前向安全性、RSA的广泛接受度、AES_256_GCM的高效加密和认证能力以及SHA384的强哈希功能。这种套件通常用于需要高安全性的通信，例如金融服务、政府通信或其他敏感数据传输。
-
ECDHE: 椭圆曲线Diffie-Hellman密钥交换（Elliptic Curve Diffie-Hellman Ephemeral）。这是一种密钥交换机制，使用椭圆曲线加密算法来生成一个临时的共享密钥，用于加密会话密钥。
可以简单理解，这是个ECC的椭圆机密曲线，那有没有可能就是因为项目的某些配置导致ECC椭圆加密曲线缺失了；
我本人对这个方面的研究不深，到达了我的知识盲区，刚好身边有个博士做过这方面的研究，他所在的团队实现了TLS1.3的一个版本，对这个非常熟悉，请他看了一下日志，可以判断，也是缺少椭圆曲线；
既然大概确定是缺少某些东西导致调用报错，那就想办法把原因找出来；
经过了一天的努力，终于发现了问题所在，之前有个哥们不知道因为什么原因，把SUN公司的ECC曲线都删掉了，导致了问题；
现在公布这个罪魁祸首：
static {
Security.removeProvider("SunEC");
}问了KIMI，它的回答是这样的：
在Java中，Security 类是 java.security 包的一部分，它提供了一些管理安全属性和访问安全服务的方法。Security 类中的 removeProvider 方法用于从安全框架中移除一个已经注册的提供者。这里的 "SunEC" 是一个提供者的名称，它代表Sun公司提供的椭圆曲线加密（ECC）服务。
椭圆曲线加密是一种基于椭圆曲线数学的公钥密码体系，它在TLS握手中用于密钥交换和数字签名等操作。在TLS握手过程中，如果客户端和服务器都支持ECC，它们可能会选择使用基于ECC的加密套件来进行通信，因为它们通常提供与RSA相比更高的安全性，并且密钥尺寸更小。
当你执行 Security.removeProvider("SunEC") 这行代码时，你告诉Java安全框架不再使用 "SunEC" 提供者的服务。这可能导致以下问题：
移除关键加密服务:
如果"SunEC"提供者是用于TLS握手中ECC相关操作的唯一提供者，那么移除它可能会导致Java虚拟机无法使用ECC加密套件，这可能违反了客户端和服务器之间的安全协议。
TLS握手失败:
如果客户端尝试使用ECC加密套件与服务器进行握手，但服务器期望使用"SunEC"提供者支持的特定加密算法，而该提供者已被移除，这可能导致握手失败。
兼容性问题:
某些TLS库或服务器可能特别依赖于特定的加密提供者。移除"SunEC"可能会影响到这些库或服务器的兼容性。
安全漏洞:
如果你的应用程序依赖于ECC提供的安全性，移除"SunEC"提供者可能会降低安全性，使应用程序容易受到某些类型的攻击。
配置错误:
如果"SunEC"提供者被用于支持某些特定的业务逻辑或安全策略，移除它可能会导致应用程序行为不符合预期。
要解决这个问题，你可以考虑以下步骤：
审查代码:
检查为什么需要移除"SunEC"提供者，是否有其他方式可以实现相同的目标，而不需要移除整个提供者。
错误日志:
查看TLS握手失败的错误日志，了解具体是哪个步骤失败了，以及是否与ECC相关。
恢复提供者:
如果确定移除"SunEC"是导致问题的原因，尝试恢复它，看看是否能解决问题。
更新依赖:
如果你的应用程序依赖于特定的加密库或版本，确保这些依赖是最新的，并且与你的Java版本兼容。
联系服务提供者:
如果问题依然存在，可能需要联系服务提供者或寻求专业的技术支持。
在处理这类问题时，重要的是要理解你的应用程序对特定加密服务的依赖程度，以及这些服务如何与TLS握手过程相互作用。接下来的工作就是看要不要删除这行代码，删除之后会不会对以前的功能有影响，需要回归测试。
这个问题困扰了我好久，感觉http、https吃得不透啊，需要去看一下《TCP/IP详解》这种经典了。
原文地址：https://blog.csdn.net/u010843422/article/details/140242431
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！