修復在 RHEL 4 上執行的 Apache 2.0 上的 BEAST 漏洞
我有一個在 RHEL4 上執行 Apache 2.0 的 Web 伺服器。此伺服器最近未能通過 PCI 掃描。
原因：SSLv3.0/TLSv1.0 協議弱 CBC 模式漏洞解決方案：此攻擊是在 2004 年發現的，隨後的 TLS 協議修訂版包含對此的修復。如果可能，請升級到 TLSv1.1 或 TLSv1.2。如果無法升級到 TLSv1.1 或 TLSv1.2，則禁用 CBC 模式密碼將消除該漏洞。在 Apache 中使用以下 SSL 配置可緩解此漏洞： SSLHonorCipherOrder On SSLCipherSuite RC4-SHA:HIGH:!ADH
簡單的修復，我想。我將這些行添加到 Apache 配置中，但它不起作用。顯然
“SSLHonorCipherOrder On”僅適用於 Apache 2.2 及更高版本。我嘗試升級 Apache，很快就遇到了依賴地獄，看來我必須升級整個作業系統才能升級到 Apache 2.2。我們將在幾個月後停用此伺服器，因此不值得。
該解決方案顯示*“如果無法升級到 TLSv1.1 或 TLSv1.2，則禁用 CBC 模式密碼將消除該漏洞。”*
我將如何在 Apache 2.0 上執行此操作？這甚至可能嗎？如果沒有，還有其他解決方法嗎？
除了手動編譯較新的 Apache，我唯一能想到的就是讓 RC4-SHA 成為唯一支持的密碼（
openssl ciphers RC4-SHA在目前的 openssl 上進行測試以確保它只列印一個密碼，你可能想要做同樣的事情以確保它與舊 openssl 上的一些奇怪的舊密碼不匹配）：SSLCipherSuite RC4-SHAMS 說 Windows XP 支持TLS_RSA_WITH_RC4_128_SHA所以你不應該有任何兼容性問題。
只有兩種方法可以在伺服器級別“修復”BEAST。
最好的選擇是將伺服器的 SSL 庫升級到支持 TLS v1.1 或更高版本的庫（並確保您的客戶端也支持它，這樣您就可以強制他們使用它）。
另一種選擇是禁用任何 CBC（密碼塊鏈）加密算法並切換到 en ECB（電子密碼本）密碼或類似 RC4 的東西（ECB 算法理論上“不太安全”，因為給定的明文輸入加密到給定密鑰總是映射回相同的密文，這使得更容易被已知的明文攻擊破解，但實際上這不太可能是一個大問題。Google（例如）仍然使用 RC4）。
由於您正在執行的伺服器已死、被掩埋並且正在分解，因此建構修補的 Apache 所需的努力可能不值得（您需要單獨重建 Apache 和 OpenSSL，以免破壞任何預設情況下需要在您的系統上安裝 OpenSSL 的版本——如果您正在做這麼多工作，您不妨將整個系統升級到實際支持的系統），因此您幾乎可以使用“切換到 ECB 密碼”作為您可行的解決方案。
如今，BEAST 真的是一種無形的攻擊——所有流行的瀏覽器（IE、Chrome、Safari、Opera）都實現了有效的解決方法，並且由於攻擊的工作方式，很難在瀏覽器之外實現（所以
apt並且yum仍然非常安全）。Google 的 Adam Langley 在今年早些時候發表了精彩的演講，概述了您應該關注的一些痛點：SSL 和安全性——雖然 BEAST 獲得了提及，但它在需要擔心的事情列表的底部附近。