如何在 Java 服务器的 ssl 中禁用 112 位密码套件

Question

如何在 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）

该怎么办 ？

Answer 1

在更改 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 存在一个称为中间人攻击的问题。方法如下：

1. 为要破解的给定密钥查找已知的明文和密文块对。
2. 对所有可能的 56 位密钥在明文块上计算第一个加密步骤（即一个 DES 加密操作）。
3. 将所有生成的 64 位块存储在一个大查找表中。
4. 对于密钥的每个可能剩余的 112 位部分，对密文执行其他两个操作（解密、加密）。
5. 如果这两个操作的结果与查找表中的任何块匹配，则您已找到密钥。否则尝试下一个 112 位密钥。

这是一种时间/空间权衡，允许您将计算次数从 2 ^{168 次}减少到 2 ^{112 次}，空间成本为 2 ⁵⁶个 64 位块（512 PB）。

现在，出于某种奇怪的原因，所有安全工具似乎都将 3DES-EDE 报告为 112 位，但实际上并未说明原因。3DES-EDE 没有 112 位的密钥长度，它甚至实际上也没有 112 位的有效密钥长度，除非您指定您的攻击者拥有 512PiB 闪电般的存储空间以及他们的大量 DES 破解 ASIC。将其报告为 112 位的做法似乎始于“sslscan”工具，此后被各种其他工具复制，导致各种混淆和误解（我什至在安全考试中看到错误标记） ！）

这并不是说您不应该禁用 3DES - 它现在是一个旧算法并且存在问题，因此可能值得远离它。只是值得知道为什么。

如果您想这样做，请将DESede和添加DES到您的禁用算法列表中。这些名称在加密提供程序文档中定义，以防您想禁用任何其他名称。