在Java中使用不加密的HTTPS
我们正在寻找一种解决方案,允许我们使用不加密的 HTTPS。为什么?故事是这样的:
我们的产品(安装在客户处)连接到我们的服务器以获取更新、发布信息等。我们希望产品在发布数据之前验证它是否已连接到服务器(而不是冒名顶替者)。我们还需要确保没有中间人攻击(即内容应该被签名等)。然而,我们的客户要求他们能够嗅探流量(Wireshark、tcpdump 等)并查看整个事务的内容。这是出于合规性和安全原因。
顺便说一句,我们的产品是用 Java 编写的。
有什么想法吗?
更新: 如果我没有使用正确的表格来回复答案,请原谅,我是这个网站的新手。
首先,感谢您的快速解答!
我们研究 HTTPS 可能性的原因是因为我们不想在这里发明一个新的协议。这不仅是工作量的问题,而且发明自己的安全协议(即使只是为了签名)通常被认为是不好的做法。我们正在尝试获得 HTTPS 在验证服务器方面的优势(这一点很重要,该服务器还提供可能非常大的可执行代码 - 我们不希望任何人提供恶意软件或使用大数据攻击我们的客户,而这些数据只有在收到整个系统是否会发现它是坏的)以及确保不会发生 MITM(消息本身的签名)。我们不介意是否有人窃听流量,因为它从来不包含被视为机密的内容。此外,Wireshark 中的内容并不一定需要容易阅读,只要审计人员能够做到即可。
@Nate Zaugg - 不,这不是一个笑话。事实上,令人惊讶的是,供应商如今使用带有加密功能的 HTTPS,并且没有受到存在严格合规问题的客户的强烈反对。
@erickson - 第一个使用 NULL 密码套装的解决方案看起来很有趣,我们将研究它。第二种解决方案需要为每个客户提供一组密钥——这不是我们想要管理的。
@ZZ Coder - 您的意思是使用空密码将无法在 Wireshark 中查看内容吗?
We're looking for a solution that will allow us to use HTTPS without encryption. Why? Here's the story:
Our product (installed at customers) connects to our servers to fetch updates, post information, etc. We want the product to verify that it is connected to the server (and not an imposter) prior to posting data. We also need to ensure there are no man-in-the-middle attacks (that is, the content should be signed, etc.). However, our customers require that they can sniff the traffic (Wireshark, tcpdump, etc.) and view the entire transaction's contents. This is for compliance and security reasons.
Our product is written in Java, by the way.
Any ideas?
UPDATE:
Please excuse me if I'm not using the correct form for responding to answers, I'm fairly new on this site.
First of all, thank you for your quick answers!
Our reason for investigating the possibility of HTTPS is because we don't want to invent a new protocol here. It's not just the amount of work but also the fact that inventing your own security protocol (even if just for signing) is generally considered bad practice. We're trying to gain HTTPS's advantages in authenticating the server (which is important, this server also serves executable code which can be quite large - we don't want anyone serving malware or DoSing our customers with large data that only after receiving the entire thing will the system find out it's bad) as well as ensuring MITM doesn't occur (the signing of the messages themselves). We don't mind if anyone evesdropes on the traffic because it never contains something considered confidential. Furthermore, it doesn't necessarily need to be easy to read the contents in Wireshark, only possible so auditors can do it.
@Nate Zaugg - no, this is not a joke. It's actually surprising that vendors use HTTPS with encryption today and don't get a lot of backlash from customers with strict compliance issues.
@erickson - The first solution with the NULL cipher suits looks interesting, we'll look into it. The second solution will require a set of keys for each customer - not something we'd like to manage.
@ZZ Coder - do you mean that with null ciphers it will not be possible to view the contents in Wireshark?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
有一些不加密的 SSL“密码套件”,并且所有版本的 Sun JSSE 提供程序都支持
SSL_RSA_WITH_NULL_SHA
。然而,所有应用程序数据仍然封装在 SSL 记录中(以携带提供完整性保护的 MAC 等),因此当您在 Wireshark 中查看它时,您将看到这些结构。或者,只要您不使用临时 Diffie-Hellman(
DHE_XXX
密码套件之一),您就可以向 Wireshark 提供服务器的私钥,它将解密 SSL 会话。虽然这是一些额外的工作,但它不会对服务器或客户端提出任何不寻常的要求来支持很少使用的未加密密码套件。There are SSL "ciphersuites" without encryption, and all versions of the Sun JSSE provider support
SSL_RSA_WITH_NULL_SHA
. However, all of the application data is still wrapped in SSL records (to carry the MAC that provides integrity protection, etc.), so as you look at it in Wireshark, you'll see these structures.Alternatively, as long as you don't use ephemeral Diffie-Hellman (one of the
DHE_XXX
ciphersuites), you can give Wireshark the server's private key, and it will decrypt an SSL session. While this is some extra work, it doesn't impose any unusual requirement on the server or client to support the seldom-used unencrypted ciphersuites.如果您只需要签名,为什么不能只使用私钥对每个响应进行签名(将签名放在标头中)并使用客户端上的公钥进行验证,而不使用 HTTPS?只要您的私钥保持秘密并且您选择适当的签名算法,这应该可以防止篡改响应正文,但不会对该正文保密。
If you only need signing, why can't you just sign each response with a private key (putting the signature in a header) and verify it with a public key on the client, but not use HTTPS at all? So long as your private key remains secret and you choose an appropriate signature algorithm, this should prevent tampering with the body of the response but without keeping that body secret.
有一些替代方案可以对流量进行解密,以便可以读取。 Netronome 只是一个例子。有关详细信息,请参阅 http://werebuild.telecomix.org/ w/images/2/25/Netwitness-SSL-Decryption.pdf
There are alternatives that allow for decrpting traffic so it can be read. Netronome is just one example. For details see http://werebuild.telecomix.org/w/images/2/25/Netwitness-SSL-Decryption.pdf
我同意@Jon Skeet - 你不应该尝试使用有问题的HTTPS,相反你应该只签署你的回复。您可以查看 Amazon S3 的一些文档,以获取坚固、健壮、但安全模型相当简单。
简而言之,基本思想是,拥有某种密钥,将其和时间戳附加到您的消息中,然后对其进行哈希处理。将哈希值和日期(显然不是秘密)与您的消息一起发送到服务器。然后,您的服务器会检查该日期是否足够接近可信(例如 15 分钟),并对请求、日期及其存档的密钥进行哈希处理。如果它获得相同的哈希值,则受信任的资源生成该请求,并且服务器可以安全地继续。
显然,这对于中间人嗅探来说是不安全的(你似乎可以接受),但它会阻止 MITM 更改或创建虚假请求。
I would agree with @Jon Skeet - you shouldn't be trying to use a crippled HTTPS, instead you should just sign your responses. You can look at some of the documentation for Amazon's S3 for a good example of a sturdy, robust, and yet fairly straightforward security model.
In short though, the basic idea is, have some kind of secret key, append it and a timestamp to your message and hash that. Send the hash and date (but not the secret, obviously) along with your message to the server. Your server then checks that the date is close enough to trust (say 15 minutes) and hashes the request, date, and the secret key which it has on file. If it gets the same hash, then a trusted resource generated the request, and the server can safely proceed.
Obviously, this is not safe from man-in-the-middle sniffing (which you seem to be ok with) but it will prevent a MITM from changing or creating phony requests.
您可以尝试使用 NULL 密码(1 和 2),但大多数服务器都配置为不接受弱密码。当然,这两个密码是最弱的。
即使有效负载是明文形式,它仍然封装在 SSL 帧内,因此最常见的数据包解密不起作用。
You can try to use the NULL ciphers (1 and 2) but most servers are configured not to accept the weak ciphers. Of course, these 2 ciphers are the weakest.
Even the payload will be in clear text, it's still wrapped inside SSL frame so most common packet decipher doesn't work.
那么每个客户端不应该有一个不同的密钥吗?否则你的服务器如何知道谁在发帖?服务器不关心中间的任何人吗?
如果每个客户端都有一个服务器知道的密钥(例如简单密码),则该密钥可以用作具有哈希函数的盐来签署请求/响应。
well shouldn't each client have a distinct key anyway? otherwise how does your server know who is posting? the server doesn't care any man in the middle?
if each client has a key, like a simple password, that the server knows, the key can be used as salt with a hash function to sign requests/responses.