哪些 TLS 功能容易受到 SHA-1 上的選擇前綴衝突的影響？
Gaëtan Leurent 和 Thomas Peyrin 的預印本From Collisions to Chosen-Prefix Collisions - Application to Full SHA-1（在即將到來的Eurocrypt 2019會議記錄的第1 卷中）顯示了對 SHA-1 的可行選擇前綴衝突攻擊。給定不同的前綴 $ P_A $ 和 $ P_B $ 長度相等，攻擊產生後綴 $ S_A $ 和 $ S_B $ 和 $ \operatorname{SHA-1}(P_A\mathbin|S_A)=\operatorname{SHA-1}(P_B\mathbin|S_B) $ . 攻擊的成本是可行的：是給定前綴的shattered的幾倍 $ P $ 產生不同的後綴 $ S_A $ 和 $ S_B $ 和 $ \operatorname{SHA-1}(P\mathbin|S_A)=\operatorname{SHA-1}(P\mathbin|S_B) $ .
哪些 TLS 功能（密碼套件、證書等）容易受到此類選擇前綴衝突攻擊？
執行摘要：
對 SHA-1 的攻擊歷史，尤其是 Marc Stevens 等人自 2012 年左右以來的攻擊歷史，使人們意識到 SHA-1 很快就會被破壞，是時候停止使用它了。這個過程在 SHA-1 完全被破壞之前就完成了，所以最新的出版物沒有發生什麼可怕的事情。
那麼讓我們回顧一下 TLS 是如何使用雜湊函式的。
- 作為 PRF 從密鑰交換中導出共享秘密值（對稱密鑰、IV、隨機數、MAC 密鑰等）。
TLS 1.1 及以下版本的PRF使用 SHA-1，但在 HMAC 中。HMAC-SHA1 不受最新中斷的影響。
- SHA-1 在 HMAC-SHA1 中用作 TLS 記錄協議的 MAC，在使用 HMAC 的密碼套件（即名稱以“_SHA”結尾的密碼套件）中。
HMAC-SHA1 不受 SHA-1 新中斷的影響，因此那些密碼套件不受影響。無論如何你都不應該使用它們，因為它是 MAC-then-Encrypt 並且在野外有許多糟糕的實現（很多Lucky13 變體，很多 POODLE 變體）。
- SHA-1 可用於頒發葉證書和中間證書。
SHA-1 證書已經有幾年不允許使用了（葉證書和中間證書）。當時，Facebook、Cloudflare 和賽門鐵克為 SHA-1 證書而戰，前兩個是因為他們看到了一些來自僅支持 SHA-1 證書的客戶的流量，而後者是因為他們有願意為這些證書支付大量費用的客戶此類證書可支持無法修補以啟用 SHA-256 證書的舊硬體。一些 CA 在截止日期後被抓到頒發 SHA-1 證書並受到瀏覽器的懲罰。現在這都是舊聞了。
眾所周知，SHA-1 很弱，以至於 Web PKI TLS 生態系統不受影響。
我想如果使用 TLS 的私有 PKI 不遵循 Web PKI、CA/瀏覽器論壇基線要求、Chrome 安全性（作為最大的瀏覽器，當他們棄用它已經死的東西）等實施的最佳實踐，它們就會受到影響。
- SHA-1 可用於身份驗證、簽署握手密鑰共享消息 ServerKeyExchange（DHE 和 ECDHE 密碼套件）和 CertificateVerify（僅與客戶端證書一起使用）。
在 ServerKeyExchange 消息上執行 SHA-1 簽名的 TLS 伺服器和使用客戶端證書的 TLS 客戶端使用證書的密鑰在 CertificateVerify 消息中執行 SHA-1 簽名可能容易受到攻擊（我想這些幾乎完全是 RSA-SHA1 簽名，儘管我想其他種類也可以使用）。
我的印像是 TLS 伺服器本身生成的 SHA-1 簽名也是不允許的，但現在我看到 TLS RFC 沒有這麼說，並且有一個更改 RFC 的提議。
Chrome在 2016 年取消了對 ECDSA-SHA1 簽名的支持。
Google表示他們真的希望伺服器支持 SHA-256 或 SHA-512 來簽署 ServerKeyExchange（Chrome 可能會將不支持“現代 TLS”的伺服器視為不安全），但我猜 Chrome 還不需要它，所以現有的 TLS 1.2 伺服器可能使用 SHA-1 簽署 ServerKeyExchange。我認為目前對 SHA-1 的攻擊不會讓你對此做任何事情（它是客戶端隨機、伺服器隨機和伺服器 DH 參數的簽名）。
結論：
我認為目前的攻擊只破壞了 SHA-1 CA，並且只破壞了那些頒發具有可預測序列號的證書（所有這些在一段時間內都不允許公開信任的證書）。
建議：即使不公開信任也不要使用 SHA-1 證書，不支持 TLS 握手中的 SHA-1 簽名，請改用 SHA-256 和 SHA-512。