绿色挂锁揭秘：SSL 握手是如何工作的？

每天在安全浏览网页时，您会想到浏览器中网站 URL 地址附近著名的绿色挂锁和 HTTPS 版本的数据传输协议。 在本文中，我们将了解HTTPS 为何真正安全，以及如何保护通信免受第三方窃听。

首先，我们将简要介绍两个基本的加密概念：数字签名和加密，我们将深入了解一个称为SSL 握手的过程，该过程在客户端和服务器开始交换通信之前执行，用于建立安全的加密上下文。 我们将通过一个称为客户端证书身份验证的可选步骤来完成有关如何进一步提高安全性的信息。

公钥密码学 101：密钥对

认识 Alice 和 Bob，这两个人决定使用加密方法安全地交换他们的私人消息。 他们必须面对的第一个选择是在两种不同的加密类型之间：对称和非对称密钥加密（也称为公钥加密）。

但是等等，这些键是什么？ 基本上，我们可以简化为一个键是一个随机的字符序列。 我们可以使用这个序列对消息进行转换（执行某种加密操作）——我们很快就会深入研究。

对称密钥密码学

使用对称密钥加密时，发送者生成一个密钥，然后为接收者复制它。 发送者保存原始密钥，并将副本传递给接收者。 相同的密钥用于通信两端的加密操作。

对称密钥加密的主要优点和缺点是什么？

非对称密钥加密

当使用非对称密钥加密时，发送者和接收者都会生成一个密钥对——一个公钥和一个私钥。 这些密钥在数学上相互耦合，以在各种加密操作中协同工作。 发送者和接收者都安全地保存了他们的私钥，但他们可以在没有特殊预防措施的情况下交换公钥。 他们甚至可以使用一种“公钥黄页”——一个公钥服务器来发送他们的公钥以供任何人访问。

非对称密钥加密的优缺点是什么？

由于非对称加密设置更安全，Alice 和 Bob 决定采用它！ 现在他们可以利用这一点并开始考虑确保通信的安全性和完整性。

公钥密码学 101：加密

当 Alice 向 Bob 发送消息时，她想确保没有其他人可以看到内容是什么。 她决定加密消息。 为此，Alice 必须首先从密钥服务器或通过通信通道直接从 Bob 获得 Bob 的公钥。 一旦 Alice 获得了密钥，她就可以使用 Bob 的公钥对她想要发送的消息进行加密操作。

一般来说，在这个过程中，消息被加密算法（又名密码）以块（最常见）的形式获取，并且在消息和密钥之间执行一些位操作，产生一个输出，即加密消息（又名密文） . 当 Bob 得到加密消息时，他是唯一可以用他的私钥解密它的人。

笔记：

• 消息加密——发件人使用收件人公钥加密消息
• 消息解密——接收者用他们的私钥解密消息

公钥密码学 101：签名

除了防止消息内容被泄露之外，能够确认发件人的身份并验证消息是否未被更改同样重要。 正是出于这两个原因，才使用数字签名（附加到消息的单独对象）。

Alice 首先使用散列算法开发消息散列来生成她的签名。 散列是在消息上计算单向数学函数，产生更短的固定值输出——不同的输入不同。 然后她使用她的私钥对生成的哈希进行加密（签名）。

接下来，当 Bob 收到消息和签名时，他可以首先使用 Alice 的公钥解密签名。 当成功时，他知道签名确实是由 Alice 生成的（否则，用她的公钥解密会失败）。

其次，Bob 可以获取消息并使用 Alice 之前使用的相同算法对其进行散列，并确认他的消息散列与 Alice 生成的散列相同。 当哈希匹配时，他知道消息没有被篡改。

笔记：

• 生成签名——发送者用他的私钥加密（签名）消息哈希并创建签名
• 验证签名——接收者首先从签名中解密消息散列并检查他计算的散列是否与签名中的散列匹配
• 加密和签名可以分开使用，但为了最高的安全性，它们通常结合使用。 因此，您可以遇到的大多数加密函数称为encryptSignMessage() 、 decryptVerifyMessage()等。

我希望你没有跟上爱丽丝和鲍勃的故事。 让我再次说明整个流程，以确保一切都清楚并总结。

1. 爱丽丝想给鲍勃发消息
2. Alice 获取她的私钥并生成签名
3. Alice 获取 Bob 的公钥并加密消息
4. Alice 将消息发送给 Bob
5. Bob 获取 Alice 的公钥并验证签名
6. Bob 使用他的私钥解密消息

好了，理论就够了。 现在让我们看看所有这些是如何在 HTTPS 中使用的！

