security - HTTPS 的安全性如何？任何人都不能解密回复吗？

Question

我了解公钥密码学的概念，而 HTTPS 在证明身份方面对我来说非常有意义。

我不明白的是它如何使用户的请求和网站的响应变得不可读。该站点的公钥是公开的——所以任何人都不能记录网络流量、捕获响应并使用每个人都可用的公钥对其进行解码吗？如果没有私钥，他们将无法执行中间人攻击，但为什么他们不能读取用户得到的响应？

反之亦然:用户可能在初始连接时将其公钥发送到服务器，那么记录用户网络流量的人不能解密所有请求吗？

我想我要问的是:双向公钥密码学如何提供除了身份证明之外的任何东西？

Answer 1

您对如何建立 SSL 连接的分析缺少初始化的一个重要部分，即 。 key 交换 .

作为 SSL 连接设置的一部分，客户端和服务器就要使用的对称密码以及与该密码一起使用的 key 达成一致。安全性基于密码的强度和对称 key 的保密性，对称 key 只有客户端和服务器知道。

生成和共享对称 key 的机制很复杂。

在一个过于简单的场景(足以回答所提出的问题)中，我们可以认为客户端生成要使用的对称 key 。客户端将 key 发送到服务器，诀窍在于它使用服务器的公钥在使用非对称密码加密的消息中发送它。

由于消息(包含“ secret ” key )是使用服务器的公钥加密的，因此只有服务器可以解密消息，所以对称 key 是“ secret ”的，因为只有服务器和客户端知道对称 key 。

一旦客户端和服务器建立了用于加密的对称密码和 key ， session 的其余部分将使用该密码和 key 来加密和解密消息。

问:任何人都不能解密回复吗？

任何使用服务器私钥“加密”的消息都有可能被任何拥有服务器公钥的人解密。然而这不是 SSL 的工作方式——消息永远不应该用私钥加密。

“技巧”(如果你愿意的话)是第二个 key 和密码。客户端生成第二个“ secret ” key ，只有它自己知道，然后将第二个 key 安全地发送到服务器。 (它通过使用服务器的公钥加密消息中的第二个“ secret ” key 来安全地执行此操作。客户端和服务器通过执行称为 Diffie-Hellman 的 key 协商协议(protocol)来生成 secret 来建立 secret key key 。

key 建立后， session 的剩余部分使用第二个“ secret ” key ，现在客户端(生成 key 的)和服务器都知道该 key 。

正如@MarteenBodewes 指出的那样，客户端和服务器用于就对称 key 达成一致的机制，包括验证服务器的真实性等。比我在上面的答案中给出的过于简化的解释更复杂。也就是说，说客户端生成对称 key 并发送给服务器是不正确的。

无论实际的机制和 key 交换有多复杂，主要思想是客户端和服务器就使用对称密码达成一致，并就使用的 key 达成一致。安全性来自对称密码的强度和 key 的保密性。