針對 PKCS#1v1.5 的 TLS 1.3 安全性
本文解釋了對 TLS 1.3 的攻擊。這早在 2015 年 TLS RFC 處於草稿階段時就已發布。
我的問題是現在 TLS 1.3 RFC 已經完成，這種攻擊是否得到解決？
有一種加密方案稱為 RSAES-PKCS1-v1_5，簡稱 PKCS#1v1.5。有一個簽名方案稱為 RSASSA-PKCS1-v1_5，簡稱 PKCS#1v1.5。這兩種方案具有不同的安全態勢。
只要實現在功能上正確並且私鑰的使用沒有可利用的側通道洩漏，簽名方案就沒有特別的弱點。由於 Bleichenbacher，有一類針對 PKCS#1v1.5 的攻擊，但這是由於簽名驗證的實現沒有驗證他們應該驗證的所有內容。2019 年仍然存在易受攻擊的實現，但 PKCS#1v1.5 的主要實現已經安全了很長時間。
加密方案很難正確實施，因為解密容易受到填充預言攻擊。有些密文是無效的，僅僅揭示密文是否有效，即使通過非常小的時間差，也足以讓攻擊者解密任意密文。更糟糕的是，在成功解密後洩露有關明文的部分資訊也可能導致攻擊。這類攻擊也是由 Bleichenbacher 造成的（還有一類類似的攻擊，稱為 Manger 攻擊）。2018 年底掀起了一波被戲稱為“布萊肯巴赫貓的 9 條命”的披露浪潮，而且這可能不是最後一次。PKCS#1v1.5 加密非常難以正確實施和使用，而且許多聲音呼籲完全停止使用它。
最高 1.2 的 TLS 具有使用 RSA 加密的密碼套件：客戶端加密主密鑰，伺服器對其進行解密，此主密鑰成為後續通信的共享密鑰，客戶端知道它正在與正確的伺服器通信，因為只有正確的伺服器可以解密主密鑰。TLS 還具有使用 RSA 簽名的密碼套件：雙方執行未經身份驗證的密鑰協議以建立主密鑰，伺服器對握手數據進行簽名，客戶端驗證簽名以確保它正在與正確的伺服器通信。
如果伺服器願意使用使用 RSA 解密的密碼套件，並且存在允許攻擊者將伺服器用作解密預言機的漏洞，則該漏洞也可能允許攻擊者將伺服器用作簽名預言機。如果是這種情況，那麼攻擊者甚至可以冒充伺服器來攻擊拒絕使用 RSA 解密的客戶端。攻擊是這樣的：
- 客戶端開始握手。攻擊者是中間人，攔截握手包。客戶端和攻擊者同意使用基於 RSA 簽名的 TLS 密碼套件。
- 攻擊者需要對握手數據進行簽名。它與願意執行 RSA 解密的伺服器聯繫。攻擊者使用伺服器作為預言機來構造握手的簽名。
- 攻擊者將有效簽名發送給客戶端，因此客戶端認為它正在與正確的伺服器通信。
即使客戶端使用 TLS 1.3，這種攻擊也是可能的，它只有基於 RSA 簽名的密碼套件（以及使用其他簽名方案的密碼套件），而不是 RSA 加密。問題的根源在於伺服器願意使用相同的密鑰進行 RSA 解密和 RSA 簽名。
這說明了將相同的密鑰用於兩種不同的目的是一種不好的做法。協議定義不能防止這種情況（除了說“不要這樣做”，但這不是對方可以檢測到的）。