SSL 握手

请打个招呼

当客户端启动与服务器的连接时，首先要进行适当的介绍，以便为其余的通信建立加密上下文。 这可以在 HTTPS CONNECT 步骤中完成，在解析标头和请求正文之前。 这一切都始于客户端发送客户端问候消息。

最重要的是，该消息包含客户端理解的加密算法和一些附加材料，如支持的压缩算法、协议版本、会话 ID 等。由于服务器喜欢礼貌，它还以服务器 hello 消息进行响应，其中最值得注意的是包含带有服务器公钥的服务器证书（是的，该过程基于公钥加密 - 与 Alice 和 Bob 选择的方法相同）。

证书颁发机构

现在是时候在舞台上欢迎我们的下一位客人了：证书颁发机构(CA)。 这个名字听起来很严肃——但它只是一个拥有大量街头信用的第三方实体，在全球范围内基本上被认为是值得信赖的。 这样的实体可以验证服务器的身份并将他们的数字签名与服务器证书一起放置（类似于 Alice 向 Bob 发送消息时）。

证书验证

现在让我们最终考虑浏览器 URL 地址旁边的标题绿色挂锁。

每个 Web 客户端都有一个捆绑的知名且受信任的证书颁发机构的公钥列表。 你可能还记得，在文章的开头，我提到签名是使用发送者的私钥生成的，并且可以使用发送者的公钥进行验证。 好吧，这正是客户所做的。 它遍历捆绑的受信任 CA 列表并检查服务器证书的签名是否属于受信任的 CA 之一。 如果是，它就会接受证书——这就是挂锁变绿的时刻。

但这只是第一步，与安全无关。 任何人都可以复制任何公钥证书，将其放在服务器上并将其呈现给连接的客户端，对吗？

客户端验证服务器证书后，会创建一个对称密钥来加密通信。 但是，正如我在开头提到的，对称密钥的问题在于它们在传输过程中很容易被截获。 在这一步，客户端和服务器没有共同的加密上下文。 因此客户端将对称密钥发送给服务器，但它首先使用服务器的公钥对其进行加密。 然后服务器收到它并需要解密它以建立安全连接的能力。

因此，即使有人会出示被盗的公钥证书，这也是他们失败的一步。 绑定到服务器证书公钥的有效私钥对于解密对称密钥至关重要。 当然，这对于合法服务器来说不是问题，因为它安全地保存了私钥。 它可用于解密对称密钥并加密进一步的通信。

因此，总而言之， SSL 握手是一个同时使用对称和非对称加密类型的过程。 首先，非对称密钥对启动连接并为对称密钥的传输提供安全的方式。 正如我们在开始时指出的那样，对称加密操作更快，因此在设置后将其用于整个通信是有益的。 此外，一旦建立了安全连接，它就会被重复使用直到过期，因此在每个客户端请求之前不会完成非对称密钥设置。

还值得一提的是，在现实生活中，证书不是由最著名的可信 CA （称为根）直接签名的。 尽管如此，根 CA 签署中间证书，然后最终签署服务器证书 - 从而创建证书链，连接客户端检查该证书直到满足有效签名。 它当然提供了更好的安全性——当其中一个中间 CA 被破坏时，它影响的人更少。

客户端证书验证

现在，我们可以简要提及一个可选步骤，因为我们拥有理解它所需的所有知识。 可以将服务器配置为在建立安全连接后请求和验证客户端证书以实现额外的安全性。

以同样的方式工作——但这​​一次，客户端发送他们的证书，服务器通过他们的受信任的证书颁发机构列表并对其进行验证。 值得一提的是，服务器在开发者的控制之下（与客户端相反，即网络浏览器或移动操作系统），因此后端开发者可以轻松地修改受信任证书列表。

公司网络通常使用这种机制。 最常见的是，客户端证书由安装在员工设备上的设备管理系统生成，并使用公司生成的根证书进行签名。 相同的证书也被添加到后端环境中。 这样，企业后端可以在客户端连接时轻松验证证书。

让我们浏览我们的后端解决方案

阅读更多

现在，总结一下，让我们看一下整个流程的图表：

概括

你已经到了文章的结尾！ 希望您已经了解HTTPS 中加密设置的实现机制以及签名和加密过程的应用方法。

既然您知道事情是如何运作的，那么您当然应该对数据加密更有信心。 不过，重要的是要记住，浏览器中的绿色挂锁还不能保证安全。 在安全敏感的上下文中，您还应该仔细检查证书。 正如他们所说，预先警告就是预先武装！