在Java中使用HTTPS而不加密

我们正在寻找一种解决方案，它允许我们在不加密的情况下使用HTTPS。为什么？故事是这样的：

我们的产品（安装在客户处）连接到我们的服务器以获取更新、发布信息等。我们希望产品在发布数据之前验证它是否连接到服务器（而不是冒名顶替者）。我们还需要确保没有中间人攻击（即，内容应该签名，等等）。但是，我们的客户要求他们可以嗅探流量（Wireshark、tcpdump等）并查看整个事务的内容。这是出于法规遵从性和安全原因

顺便说一下，我们的产品是用Java编写的

有什么想法吗

更新： 请原谅，如果我没有使用正确的表格回答问题，我是这个网站的新手

首先，感谢您的快速回答

我们之所以研究HTTPS的可能性，是因为我们不想在这里发明新的协议。这不仅是工作量的问题，而且事实上，发明自己的安全协议（即使只是为了签名）通常被认为是不好的做法。我们正试图获得HTTPS在验证服务器方面的优势（这一点很重要，该服务器还提供相当大的可执行代码-我们不希望任何人向恶意软件提供服务或向我们的客户提供大数据，只有在接收到整件事情后，系统才会发现它不好）以及确保不会发生MITM（消息本身的签名）。我们不介意有人偷看流量，因为它从不包含被认为是机密的东西。此外，阅读Wireshark中的内容并不一定要简单，只有在审计师能够做到这一点的情况下才有可能

@内特·扎格-不，这不是玩笑。事实上，令人惊讶的是，如今的供应商使用HTTPS进行加密，却没有受到有严格法规遵从性问题的客户的强烈反对

@erickson-第一个使用空密码套装的解决方案看起来很有趣，我们将对此进行研究。第二个解决方案需要为每个客户提供一组密钥，而不是我们想要管理的

---

@ZZ编码器-您的意思是，使用空密码无法在Wireshark中查看内容吗？

如果您只需要签名，为什么不能使用私钥（将签名放在标题中）对每个响应进行签名，并在客户端使用公钥进行验证，而不使用HTTPS？只要您的私钥仍然是保密的，并且您选择了适当的签名算法，这应该可以防止篡改响应的主体，但不会保留该主体的机密。

存在未加密的SSL“CipherSuite”，并且Sun JSSE provider的所有版本都支持

SSL\u RSA\u和\u NULL\u SHA

。但是，所有的应用程序数据仍然包装在SSL记录中（以承载提供完整性保护的MAC等），因此当您在Wireshark中查看它时，您将看到这些结构

---

或者，只要不使用短暂的Diffie Hellman（一种

DHE_XXX

CipherSuite），就可以将服务器的私钥提供给Wireshark，它将解密SSL会话。虽然这是一些额外的工作，但它不会对服务器或客户端提出任何异常要求，以支持很少使用的未加密密码套件。

您可以尝试使用空密码（1和2），但大多数服务器配置为不接受弱密码。当然，这两个密码是最弱的

---

即使有效负载是明文的，它仍然包装在SSL框架内，所以大多数常见的数据包解密都不起作用。

我同意@Jon Skeet的观点-你不应该试图使用受损的HTTPS，而应该只是在你的回复上签名。您可以查看一些文档，以获得一个坚固、健壮但相当简单的安全模型的良好示例

简而言之，其基本思想是，拥有某种密钥，将其和时间戳附加到消息中，并对其进行散列。将散列和日期（但显然不是秘密）与消息一起发送到服务器。然后，服务器检查日期是否足够可信（比如15分钟），并对请求、日期和文件中的密钥进行散列。如果它得到相同的散列，那么受信任的资源将生成请求，服务器可以安全地继续

---

显然，这对于中间人嗅探（您似乎对此很满意）并不安全，但它可以防止MITM更改或创建虚假请求。

那么，每个客户机都不应该有一个不同的密钥吗？否则，您的服务器如何知道谁在发帖？服务器在中间不关心任何人？

---

如果每个客户端都有一个服务器知道的密钥（如简单密码），则该密钥可以用作salt，并带有一个哈希函数，用于对请求/响应进行签名。

有其他方法可以减少通信量，以便读取。Netronome只是一个例子。有关详细信息，请参见Wireshark解决方案的Upvote。理想情况下，如果您为该客户执行此操作，请为他们提供自己的私钥，而不是共享您的服务器私钥。这可以确保如果密钥丢失，客户只会受到影响。建议重新表述问题“暴露HTTPS流量以进行嗅探/安全审核”。这是一个好主意，但需要在向服务器发布任何数据之前验证服务器身份。我不确定这个要求是否合理，因为通常你会想验证身份，以避免向中间的人泄露秘密；在这里，内容不是私有的，所以我不明白为什么它很重要。@erickson：你可以发出一个空请求，让服务器简单地对一个没有重要数据的小响应进行签名。如果我继续这样做，我会考虑使用多部分S/MIME签名的消息进行响应。