SSL/TLS 中客戶端和伺服器共享的四個不同秘密的目的是什麼？
我正在查看SSL V3的工作，發現連接狀態是由一組事物定義的，包括
- 客戶端寫mac secret，
- 伺服器寫入mac秘密，
- 伺服器寫入密鑰，
- 客戶端寫入密鑰。
我在 SSL 協議中找不到這些的使用。
正如我從閱讀中了解到的，在握手之後，SSL 創建了一個 48 字節的主密鑰，用於加密，並且該密鑰由客戶端和伺服器共享。
這四個值的用途是什麼？
在TLS（這是 SSL 的標準名稱；TLS 1.2 類似於“SSL 版本 3.3”）中，客戶端和伺服器以共享密鑰（“主密鑰”，一個 48 字節序列；使用 RSA 密鑰交換時， master secret 派生自“premaster secret”，它是客戶端使用伺服器公鑰加密的 48 字節字元串）。然後，該共享秘密被“擴展”為六個值：
- “客戶端寫入密鑰”；
- “客戶寫 IV”；
- “客戶端寫入 MAC 密鑰”；
- 伺服器的三個相似值。
“擴展”使用第 5 節中描述的 PRF；它可以被認為是一個具有靈活輸出長度的散列函式。
TLS 的主要目的是為數據保密；但是，它還旨在維護數據完整性：如果某人或某事願意或不願意更改傳輸中的數據，那麼接收器必須能夠可靠地檢測到它。在許多協議中檢測更改很重要。此外，如果攻擊者可以修改數據，他通常可以手工進行精確的更改，當將其發送給對等方以代替正確的數據時，可能會導致洩露有關加密數據的資訊的反應。因此，我們不僅要為了完整性而檢測更改，而且因為不受約束的更改可能會導致機密性洩露。
所以我們需要加密（為了機密性）和完整性控制（為了支持機密性，因為完整性本身也是需要的）。這需要幾種算法，通常AES用於對稱加密部分，而HMAC用於完整性控制。HMAC 是一種消息驗證碼算法，它是一種“帶密鑰的散列函式”（HMAC 建立在真正的散列函式之上，如 SHA-256，密鑰以“正確的方式”插入）。HMAC 值由客戶端使用其“客戶端寫入 MAC 密鑰”計算並附加到記錄數據中；伺服器將重新計算 HMAC 值並查看它是否與發送的匹配。
加密部分需要一個密鑰（以及一個使用 CBC 模式的對稱加密算法的 IV，這取決於 SSL 協議版本的一些細微之處，所以我不會在這裡詳細說明）。MAC 還需要一個密鑰。**作為一般規則，根本不建議對兩種不同的算法使用相同的密鑰：**這兩種算法之間可能存在不需要的互動，這是一個不太可能但並非不可能的事件，尚未徹底研究。因此，為了安全起見，我們生成了兩個密鑰，一個用於加密，一個用於 MAC。這兩個密鑰來自主密鑰，但推導機制就像一個雜湊函式，所以即使你知道加密密鑰也無法猜測 MAC 密鑰，反之亦然。
由於 TLS 具有可以生成任意長度的輸出的密鑰派生功能（“PRF”），因此很容易強制生成兩個方向不同的加密和 MAC 密鑰（客戶端用於加密數據的密鑰 - 並且伺服器用來解密接收到的數據——不同於伺服器用來加密它發送給客戶端的數據的密鑰）。使用不同的密鑰可以避免攻擊者出現問題，否則攻擊者可以獲取客戶端發送的加密記錄的副本，並將其回饋給客戶端，就像它是從伺服器發送的一樣。使用不同的密鑰，客戶端將拒絕嘗試，因為 HMAC 值與客戶端期望的不匹配（它將是使用客戶端寫入 MAC 密鑰計算的 HMAC，而不是使用伺服器寫入 MAC 密鑰）。
有更新的對稱加密模式，它們以受控方式使用相同的密鑰進行加密和MAC，例如GCM - 並且 AES-with-GCM 可以與 TLS一起使用，儘管您可能很難找到兼容的實現（這是比較新）。