https - 在保护 https keystore 时，WildflyVault (JCEKS) 有什么意义？

Question

我觉得我完全没有理解 Wildfly 中新的 JCEKS keystore 格式的要点。也许你可以纠正我。

我们配置 Wildfly 的方式(互联网上的大部分内容都指示我们这样做，for example):

• 我们将标准 keystore 条目放入标准 Java keystore (“keystore.jks”)文件中，并带有密码(“jks_pw”)
• 然后，我们使用密码、盐和轮数(“jceks_s_n”)创建 JCEKS keystore (“keystore.jceks”)。
• 然后我们将“pks_pw”放入“keystore.jceks”
• 然后，我们将 JCEKS 密码/等(“jceks_s_n”)以纯文本形式添加到我们的 jboss 配置(standalone.xml)中，定义一个条目
• 然后，我们将对保管库存储的 JKS 密码的引用添加到 jboss https 连接器 (standalone.xml)，如“password="${VAULT::jks::jks::1}”。

这一切到底完成了什么？？？

如果我们只使用 JKS 文件和嵌入standalone.xml 中的密码，系统容易受到以下影响:

• 攻击者获取standalone.xml 和JKS 文件的副本，在这种情况下，所有 secret 都已知晓。
• 攻击者获取 JKS 文件的副本，在这种情况下，攻击者可以使用暴力破解或查找表攻击。

如果我们按照描述的方式使用 JCEKS 容器，系统容易受到以下影响:

• (相同)攻击者获取standalone.xml(JKS/JCEKS 文件)的副本，在这种情况下，所有 secret 均已知晓。
• (相同)攻击者获取 JKS 文件的副本，在这种情况下，攻击者可以使用暴力破解或查找表攻击。

如果我们将实际的证书放入 JCEKS 文件中，这将是有意义的，在这种情况下，在第二种攻击情况下，暴力破解和查找表攻击会更困难，但到目前为止，我还没有找到直接通过 https 连接器使用 JCEKS 格式的 keystore 的方法。

真的，我太关心这个的唯一原因是我们显然有使用“保险库”的安全要求，但这似乎毫无意义。

更新:值得注意的是，通过使用保管库，您在 jboss 配置文件中使用了保管库的“屏蔽”密码，但我无法弄清楚这意味着什么。显然你的屏蔽密码+盐+轮可以解锁JCEKS keystore ( source )，所以我不确定屏蔽到底能完成什么。这似乎只是第三层重定向。我一定错过了一些东西......

Answer 1

JBoss 指出“Vault”背后的安全机制是隐匿性安全 ( https://developer.jboss.org/wiki/JBossAS7SecuringPasswords )

How secure is this?

• The default implementation of the vault utlizes a Java KeyStore. Its configuration uses Password Based Encryption, which is security by obscurity. This is not 100% security. It only gets away from the problem of clear text passwords in configuration files. There is always a weak link. (As mentallurg suggests in the comments, the keystore password is the weakest link).
• Ideally, 3rd party ISV robust implementations of Vaults should provide the necessary security.

Vault 使用未知密码和算法对 keystore 密码执行对称加密。如果没有 HSM，您将始终面临“在哪里存储数据源密码”的问题。因此，通常您会定义一个带有访问控制列表的属性文件，并将编码后的密码存储在其中。

保险库只是增加了获取安全密码的难度，让攻击者要么读取内存中的密码，要么对保险库加密算法+ key 进行逆向工程。