了解 HTTPS 如何工作并对此进行查询？ [关闭]答案

【问题标题】：Understanding How HTTPS works and queries on this? [closed]了解 HTTPS 如何工作并对此进行查询？ [关闭]
【发布时间】：2012-03-23 20:22:28
【问题描述】：

我已经浏览了两个关于 HTTP 与 HTTPS 的好链接，即

我提出了我的简单理解和一些疑问。这是理解：-

当我们从 http 迁移到 https 时，我们必须修改 web 应用程序，以便当它接收到第一个请求时，它会发送带有响应的数字证书。
我们必须修改的另一件事是 server.xml 以包含密钥库位置（如值是 .keystore）和密码。这个密钥库实际上将包含将用于加密和解密双方的数据，即服务器和客户端（浏览器）。
现在，当客户端发送第一个请求时，它会获取加密的数据、证书和密钥。浏览器根据这个密钥对数据进行解密和加密。再次将其发送回客户端。一旦浏览器接受检查证书的真实性，它就会表明它是受信任的站点。

以上步骤正确吗？

如果是，我们怎么能说黑客可以破解它。因为如果加密和解密是在基础算法上进行的（基于 .keystore 文件中的密钥），他们还可以在将请求发送到服务器时解密数据。如果浏览器可以使用该算法，为什么黑客不可以呢？我同意它将增加一项额外的安全性一步，但它仍然可以被黑客入侵。只是一个想法？

【问题讨论】：

【解决方案1】：

大致的基本情况如下：

服务器有一个公钥和一个私钥。用一个加密的所有东西都只能用另一个解密。

服务器根据请求发送公钥。

客户端创建一个秘密（想想随机数），用公钥对其进行加密并将其发回。

只有服务器可以解密它。

服务器和客户端现在共享一个秘密，它们可以用来加密来回的消息。

如果您想了解更多详细信息，我建议您使用 google SSL

【讨论】：

其实我对两个文件有疑问。我可以有两个密钥文件，一个是 .keystore，另一个是 CAKey.pem。我特别想知道这两个文件之间的区别。在 server.xml 中，我找到了一个 .keystore 文件和密码条目，而在应用程序中，我找到了我为 CAKey.pem 提供的密码。所以对这两个文件和角色感到困惑
这是一个完全不同的问题（完全不是关于 HTTPS 的工作原理），而是关于某些特定文件格式的目的。来吧，在stackoverflow上提出问题
stackoverflow.com/questions/9586304/…

【解决方案2】：

我不太理解您的问题，但是是的，只要您可以双向拦截消息，就可以窃听 HTTPS - 请阅读有关man-in-the middle 攻击的信息。

但是，如果可以“带外”安全地交换公钥或以其他方式验证公钥，那么公钥加密是安全的，不会被窃听。

【讨论】：