您不需要密码来访问信任库(使用 java keytool 创建)吗?

发布于 2024-08-23 06:39:55 字数 548 浏览 15 评论 0原文

我刚刚使用 java keytool 创建了一个信任库(用于对没有 CA 证书的服务器进行服务器身份验证)。然而我刚刚注意到一些奇怪的事情。我像这样启动我的客户端:

java -Djavax.net.ssl.trustStore=<PATHSTUFF>/client.keystore -classpath <STUFF> Client

(注意:没有指定密码)

上面的调用有效。


但是,当我尝试这样做时:

java -classpath <STUFF> Client

它不起作用。 (显然它不起作用,它需要信任库)。


我原本期望需要传递此选项(但我没有):

-Djavax.net.ssl.trustStorePassword=mypass

问题:访问信任库不需要密码吗?密码只能修改吗?密钥库怎么样?

I just created a truststore with the java keytool (for server authentication of a server that does not have a CA cert). However I just noticed something strange. I am starting my client like this:

java -Djavax.net.ssl.trustStore=<PATHSTUFF>/client.keystore -classpath <STUFF> Client

(Note: there is NOT a password specified)

The above call works.


However when I try this:

java -classpath <STUFF> Client

It does not work. (Obviously it does not work it requires the truststore).


I was expecting to need to pass in this option (but I did not):

-Djavax.net.ssl.trustStorePassword=mypass

Question: Do you not need a password to access a truststore? Is the password just for modification? What about a keystore?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

一腔孤↑勇 2024-08-30 06:39:55

密码用于保护密钥库的完整性。如果您不提供任何存储密码,您仍然可以读取密钥库的内容。命令 keytool -list 演示了此行为(使用空密码)。

The password is used to protect the integrity of a keystore. if you don't provide any store password, you can still read the contents of the keystore. The command keytool -list demonstrates this behavior (use it with an empty password).

泪痕残 2024-08-30 06:39:55

除了 pascal-thivent 的出色答案

密钥库密码有两个用途 - 如果未提供,keytool 拒绝让您用新内容替换存储的内容,例如通过删除现有或添加新的证书条目。

当然,如果您拥有使用 keytool (不是 setuid)更新密钥库文件的写入权限,您可以使用另一个不检查密码的工具来替换内容。我们知道存储及其格式无需密码即可读取,因此我们可以在那里编写我们想要的内容。

这就是验证密码的用武之地。当存储条目被写出时,提供的存储密码用于计算存储内容的摘要,如密码加盐的那样。这是一种单向哈希/摘要,因此如果没有密码,您无法验证存储内容是否已被篡改。同样,不知道密码的恶意者也无法修改存储的内容并生成由该密码生成的摘要哈希。

这就是为什么当您提供无密码时,keytool 只是警告您它无法验证存储是否未被篡改。如果您提供无效密码,或者存储被篡改,您将收到一条不同的消息:

Enter keystore password:
keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect

keytool 无法重新创建基于当前存储内容和您提供的密码的现有哈希摘要,因此密码不正确,或者密钥库已被泄露 - keytool 无法判断,但它假设您或软件读取店家知道。

请注意,虽然术语密钥库被广泛使用,但它同样指密钥库信任库。不太常见的是,密钥库通常是身份存储,包含身份及其秘密私钥,例如运行 HTTPS 的服务器所使用的。 信任库通常只包含公钥,没有私钥,因此没有秘密,但对于确定客户端信任哪些身份很重要。

In addition to pascal-thivent's excellent answer:

The keystore password has two purposes - if not supplied, keytool refuses to let you replace the contents of the store with new contents e.g. by deleting existing or adding new certificate entries.

Of course if you have write-access to update the keystore file using keytool (it's not setuid), you could replace the contents using another tool which didn't check the password. And we know that the store and its format is readable without a password, so presumably we can write what we want there.

That's where the verification password comes-in. When the store entries are written-out, the supplied store password is used to compute a digest of the store-contents, as salted by the password. This is a one-way hash/digest, so without the password, you cannot verify whether the store contents have been tampered with or not. Equally, someone malicious who does not know the password also cannot modify the store's contents and produce the digest-hash that would be produced by that password.

That's why when you supply no-password, keytool just warns you that it can't verify that the store has not been tampered with. If you provide an invalid password, or the store has been tampered with, you will get a different message:

Enter keystore password:
keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect

keytool was unable to re-create the existing hash digest based on the current store contents and the password you supplied, so either the password is incorrect, or the keystore is compromised - keytool cannot tell, but it assumes that you or the software reading the store knows.

Note that whilst the term keystore is used generally, it refers equally to keystores and truststores. Less-generally, a keystore is more often an identity store and contains identities and their secret, private keys, as used e.g. by a server running HTTPS. A truststore more often contains only public keys and no private keys, so no secrets, but is important to determine what identities a client trusts.

空袭的梦i 2024-08-30 06:39:55

默认情况下,JRE 信任存储区密码为“changeit”。如果您想使用 Java 以编程方式更改默认信任存储 (cacerts) 密码,请访问 此链接

By default, the JRE trust store password is "changeit". If you want to change the default trust store (cacerts) password programmatically using Java, then please go through this link.

沫离伤花 2024-08-30 06:39:55

你的观点是有效的。对信任库进行密码保护的决定取决于安全上下文及其运行环境。

truststore 处于访问受限的受信任环境中并且将其配置为不可修改或只读的情况下,对密码保护的需求可能会减少。如果对 truststore 进行未经授权的访问不太可能或实际上不可能,并且可以保证 truststore 的完整性,那么人们可能会选择不使用密码。

然而,了解潜在风险至关重要,例如黑客获得信任库访问权限并可以操纵它引入新证书的场景。即使在只读设置中,也可能存在漏洞,例如修改容器配置和卷替换。这样他就可以将新证书添加到信任库中。
这个新证书可以欺骗您的应用程序信任黑客设置的恶意服务器。

相反,正如其他响应中所述,保护密钥库是必须的,因为它包含私人凭证。

Your point is valid. The decision to password-protect a truststore depends on the security context and the environment in which it operates.

In scenarios where the truststore is in a trusted environment with restricted access, and it's configured as non-modifiable or read-only, the need for password protection may be diminished. If unauthorized access to the truststore is improbable or practically impossible, and the integrity of the truststore can be guaranteed, one might opt not to use a password.

However, it's crucial to understand potential risks, such as scenarios where a hacker gains access to the truststore and can manipulate it to introduce new certificates. Even in read-only setups, there may be vulnerabilities, like modifying container configurations and volume replacement. That way he can add a new certificate to the truststore.
This new certificate can trick your application into trusting a rogue server set up by the hacker.

In contrast, as described in other responses, protecting the keystore is a must as it contains private credentials.

踏月而来 2024-08-30 06:39:55

如果您不指定信任库,则会使用默认信任库。我假设您收到一个错误,您需要指定一个信任库才能信任您请求的主机?默认信任库位于 $JAVA_HOME/lib/security/jssecacerts 中。

If you do not specify a truststore, the default one is used instead. I assume, you get an error, that you'll need to specify a truststore in order to trust the host you request? The default truststore resides in $JAVA_HOME/lib/security/jssecacerts.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文