SSL握手過程

Question

我開始學習安全性並閱讀有關SSL握手方案。在這個post中，回覆者提到在瀏覽器上生成對稱密鑰，使用服務器的公鑰加密併發送到服務器。

但是，在其他文章中，他們提到了一個預主祕密被生成併發送過來用於計算對稱密鑰。

我可以知道哪個是正確的解釋，以及這個預主密鑰是如何生成並用於生成對稱密鑰的？

Answer 1

鏈接到的帖子中的描述只是對協議的簡單說明。

客戶端生成預主密鑰，並使用服務器的公鑰對其進行加密，作爲握手過程的一部分。然後雙方根據RFC 6101中的方法推導出對稱密鑰材料，包括IV和MAC密鑰。

Answer 2

下面是一篇優秀文章的鏈接，描述了SSL/TLS握手（包括客戶端和服務器使用預主密鑰生成主密鑰，用於生成一組會話密鑰爲MAC和加密）：

The First Few Milliseconds of an HTTPS Connection

Answer 3

說，瀏覽器生成對稱密鑰僅僅是一個簡化的（至少比說的加密與證書完成）更好。您可能對Security.SE上的this answer感興趣：

密碼套件然後確定這些對稱密鑰最終如何共享。 SSL/TLS握手的直接目的是在客戶端和服務器之間建立一個分享預主祕密。這更廣泛地被稱爲key-exchange (see RFC 4346 Appendix F.1.1, and perhaps Section 7.4.7)。

這屬於兩個類別（不包括匿名密鑰交換）：

• RSA密鑰交換（例如TLS_RSA_WITH_AES_128_CBC_SHA）：客戶端加密使用服務器的公鑰（證書中找到的）前主祕密。
• DH（E）密鑰交換（例如TLS_DHE_RSA_WITH_AES_256_CBC_SHA）：發生Diffie-Hellman密鑰交換。服務器簽署DH參數，客戶端根據服務器證書中的公鑰驗證簽名。 （具有基於RSA的證書並不意味着是RSA密鑰交換）

在握手，使用取這兩個步驟結束後，客戶端和服務器都持有一個共同的預主祕密，從中得出主祕密（見RFC 4346 Section 8.1）。

從該主祕密，雙方可以導出加密密鑰（和MAC祕密），如RFC 4346 Section 6.3中所述。