如何在 Java 伺服器的 ssl 中禁用 112 位密碼套件
如何在 Java 應用伺服器上禁用 112 位密碼套件。具體就這幾個。
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA我已經編輯了
java.security文件並製作了jdk.tls.disabledAlgorithms=SSLv3, MD5withRSA, DH keySize < 2048，仍然列出了這些算法。我也想有降級攻擊預防（
TLS_FALLBACK_SCSV）該怎麼辦 ？
在您更改 SSL 配置之前，可能值得準確了解這裡的漏洞。
引入 3DES 時，要求它可以與傳統的單 DES 系統互操作。3DES 背後的想法是，您可以通過使用不同的密鑰執行多個 DES 操作來增加安全性。為了提供兼容性，他們使用了 EDE 結構：依次執行 3 個 DES 操作 - 加密、解密、加密 - 或簡稱 EDE。事實證明，就安全性而言，DES 解密操作基本上可以與加密操作互換，因此效果很好。當您為每個操作使用三個獨立的密鑰（稱為密鑰選項 1）時，您基本上擁有一個 168 位密鑰。如果您想回到舊的單 DES 模式，您可以使用不同的鍵控選項 (3)，它將所有三個子鍵設置為相同的值，即 k1 = k2 = k3，這樣兩個操作就會取消，實際上只有一個 DES 操作很重要。還有另一個鍵控選項，其中兩個鍵值相同但一個不同，生成一個 112 位鍵，但這在現實中並沒有真正使用，並且（有點令人困惑）與您看到 3DES 的原因完全無關報告為 112 位。
更令人困惑的是，您有時會聽到人們談論 64 位 DES 或 192 位 3DES。從加密的角度來看，這些與 56 位 DES 或 168 位 3DES 相同。DES 指定了一個密鑰填充系統，其中 8 個填充位可以添加到 56 位密鑰以生成 64 位填充密鑰。這是在一些舊系統中使用的，它並不是很重要，但是可以忽略 8 位，實際上只有 56 位是關鍵材料。在 192 位 3DES 中也會發生同樣的事情，其中每個 56 位子密鑰都用 8 個填充位填充，但真正的加密密鑰再次只有 168 位長。
現在，112 位是什麼？
3DES 遭受稱為中間相遇攻擊的問題。方法如下：
- 為要破解的給定密鑰找到已知的明文和密文塊對。
- 為所有可能的 56 位密鑰計算明文塊上的第一個加密步驟（即一次 DES 加密操作）。
- 將所有生成的 64 位塊儲存在一個大查找表中。
- 對於密鑰的每個可能剩餘的 112 位部分，對密文執行其他兩個操作（解密、加密）。
- 如果這兩個操作的結果與查找表中的任何塊匹配，則您已找到鍵。否則嘗試下一個 112 位密鑰。
這是一種時間/空間權衡，允許您將計算次數從 2 168減少到 2 112，空間成本為 2 56 64 位塊（512 PB）。
現在，出於某種奇怪的原因，所有安全工具似乎都將 3DES-EDE 報告為 112 位，但實際上並沒有說明原因。3DES-EDE 沒有 112 位的密鑰長度，它甚至沒有 112 位的有效密鑰長度，除非您指定攻擊者擁有 512PiB 的閃電般快速的儲存空間以及他們的大量 DES 破解 ASIC。將其報告為 112 位的做法似乎是從“sslscan”工具開始的，此後被各種其他工具複製，導致各種混亂和誤解（我什至在安全考試中看到這個錯誤標記！）
這並不是說您不應該禁用 3DES - 它現在是一種舊算法並且存在問題，因此可能值得放棄它。值得知道為什麼。
如果您想這樣做，請將
DESede和添加DES到您的禁用算法列表中。這些名稱在加密提供程序文件中定義，以防您想禁用任何其他名稱。