Java Applet 中开箱即用的 SSL
我目前正在尝试实现让（签名的）小程序通过 SSL 与服务器程序进行通信。 我找到了正确的咒语来为客户端、客户端的信任管理器和服务器创建密钥存储。 这允许我在客户端和服务器上创建兼容的 SSL 上下文。
然而，就目前情况而言，此设置需要管理员创建密钥存储，然后将它们分发到客户端和服务器计算机。 我想避免让人们配置系统。
那么作为后备方案，是否可以自动生成客户端密钥并使用“脑白质切除”信任管理器来创建兼容的 SSL 上下文而无需任何配置？
I'm currently attempting to implement having a (signed) applet communicate to a server program via SSL. I have found the right kind of incantations to create key stores for the client, the client's trust manager, and the server. This allows me to create compatible SSL contexts on the client and the server.
However, as it stands, this setup would require an admin to create the key stores and then distribute them to the client and server machines. I would like to avoid having to make people configure the system.
So as a fallback, is it possible to generate a client-side key automatically and use a "lobotomised" trust manager to create compatible SSL contexts without any configuration?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您正在与之通信的是您的知名服务器，并且 SSL 以某种方式让您头疼，那么您也可以考虑放弃 SSL。
SSL 的真正目的是解决与“未知”服务器通信的问题，从而解决证书和协议协商的复杂性。 如果您试图解决的问题只是将一些加密数据发送到已知服务器，那么您始终可以生成 RSA 密钥对，将公钥粘贴到 jar 中的文件中，然后使用用于发送和解释数据的无聊旧加密 API。 只是一个想法...！
更新：我应该提到，我首先假设您拥有在客户端上安装软件的可信方法。 一位评论者正确地指出，如果情况并非如此，那么以这种方式分发公钥会受到中间人攻击（MITM 会向您提供一个经过篡改的罐子，其中包含用于窃听的公钥）服务器）。 我曾假设这不是您想要防范的线程模型，并且客户端是从可信来源获得 jar 的（例如，公司的工程师在他们的系统上安装了该程序）。 如果他们通过互联网下载 jar，通过电子邮件等发送，那么您仍然需要使用 CA 颁发的证书来签署 jar，即使是在您的实际代码中，您可以使用您在 jar 中分发的公钥进行连接。
If it's your well-known server that you're communicating with, and SSL is causing you headaches in one way or another, then you might also consider the option of just ditching SSL.
SSL is really designed to solve the problem of talking to an "unknown" server, hence the complications of certificates and protocol negotiation. If the problem you're trying to solve is just sending some encrypted data to a known server, then you can always generate an RSA key pair, stick the public key in a file in the jar, and use the boring old cryptography API to send and interpret your data. Just a thought...!
Update: I should have mentioned, that I'm assuming in the first place that you have a trusted means of installing the software on your clients. A commenter has rightly pointed out that if this isn't the case, then distributing the public key this way is subject to a man-in-the-middle attack (whereby the MITM gives you a doctored jar with the public key for THEIR eavesedropping server). I had assumed that this wasn't the thread model you were trying to protect against, and that clients were being given the jar from a trusted source (e.g. an engineer from the company installs the program on their system). If they're downloading the jar over the Internet, being sent it via e-mail etc, then you'd still want to sign the jar with a CA-issued certificate, even though within your actual code, you may use the public key you distributed in the jar to connect.
我不明白。 客户端应该已经拥有可信任的根证书存储，可用于对您的服务器进行身份验证。 如果不这样做，服务器身份验证有何意义？
匿名（且已弃用）密码套件（例如“TLS_DH_anon_WITH_AES_128_CBC_SHA”）提供隐私保护。 但是，此配置容易受到中间人攻击。 在某些内部网络上，它可能是安全的，但一般来说，需要应用层的一些复杂的互锁协议来进行身份验证。
更新以回应评论：如果组织使用来自知名认证机构的服务器证书（即内置密钥存储中包含的证书），则他们不必担心分配本身。 （尽管，在高安全性应用程序中，一些组织确实采取了额外的步骤来验证这些证书的完整性。）如果他们没有获得“真实”证书（可能使用自签名证书），那么为了为了安全性，组织必须提供某种带外机制来分发证书并确保其不被更改。
I don't understand. The client should already have a store of trusted root certificates that they can use to authenticate your server. If they don't, what's the point of server authentication?
An anonymous (and deprecated) cipher suite, like
"TLS_DH_anon_WITH_AES_128_CBC_SHA", provides privacy. However, this configuration is vulnerable to man-in-the-middle attacks. On some internal networks, it might be secure, but in general, some sophisticated interlock protocol at the application layer would be needed for authentication.Update to respond to comment: If an organization uses a server certificate from a well-known certifying authority (that is, one included in the built-in key store), they don't have to take care of distribution themselves. (Although, in a high-security application, some organizations do take extra steps to verify the integrity of these certificates.) If they don't get a "real" certificate—perhaps using a self-signed cert—then for the sake of security the organization must provide some out-of-band mechanism to distribute the certificate and ensure that it has not been altered.