公钥加密

Question

这就是我理解公钥如何工作的方式......假设您在一个网站上并且您访问信用卡页面。然后，您使用该站点的公钥加密数据包并将其发送给他们。然后站点使用相应的私钥对数据包进行解码。所以那部分我明白了。

现在，当我访问经过身份验证的页面时如何。假设我正在访问我的银行帐户页面。网站如何加密发往我的数据包。我怎么打开它，我怎么知道一路上有人没有读过它。

Answer 1

这是一个相当大的问题 =) 下面是 HTTPS 的高级概述；如果有任何不清楚的地方，请大声喊出来，我会填写更多细节。

当您使用 HTTPS 连接时，公钥加密仅在会话初始化期间使用。该初始化的一部分是安全交换私有共享密钥，然后将其用于对称加密。这样做的原因是，由于涉及到数学，非对称（公钥）加密比对称密钥加密慢得多。

SSL握手

在非常高的层次上，协议是这样的：

1. 客户端发送初始“HELLO”消息，其中包含它想要使用的 ssl 版本、一个伪随机比特串（我们称之为 B1）和它支持的各种密码的列表。

2. 服务器用它自己的“HELLO”消息响应，另一个伪随机位串（我们称之为 B2），它选择的密码（通常是客户端发送的服务器支持的列表中最强的密码），以及它的包含其公钥的证书（我们称之为k）。

3. 客户端然后使用证书对服务器进行身份验证（见下文）并创建一个“premaster secret”——另一个我们称之为 S 的伪随机位字符串。

4. 如果客户端对服务器验证的结果感到满意，它会使用服务器的公钥k对预主密钥 S 进行加密，并将其发送到服务器（S 本身已加密，但连接仍未加密）。

5. 此时，服务器和客户端共享三个比特串 - B1、B2 和 S。 B1 和 B2 以明文形式发送 - S 被加密，因此，假设服务器的私钥确实是私有的，只有服务器知道客户端和服务器。

6. 然后客户端和服务器都使用这三个位串来构造会话密钥——一个只有他们知道的字符串，并且可以用作先前选择的对称密码中的密钥。

7. 客户端和服务器然后交换表明他们正在改变协议的消息，并且所有后续消息都被加密（对称地，使用上面计算的密钥）。

服务器认证

当客户端收到服务器的 HELLO 消息时，它需要确保它正在与它认为的服务器通信。服务器证书和密钥用于建立这种信任。

数字证书的全部内容是第三方声明“该实体持有与该公钥对应的私钥，该私钥嵌入在该证书中”。像 Verisign 这样的组织会做出这样的断言——这是有代价的。人们向 Verisign 和其他人支付证书费用的原因是 Verisign 遇到了将他们的中间证书嵌入到大多数常见浏览器中的麻烦。

所以，当客户端收到服务器 HELLO 时，会进行以下检查：

• 今天的日期是否在证书的有效期内？
• 证书的主题名称是否与我尝试连接的服务器的主题名称匹配？
• 证书上的颁发者名称是否与我知道其公钥的任何 CA 相匹配？
  • 如果是这样，我为此 CA 拥有的公钥是否会验证此证书？

如果所有这些检查都通过，则客户端假定它可以相信服务器就是它所期望的。然后它从证书中取出公钥（仍然是k），并使用它安全地将 S 传输到服务器。在这一点上，想法是您有一些第三方（Verisign）的断言，即公钥属于服务器；所以只有服务器才能解密 E(S, k ) 的结果，因此只有服务器才能生成您将用于对称密码的匹配密钥。

握手后，您对第三方无法读取数据包的信心应该等于您对正在使用的对称算法的信心。

（还有其他很好的曲折——例如，使用三位字符串的原因是为了防止重放攻击。如果只使用 S，攻击者可以记录整个会话并在闲暇时重放它——例如，重复一次汇款指令并结束。通过让客户端和服务器生成额外的伪随机字符串，您可以大大降低两个独立 SSL 握手产生相同 S 的可能性。）