1. 從握手到握手為什么RSA和ECDHE總是成對(duì)出現(xiàn)如果你寫(xiě)過(guò)網(wǎng)絡(luò)通信程序或者配置過(guò)HTTPS服務(wù)器大概率見(jiàn)過(guò)這兩個(gè)名字RSA和ECDHE。它們常常在TLS/SSL的配置項(xiàng)里肩并肩出現(xiàn)比如TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384這樣的密碼套件。新手可能會(huì)疑惑為什么需要兩個(gè)算法一個(gè)用來(lái)加密不就行了嗎這背后其實(shí)隱藏著現(xiàn)代安全通信設(shè)計(jì)的一個(gè)核心思想前向保密。簡(jiǎn)單來(lái)說(shuō)就算你今天通信用的密鑰被泄露了攻擊者也無(wú)法解密你過(guò)去已經(jīng)發(fā)生的通信記錄。這個(gè)聽(tīng)起來(lái)有點(diǎn)“魔法”的特性正是RSA和ECDHE這對(duì)組合拳打出來(lái)的效果。RSA這個(gè)以三位發(fā)明者姓氏首字母命名的算法自1977年誕生以來(lái)一直是公鑰密碼學(xué)的基石。它的核心原理基于大數(shù)分解的困難性你可以用它來(lái)加密數(shù)據(jù)也可以用來(lái)進(jìn)行數(shù)字簽名。在早期的TLS如TLS 1.0, 1.1中RSA常常身兼兩職既用于身份認(rèn)證服務(wù)器用私鑰簽名證書(shū)又用于密鑰交換客戶端用服務(wù)器的RSA公鑰加密一個(gè)隨機(jī)生成的“預(yù)主密鑰”。這種模式簡(jiǎn)單直接但有一個(gè)致命缺陷如果服務(wù)器的RSA私鑰不幸泄露那么攻擊者就可以用它解密所有被截獲的通信流量中的“預(yù)主密鑰”從而解密全部歷史會(huì)話。這就像你把家里所有房間的鑰匙都藏在了門(mén)口一個(gè)固定的花盆底下一旦這個(gè)藏匿點(diǎn)被發(fā)現(xiàn)所有房間都失守了。而ECDHE全稱是橢圓曲線迪菲-赫爾曼密鑰交換它是經(jīng)典迪菲-赫爾曼DH密鑰交換的橢圓曲線版本。它的核心作用不是加密或簽名而是讓通信雙方在不安全的信道上安全地“協(xié)商”出一個(gè)只有他們倆知道的共享秘密。這個(gè)秘密隨后會(huì)被用作生成會(huì)話加密密鑰的“種子”。ECDHE的精妙之處在于每次會(huì)話協(xié)商出的共享秘密都是獨(dú)立的、臨時(shí)的。即便服務(wù)器的長(zhǎng)期私鑰比如RSA私鑰泄露攻擊者也無(wú)法倒推出過(guò)去某次會(huì)話中由ECDHE臨時(shí)協(xié)商出的那個(gè)共享秘密。這就好比每次見(jiàn)面雙方都現(xiàn)場(chǎng)隨機(jī)生成一個(gè)只有本次對(duì)話能用的密碼本用完即焚。之前的密碼本跟這次的毫無(wú)關(guān)系。所以在現(xiàn)代TLS如TLS 1.2, 1.3中RSA和ECDHE的分工就非常明確了RSA主要承擔(dān)身份認(rèn)證的職責(zé)在證書(shū)簽名鏈中證明“我是我”而ECDHE則專職負(fù)責(zé)實(shí)現(xiàn)前向保密的密鑰交換。它們各司其職共同構(gòu)筑了安全通信的雙重保障。接下來(lái)我們就深入這兩個(gè)算法的內(nèi)部看看它們具體是如何工作的以及在實(shí)踐中我們?cè)撊绾握_地使用和配置它們。2. RSA算法深度拆解不只是加密很多人對(duì)RSA的第一印象是“非對(duì)稱加密算法”用它來(lái)加密小段數(shù)據(jù)。這沒(méi)錯(cuò)但它在TLS世界里的首要角色其實(shí)是數(shù)字簽名和身份認(rèn)證。理解這一點(diǎn)是理解整個(gè)公鑰基礎(chǔ)設(shè)施PKI的關(guān)鍵。2.1 核心原理大數(shù)分解難題與模冪運(yùn)算RSA的安全性建立在一個(gè)數(shù)學(xué)假設(shè)上將兩個(gè)大質(zhì)數(shù)相乘很容易但將它們的乘積一個(gè)非常大的合數(shù)分解回原來(lái)的兩個(gè)質(zhì)數(shù)極其困難。這個(gè)“困難”是計(jì)算復(fù)雜度意義上的以目前計(jì)算機(jī)的能力分解一個(gè)2048位約617位十進(jìn)制數(shù)的RSA模數(shù)需要耗費(fèi)天文數(shù)字的時(shí)間和資源。整個(gè)RSA的運(yùn)作圍繞三個(gè)核心數(shù)字模數(shù)n、公鑰指數(shù)e和私鑰指數(shù)d。密鑰生成隨機(jī)選擇兩個(gè)非常大的質(zhì)數(shù)p和q計(jì)算n p * q。再計(jì)算歐拉函數(shù)φ(n) (p-1)*(q-1)。選擇一個(gè)與φ(n)互質(zhì)的小整數(shù)作為公鑰指數(shù)e通常就是655370x10001因?yàn)樗M(jìn)制表示中只有兩個(gè)1能優(yōu)化加密運(yùn)算速度。接著計(jì)算私鑰指數(shù)d使得(d * e) mod φ(n) 1。至此公鑰就是(n, e)私鑰就是(n, d)。p和q必須被徹底銷毀。加密與解密加密過(guò)程是密文c 明文m^e mod n。解密則是明文m 密文c^d mod n。這里要求明文m必須小于模數(shù)n。簽名與驗(yàn)簽這才是RSA在TLS中的主要用法。簽名過(guò)程是簽名s 消息摘要H(m)^d mod n用私鑰對(duì)消息的哈希值進(jìn)行“解密”操作。驗(yàn)簽過(guò)程是計(jì)算H(m) 簽名s^e mod n用公鑰對(duì)簽名進(jìn)行“加密”操作然后對(duì)比H(m)與自己計(jì)算的H(m)是否一致。注意直接使用RSA加密大段數(shù)據(jù)如圖片、文件是不正確且低效的。實(shí)踐中RSA通常用于加密一個(gè)對(duì)稱密鑰如AES密鑰或者如上面所述用于數(shù)字簽名。這就是“混合加密”體系。2.2 在TLS握手中的應(yīng)用與潛在風(fēng)險(xiǎn)在支持RSA密鑰交換的舊式密碼套件如TLS_RSA_WITH_AES_128_CBC_SHA中流程是這樣的客戶端發(fā)送ClientHello。服務(wù)器回復(fù)ServerHello、證書(shū)其中包含RSA公鑰和ServerHelloDone?？蛻舳蓑?yàn)證證書(shū)后生成一個(gè)隨機(jī)數(shù)作為“預(yù)主密鑰”用證書(shū)中的RSA公鑰加密它發(fā)送給服務(wù)器。服務(wù)器用RSA私鑰解密得到“預(yù)主密鑰”。雙方用這個(gè)“預(yù)主密鑰”推導(dǎo)出相同的會(huì)話密鑰。這個(gè)流程的風(fēng)險(xiǎn)我們之前提過(guò)缺乏前向保密。因此現(xiàn)代安全實(shí)踐已經(jīng)明確棄用了這種純RSA密鑰交換方式。在TLS 1.3中RSA密鑰交換已被徹底移除。那么RSA現(xiàn)在用來(lái)干嘛簽名。在ECDHE_RSA套件中服務(wù)器在發(fā)送證書(shū)證明身份后還會(huì)發(fā)送一個(gè)由ECDHE算法生成的臨時(shí)公鑰參數(shù)。在密鑰交換完成后服務(wù)器會(huì)使用自己的RSA私鑰對(duì)到目前為止所有的握手消息進(jìn)行簽名生成一個(gè)ServerKeyExchange簽名在TLS 1.3中機(jī)制不同但核心仍是簽名。客戶端用證書(shū)中的RSA公鑰驗(yàn)證這個(gè)簽名。只有驗(yàn)證通過(guò)才確信剛才收到的ECDHE臨時(shí)公鑰確實(shí)來(lái)自持有證書(shū)私鑰的合法服務(wù)器而非中間人。所以RSA從“密鑰交換的執(zhí)行者”變成了“密鑰交換的見(jiàn)證者和擔(dān)保人”。它的私鑰依然至關(guān)重要泄露了意味著身份可以被冒用但由于不直接參與密鑰生成歷史會(huì)話內(nèi)容依然是安全的。2.3 密鑰長(zhǎng)度選擇與性能考量RSA密鑰的長(zhǎng)度直接關(guān)系到安全性。隨著計(jì)算能力的提升密鑰長(zhǎng)度也在不斷升級(jí)。1024位已被認(rèn)為不安全應(yīng)堅(jiān)決棄用。2048位當(dāng)前Web服務(wù)、代碼簽名等場(chǎng)景的最低安全要求和普遍選擇預(yù)計(jì)安全期到2030年左右。3072位更高安全級(jí)別的選擇適用于需要長(zhǎng)期保密的數(shù)據(jù)。4096位目前個(gè)人或企業(yè)CA簽發(fā)根證書(shū)、中間證書(shū)的常見(jiàn)選擇用于提供更長(zhǎng)的安全有效期。密鑰長(zhǎng)度增加帶來(lái)的直接問(wèn)題是性能開(kāi)銷。RSA的運(yùn)算特別是私鑰操作是CPU密集型的。長(zhǎng)度從2048位提升到4096位私鑰解密或簽名的速度可能會(huì)慢4-8倍。因此對(duì)于高性能TLS終端如網(wǎng)關(guān)、負(fù)載均衡器需要在安全性和性能之間權(quán)衡。一種常見(jiàn)的優(yōu)化架構(gòu)是使用ECDSA證書(shū)基于橢圓曲線簽名更快更短來(lái)代替RSA證書(shū)進(jìn)行握手簽名從而徹底擺脫RSA的性能瓶頸。3. ECDHE算法詳解前向保密的引擎如果說(shuō)RSA是靜態(tài)的、用于證明身份的“公章”那么ECDHE就是動(dòng)態(tài)的、用于生成會(huì)話密鑰的“一次性密碼機(jī)”。它是實(shí)現(xiàn)前向保密PFS的關(guān)鍵技術(shù)。3.1 從迪菲-赫爾曼到橢圓曲線效率的飛躍經(jīng)典的迪菲-赫爾曼密鑰交換基于離散對(duì)數(shù)難題。在整數(shù)模乘群中給定素?cái)?shù)p、生成元g以及A g^a mod p和B g^b mod p計(jì)算共享秘密s B^a mod p A^b mod p g^(ab) mod p很容易。但僅從公開(kāi)的p, g, A, B倒推出秘密的a或b即求解離散對(duì)數(shù)則非常困難。ECDHE將這套機(jī)制搬到了橢圓曲線的代數(shù)結(jié)構(gòu)上。橢圓曲線密碼學(xué)ECC的優(yōu)勢(shì)在于它能在更短的密鑰長(zhǎng)度下提供與RSA相當(dāng)甚至更高的安全性。例如一個(gè)256位的橢圓曲線密鑰對(duì)應(yīng)于ECDHE中的曲線參數(shù)其安全性大致相當(dāng)于一個(gè)3072位的RSA密鑰。更短的密鑰意味著更小的計(jì)算量、更快的速度和更少的網(wǎng)絡(luò)傳輸開(kāi)銷。在橢圓曲線上我們定義了一種特殊的“點(diǎn)加”和“點(diǎn)乘”運(yùn)算。私鑰是一個(gè)隨機(jī)整數(shù)d公鑰是基點(diǎn)G乘以d次得到的點(diǎn)Q d * G。這里的“點(diǎn)乘”相當(dāng)于整數(shù)域中的指數(shù)運(yùn)算但逆向運(yùn)算從Q和G求d即橢圓曲線離散對(duì)數(shù)問(wèn)題ECDLP被公認(rèn)在當(dāng)前條件下是計(jì)算不可行的。3.2 ECDHE在TLS握手中的工作流程以TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384套件為例一次簡(jiǎn)化版的握手如下ClientHello客戶端發(fā)送支持的密碼套件列表、隨機(jī)數(shù)ClientRandom以及支持的橢圓曲線列表和點(diǎn)格式列表。ServerHello服務(wù)器選擇一套密碼套件如上述ECDHE_RSA套件生成隨機(jī)數(shù)ServerRandom并選擇一條橢圓曲線如secp256r1又稱P-256。Certificate服務(wù)器發(fā)送其證書(shū)鏈其中包含用于簽名的RSA公鑰。ServerKeyExchange在TLS 1.2及之前這是ECDHE的核心步驟。服務(wù)器生成一個(gè)臨時(shí)的ECDHE私鑰server_ecdhe_priv一個(gè)隨機(jī)數(shù)并計(jì)算出對(duì)應(yīng)的臨時(shí)公鑰server_ecdhe_pub server_ecdhe_priv * G。然后服務(wù)器用其RSA私鑰對(duì)這個(gè)臨時(shí)公鑰參數(shù)以及之前兩個(gè)隨機(jī)數(shù)進(jìn)行簽名將臨時(shí)公鑰和簽名一并發(fā)送給客戶端。ClientKeyExchange客戶端驗(yàn)證服務(wù)器證書(shū)和簽名。驗(yàn)證通過(guò)后客戶端自己也生成一個(gè)臨時(shí)的ECDHE私鑰client_ecdhe_priv和公鑰client_ecdhe_pub?？蛻舳擞?jì)算共享秘密shared_secret client_ecdhe_priv * server_ecdhe_pub。在數(shù)學(xué)上這等于client_ecdhe_priv * (server_ecdhe_priv * G) server_ecdhe_priv * (client_ecdhe_priv * G)。然后客戶端將client_ecdhe_pub發(fā)送給服務(wù)器。服務(wù)器計(jì)算共享秘密服務(wù)器收到client_ecdhe_pub后計(jì)算shared_secret server_ecdhe_priv * client_ecdhe_pub得到與客戶端相同的值。密鑰派生雙方使用shared_secret、ClientRandom和ServerRandom作為輸入通過(guò)TLS的密鑰派生函數(shù)如HKDF生成最終用于加密和完整性驗(yàn)證的會(huì)話密鑰。至此即使攻擊者錄下了整個(gè)握手過(guò)程并且后來(lái)攻破了服務(wù)器的RSA私鑰他依然無(wú)法計(jì)算出shared_secret因?yàn)樗麤](méi)有任何一個(gè)參與方的臨時(shí)ECDHE私鑰。前向保密得以實(shí)現(xiàn)。3.3 曲線選擇與安全考量并非所有橢圓曲線都是安全的。歷史上一些曲線存在后門(mén)或弱點(diǎn)。目前TLS推薦使用的曲線主要是secp256r1 (P-256)最常用由NIST標(biāo)準(zhǔn)化在安全性和性能上有良好平衡。secp384r1 (P-384)提供更高安全性。secp521r1 (P-521)提供最高安全性。X25519基于Curve25519的橢圓曲線Diffie-Hellman密鑰交換協(xié)議。它不是NIST標(biāo)準(zhǔn)但因其高性能、高安全性和“防誤用”設(shè)計(jì)而備受推崇在TLS 1.3中已成為優(yōu)先選項(xiàng)。在配置服務(wù)器時(shí)應(yīng)優(yōu)先使用X25519和secp256r1并禁用已知不安全的曲線如secp192r1強(qiáng)度不足以及所有“命名曲線”之外的顯式參數(shù)曲線。4. 實(shí)戰(zhàn)配置與常見(jiàn)問(wèn)題排查理解了原理最終要落地到配置和排錯(cuò)上。這里以常見(jiàn)的Nginx和Java應(yīng)用為例。4.1 Nginx中配置強(qiáng)密碼套件一個(gè)安全的Nginx SSL配置示例ssl_protocols TLSv1.2 TLSv1.3; # 禁用TLSv1.0和TLSv1.1 ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers on; ssl_ecdh_curve X25519:secp521r1:secp384r1:secp256r1; # 指定優(yōu)先的ECDHE曲線 # 證書(shū)和密鑰 ssl_certificate /path/to/your_domain.crt; ssl_certificate_key /path/to/your_domain.key;配置解讀ssl_ciphers定義了服務(wù)器支持的密碼套件列表及其優(yōu)先級(jí)。這里優(yōu)先列出了使用ECDHE進(jìn)行密鑰交換的套件同時(shí)支持ECDSA和RSA簽名并且使用GCM模式的AEAD加密算法如AES-GCM這些算法更安全高效。最后保留了DHE傳統(tǒng)DH套件作為兼容。ssl_prefer_server_ciphers on讓服務(wù)器端的套件優(yōu)先級(jí)順序生效而不是客戶端。ssl_ecdh_curve明確指定服務(wù)器用于ECDHE密鑰交換的橢圓曲線按優(yōu)先級(jí)排序。將X25519放在最前是推薦做法。你可以使用openssl s_client -connect yourdomain.com:443 -tls1_2命令來(lái)測(cè)試連接并使用nmap --script ssl-enum-ciphers -p 443 yourdomain.com來(lái)詳細(xì)查看服務(wù)器支持的套件列表。4.2 Java應(yīng)用中TLS配置的坑Java應(yīng)用特別是舊版本Java 8早期版本其默認(rèn)的TLS配置可能較弱或不支持現(xiàn)代算法。在HTTPS連接或SSLSocket編程時(shí)需要注意啟用ECDHE確保JVM支持并啟用了ECDHE相關(guān)的曲線。在Java 8及以后通常已內(nèi)置支持。但你可以通過(guò)系統(tǒng)屬性指定-Djdk.tls.namedGroupssecp256r1, secp384r1, x25519。密碼套件控制在創(chuàng)建SSLContext或SSLSocketFactory時(shí)可以顯式指定密碼套件。SSLContext sslContext SSLContext.getInstance(TLS); sslContext.init(...); SSLSocketFactory factory sslContext.getSocketFactory(); SSLSocket socket (SSLSocket) factory.createSocket(host, port); // 設(shè)置啟用的密碼套件優(yōu)先使用ECDHE String[] enabledCiphers { TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, // ... 其他套件 }; socket.setEnabledCipherSuites(enabledCiphers);證書(shū)問(wèn)題如果服務(wù)器證書(shū)是ECDSA證書(shū)但Java客戶端不支持或未配置相應(yīng)的簽名算法套件如TLS_ECDHE_ECDSA_...可能會(huì)導(dǎo)致握手失敗。需要確保客戶端密碼套件列表與服務(wù)器證書(shū)類型匹配。4.3 典型錯(cuò)誤“no shared cipher”與“handshake failure”在配置或連接過(guò)程中經(jīng)常會(huì)遇到握手失敗?！皀o shared cipher”這表示客戶端和服務(wù)器之間沒(méi)有找到共同支持的密碼套件。原因可能是服務(wù)器配置的ssl_ciphers列表過(guò)于嚴(yán)格或過(guò)時(shí)移除了所有客戶端支持的套件?？蛻舳颂貏e是老舊瀏覽器或庫(kù)不支持任何服務(wù)器端配置的現(xiàn)代套件如只支持RSA密鑰交換而服務(wù)器禁用了所有RSA密鑰交換套件。排查方法檢查服務(wù)器配置并使用SSL測(cè)試工具如SSL Labs的SSL Test掃描服務(wù)器查看其提供的套件列表。對(duì)比客戶端支持的套件列表?！癶andshake failure”這個(gè)錯(cuò)誤更通用可能發(fā)生在握手任何階段。與ECDHE/RSA相關(guān)的常見(jiàn)原因包括證書(shū)問(wèn)題服務(wù)器證書(shū)鏈不完整、過(guò)期、或域名不匹配。簽名驗(yàn)證失敗服務(wù)器在ServerKeyExchange消息中的RSA簽名驗(yàn)證失敗。可能是服務(wù)器私鑰與證書(shū)公鑰不匹配或者握手消息在傳輸中被篡改。曲線不支持客戶端不支持服務(wù)器在ServerKeyExchange中選定的橢圓曲線。例如服務(wù)器配置了X25519但老舊的Java 7客戶端不支持它。密鑰交換算法禁用在某些嚴(yán)格的安全策略下客戶端或服務(wù)器可能禁用了所有ECDHE或DHE算法導(dǎo)致無(wú)法完成密鑰交換。例如一些舊的SSLSocket實(shí)現(xiàn)默認(rèn)密碼套件列表可能不包含ECDHE。實(shí)操心得遇到TLS握手問(wèn)題最有效的調(diào)試方法是抓包分析。使用Wireshark捕獲TLS握手過(guò)程查看ClientHello和ServerHello中協(xié)商出的密碼套件、擴(kuò)展列表特別是Supported Groups擴(kuò)展即橢圓曲線列表以及ServerKeyExchange和Certificate消息的具體內(nèi)容。很多時(shí)候問(wèn)題根源一目了然。例如你可能會(huì)發(fā)現(xiàn)服務(wù)器返回的證書(shū)鏈中缺少中間CA證書(shū)或者ServerKeyExchange中的簽名算法客戶端無(wú)法識(shí)別。5. 超越TLS算法在其他場(chǎng)景下的應(yīng)用與思考RSA和ECDHE這對(duì)組合雖然因TLS而廣為人知但它們的應(yīng)用遠(yuǎn)不止于此。理解其本質(zhì)可以幫助我們?cè)谄渌I(lǐng)域做出正確選擇。5.1 SSH密鑰認(rèn)證Ed25519 vs RSA在SSH協(xié)議中我們同樣需要非對(duì)稱加密算法來(lái)進(jìn)行主機(jī)認(rèn)證和用戶認(rèn)證。過(guò)去ssh-keygen默認(rèn)生成的是RSA密鑰。但現(xiàn)在更推薦使用Ed25519算法。Ed25519基于Edwards曲線Curve25519的Edwards形式的數(shù)字簽名算法。它比RSA簽名更快、更短一個(gè)Ed25519簽名只有64字節(jié)、安全性更高128位安全強(qiáng)度相當(dāng)于~3000位RSA并且天然抗側(cè)信道攻擊。對(duì)比一個(gè)2048位的RSA私鑰文件大約1.7KB而一個(gè)Ed25519私鑰只有64字節(jié)。在頻繁的SSH連接中Ed25519的驗(yàn)證速度優(yōu)勢(shì)明顯。建議為新服務(wù)器和用戶生成SSH密鑰時(shí)優(yōu)先使用ssh-keygen -t ed25519。對(duì)于兼容舊系統(tǒng)可以額外保留一個(gè)RSA密鑰-t rsa -b 4096但應(yīng)將Ed25519作為首選。5.2 應(yīng)用程序內(nèi)的數(shù)據(jù)安全在開(kāi)發(fā)中我們有時(shí)需要在數(shù)據(jù)庫(kù)存儲(chǔ)加密數(shù)據(jù)或在API間安全傳輸信息。場(chǎng)景一加密存儲(chǔ)用戶敏感信息。絕對(duì)不要直接用RSA公鑰加密后存入數(shù)據(jù)庫(kù)。正確做法是為每條數(shù)據(jù)或每個(gè)用戶隨機(jī)生成一個(gè)AES密鑰數(shù)據(jù)加密密鑰DEK用AES加密數(shù)據(jù)。然后用一個(gè)RSA公鑰主密鑰KEK加密這個(gè)DEK將加密后的DEK和AES密文一起存儲(chǔ)。這樣要解密數(shù)據(jù)必須先有RSA私鑰解密出DEK。這符合密鑰分層管理原則。場(chǎng)景二API請(qǐng)求防篡改。可以使用RSA簽名?？蛻舳擞盟借€對(duì)請(qǐng)求參數(shù)排序后拼接的哈希值進(jìn)行簽名將簽名附在請(qǐng)求頭中。服務(wù)器用預(yù)留的客戶端公鑰驗(yàn)證簽名。這確保了請(qǐng)求的完整性和不可否認(rèn)性。注意這并不加密數(shù)據(jù)如需保密性應(yīng)結(jié)合TLS使用。5.3 關(guān)于“禁用RSA密鑰交換”的影響在一些極端安全合規(guī)要求下可能會(huì)要求禁用所有RSA密鑰交換的密碼套件。這主要影響兩類客戶端非常古老的客戶端如Windows XP上的IE6、舊版Android瀏覽器等它們可能只支持RSA密鑰交換。禁用后這些客戶端將無(wú)法連接。某些特定庫(kù)或配置的客戶端如果客戶端代碼顯式指定了只使用RSA密鑰交換套件。對(duì)于現(xiàn)代主流瀏覽器和操作系統(tǒng)支持TLS 1.2及以上它們都支持ECDHE。禁用RSA密鑰交換只會(huì)迫使它們使用更安全的ECDHE套件不會(huì)造成影響反而提升了整體安全性。在服務(wù)器配置中如Nginx的ssl_ciphers通過(guò)不包含任何RSA密鑰交換的套件即套件名中不包含RSA但包含ECDHE-RSA或ECDHE-ECDSA是允許的因?yàn)檫@里的RSA指的是簽名算法不是密鑰交換即可實(shí)現(xiàn)禁用。關(guān)鍵在于區(qū)分套件名中的RSA是指密鑰交換方式還是簽名算法。最后算法是工具安全是目標(biāo)。選擇RSA還是ECCECDHE/ECDSA選擇多長(zhǎng)的密鑰都需要在安全性、性能、兼容性三者之間取得平衡。對(duì)于絕大多數(shù)現(xiàn)代應(yīng)用采用TLS 1.2/1.3ECDHE密鑰交換 RSA 2048或ECDSA P-256簽名 AES-GCM加密是一個(gè)堅(jiān)實(shí)可靠的起點(diǎn)。持續(xù)關(guān)注密碼學(xué)進(jìn)展和漏洞公告定期更新配置才是長(zhǎng)治久安之道。在我自己維護(hù)的系統(tǒng)中我會(huì)定期用自動(dòng)化工具掃描SSL配置并設(shè)置告警確保不會(huì)因?yàn)樽C書(shū)過(guò)期或發(fā)現(xiàn)新的脆弱套件而導(dǎo)致服務(wù)中斷或安全降級(jí)。