HMAC 是 TLS/SSL 過程的一部分嗎？
HMAC 是否參與 TLS/SSL？當客戶端和伺服器通過 TLS 握手並創建一個通用的 SESSION 密鑰時，它們是否也會對發送出去的每條消息進行 HMAC 以確保數據完整性？
現代版本的 TLS（帶有現代密碼套件的TLS 1.2 ， TLS 1.3）不使用 HMAC 來保護每條消息的完整性或真實性1。它們使用專用的**身份驗證加密(AEAD)**原語，例如GCM或CCM模式下的分組密碼（例如 AES），或ChaCha20+Poly1305。CCM 使用分組密碼來保證完整性和機密性。GCM 和 Poly1305 使用不同的結構，既不基於塊密碼也不基於散列。
可以使用 HMAC 建構經過身份驗證的加密，這就是 TLS 最高 1.2 的版本所做的，使用流密碼 (RC4) 或 CBC 模式下的塊密碼以確保機密性。這些方法是有問題的並且已被棄用（我不會在這裡詳細介紹，查找 2000 年代和 2010 年代針對 TLS 的攻擊，例如 BEAST、POODLE、幸運十三等）。問題來自保密方面，而不是來自 HMAC。HMAC 本身非常健壯，但是將身份驗證原語和機密性原語結合起來很棘手。標準 AEAD 結構不使用 HMAC 的主要原因是它比標準結構慢，並且不需要 HMAC 的強韌性。
HMAC 在現代 TLS 的某些地方使用，只是不是為了正常消息的完整性或真實性。在 TLS 1.3 中，它用於握手的完整性。（舊版本的 TLS 只是在那裡使用散列。散列已經足夠了，但 HMAC 更健壯，以防在散列函式中發現不太可能的弱點。） HMAC 也用於派生密鑰和其他加密材料，而不是因為它的真實性或完整性屬性，但由於使用標準加密散列函式，HMAC 是一個非常健壯的偽隨機函式。TLS 1.0/1.1、TLS 1.2 和 TLS 1.3 使用略有不同的結構，均基於 HMAC。
1 完整性：防止修改。身份驗證：允許驗證消息的來源。HMAC 可以保證兩者。完整性保證通常在通信協議中沒有用：完整性意味著接收者會將 HMAC 與先前已知的值進行比較，但接收者沒有先前已知的值可以比較。消息的接收者通過檢查 MAC 或身份驗證標籤是否正確來驗證其真實性。由於消息是真實的，它必須是對話的一部分，但它可能是亂序的，或者被重新發送。因此，為了驗證會話的完整性，每條消息都包含一個數字（第一條消息為 0，第二條消息為 1，等等），這是受真實性保護的數據的一部分，並且接收者驗證它在正確的順序。
是的，沒有。
HMAC 用於在 TLS 1.2 和更早版本的密碼套件中創建身份驗證標籤，其中包含未經身份驗證的密碼，例如 CBC 模式或 RC4 中的密碼。
對於其他密碼套件，也使用 HMAC，但僅作為密鑰派生機制的一部分，該機制從主密鑰（由密鑰建立創建，例如通過使用 RSA 加密或臨時 Diffie-Hellman（DHE / ECDHE ). 在這種情況下，HMAC 是 TLS 指定的 PRF 的一部分 - TLS 1.2 或更低版本，或 HKDF (TLS 1.3) 的一部分。它還用於驗證握手（這部分取自Gilles 回答）。
當然，如果使用經過身份驗證的密碼，那麼它也會創建一個身份驗證標籤（連接到密文），但是它會使用另一個消息身份驗證程式碼，例如用於 AES-GCM 的 GMAC 或帶有 ChaCha20/Poly1305 的 Poly1305（顯然）和 CCM 的 CBC-MAC。