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