HTTPSCipherSuite問題-創(chuàng)新互聯(lián)

背景

服務(wù)器是Windows server 2012 R2, 之前掃出安全問題，并提供解決方案

創(chuàng)新互聯(lián)是專業(yè)的博望網(wǎng)站建設(shè)公司，博望接單;提供網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè),網(wǎng)頁(yè)設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行博望網(wǎng)站開發(fā)網(wǎng)頁(yè)制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!

TLS/SSL Server Is Using Commonly Used Prime Numbers

The server is using a common or default prime number as a parameter during the Diffie-Hellman key exchange. This makes the secure session vulnerable to a precomputation attack. An attacker can spend a significant amount of time to generate a lookup/rainbow table for a particular prime number. This lookup table can then be used to obtain the shared secret for the handshake and decrypt the session.

Generate random Diffie-Hellman parameters
Configure the server to use a randomly generated Diffie-Hellman group. It's recommend that you generate a 2048-bit group. The simplest way of generating a new group is to use OpenSSL:
openssl dhparam -out dhparams.pem 2048
To use the DH parameters in newer versions of Apache (2.4.8 and newer) and OpenSSL 1.0.2 or later, you can directly specify your DH params file as follows:
SSLOpenSSLConfCmd DHParameters "{path to dhparams.pem}"
If you are using Apache with LibreSSL, or Apache 2.4.7 and OpenSSL 0.9.8a or later, you can append the DHparams you generated earlier to the end of your certificate file and reload the configuration.
For other products see  the remediation steps suggested by the original researchers. (https://weakdh.org/sysadmin.html)

簡(jiǎn)單來說就是Client和Server進(jìn)行key交換的時(shí)候用的DH算法并不安全。
那么怎么辦呢，就是給Server端指定一些安全的Cipher Suites，我們的app部署在Tomcat上，自然按照指導(dǎo)（https://weakdh.org/sysadmin.html）配置Tomcat:

問題

我們把這些Cipher Suites格式話看一下：

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,
==================================
TLS_ECDHE_RSA_WITH_AES_128_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_SHA,
TLS_ECDHE_RSA_WITH_AES_256_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_256_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_SHA,
TLS_ECDHE_ECDSA_WITH_AES_256_SHA,
TLS_DHE_RSA_WITH_AES_128_SHA256,
TLS_DHE_RSA_WITH_AES_128_SHA,
TLS_DHE_DSS_WITH_AES_128_SHA256,
TLS_DHE_RSA_WITH_AES_256_SHA256,
TLS_DHE_DSS_WITH_AES_256_SHA,
TLS_DHE_RSA_WITH_AES_256_SHA

前6個(gè)還好說，后面這個(gè)suite是個(gè)啥，JDK8，甚至JDK7都沒有這些，Windows本身也沒有這些名稱的suite。
JDK8：https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SupportedCipherSuites
JDK7: https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SupportedCipherSuites

Windows:
https://docs.microsoft.com/en-us/windows/win32/secauthn/cipher-suites-in-schannel
https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-8-1

后來我絞盡腦汁，各種檢索，終于猜出這些suites可能是為了兼容更早(老舊)的應(yīng)用（瀏覽器，JDK,OPENSSL等）所為，可以參考：https://ssl-config.mozilla.org/#server=tomcat&version=9.0.30&config=old&guideline=5.6
所以現(xiàn)在2021年底了，TLS1.3部分應(yīng)用，TLS1.2普遍應(yīng)用，SSL3徹底淘汰，這個(gè)“權(quán)威”文章不用更新的嗎？或者做一些說明？

這個(gè)疑惑解決之后，我們?cè)倏辞皫讉€(gè)Cipher Suites, 通過網(wǎng)絡(luò)抓包，我們發(fā)現(xiàn)在握手階段，Client Hello的時(shí)候，客戶端會(huì)帶著一些Suites去和Server協(xié)商，但是有2兩個(gè)Suites明明帶著，服務(wù)端也支持，卻無法建立連接。
我們以0xC02B這個(gè)Suite舉例，我們?cè)赥omcat里配置，只支持該Suite，客戶端請(qǐng)求中也帶著該Suite，但是無法建立連接。

而，當(dāng)我們?cè)赥omat中配置，只支持0xC02B這個(gè)suite(圖片中的第一個(gè))的時(shí)候，就可以正確建立連接了。
為什么？

知識(shí)不夠就經(jīng)過一番搜索+學(xué)習(xí)+串聯(lián)+想象
首先，明白這些cipher suite的命名規(guī)范，具體可以看這里：https://wiki.mozilla.org/Security/Cipher_Suites
我們可以看到suite名稱由多部分組成，協(xié)商確定某個(gè)suite之后，每一部分的算法都用于不同階段