為什麼 TLS 做 Authenticate-then-Encrypt 而不是 Encrypt-then-Authenticate？
與 Authenticate-then-Encrypt (AtE) 相比，Encrypt-then-Authenticate (EtA) 通常被認為是更好的選擇（例如，請參閱此Crypto.SE問題）。為 TLS 1.2 編寫 RFC 的人似乎已經意識到這一點，但無論如何都選擇使用 AtE。
這是有原因的嗎？這是“有人在某個時候標準化了某些東西，現在我們為了向後兼容而堅持使用它，即使我們知道它很糟糕”的情況，還是有充分的理由說明 AtE 更適合 TLS？
澄清一下，因為這最初寫得不是很好：我指的是握手完成後的實際加密通道。很明顯，您必須先對伺服器進行身份驗證並執行密鑰交換，然後才能執行任何有用的加密形式。
SSL 是很久以前設計的，當時 encrypt-then-MAC 還沒有那麼流行。即使是 2008 年發布的 TLS 1.2，到現在也已經很老了，雖然當時首選 encrypt-then-MAC，但長期以來實際風險被低估了。Padding oracles 攻擊在 2010 年的幾次高調攻擊之後變得眾所周知。
使用流密碼，MAC-then-encrypt 是安全且易於正確實施的。使用 CBC 會比較棘手，但從技術上講，如果您確保攻擊者不了解任何有關檢測到的操作的原因（無效填充與不正確的 MAC 等），那麼它在 TLS 中的使用方式在技術上是安全的。
MAC-then-encrypt 的選擇導致了 SSL 和 TLS 歷史上的幾個弱點，包括 POODLE 和 Lucky 13。
- Lucky 13是一種定時攻擊，它向攻擊者提供有關解密失敗原因的資訊，從而使證明無效。
- POODLE是針對 SSL 3.0（以及一些粗心的 TLS 實現）的攻擊，它沒有新版本的 TLS 那樣嚴格的填充驗證要求。
為了應對這些攻擊，TLS 實現被仔細編寫以避免側通道攻擊，解決了這些弱點。
有一個 TLS 擴展草案（用於 TLS 的 Encrypt-then-MAC 和 DTLS Draft-gutmann-tls-encrypt-then-mac）來使用 encrypt-then-MAC，但它並沒有獲得太大的吸引力並且仍然沒有敲定。
TLS 1.3 將僅支持AEAD套件，其中每個套件負責確保機密性和真實性，而不是在協議級別結合 MAC 和加密。所以在 TLS 1.3 中這個問題最終會得到解決。