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详解》这种经典了。