行业新闻与博客

TLS 握手说明：它是什么，为什么发生以及在失败时如何解决。

让我们谈谈对 SSL / TLS 的了解最少的方面之一：SSL 握手，或更恰当地说是 TLS 握手。

如您所知，SSL / TLS 证书是通过 HTTPS 服务您的网站所必需的。在过去的几年中，作为对用户安全性的更大关注的一部分，SSL / TLS 受到了公众和 IT 行业的更多关注和关注。2016年，所有网络流量的 50％首次使用 SSL / TLS 进行了加密。三年后的现在，全球 79％的顶级站点都在使用 HTTPS。

但是，很多人还是真的不知道怎么SSL / TLS 的作品。

SSL / TLS 握手最重要的部分之一是 SSL / TLS 握手。握手是每个连接开始的地方，也是建立 SSL / TLS 技术基础的地方。

“ SSL / TLS 握手”是建立 HTTPS 连接的过程的技术名称。SSL / TLS 协议涉及的大多数艰苦工作都在这里完成。自从最初的 SSL 协议于 1996年创建以来，这一过程就得到了发展，每次新迭代都变得更快，开销更少。去年，IETF 完成了 TLS 1.3 的定稿，该协议的特征是彻底修改了握手功能。

现在实际上有两次握手。

因此，今天我们将解释 TLS 1.2 和 TLS 1.3 的 SSL / TLS 握手，从高级开始，然后深入探讨具体细节：

• 交换加密功能
• 验证 SSL 证书
• 交换 / 生成会话密钥。

我们还将讨论那些讨厌的 TLS 握手失败错误，并提供一些解决方法。

让我们将其散列出来。

目录

1. TLS 握手说明：它是什么，为什么发生以及在失败时如何解决。
2.  TLS 握手摘要
   1. 谈判密码套件
   2. 认证方式
   3. 密钥交换
3. TLS 1.2 握手：逐步
4. TLS 1.3 握手：逐步
5. TLS 握手的成本
6. TLS 1.2 握手与 TLS 1.3 握手–改进
   1. 简化密码套件
   2. 零往返恢复– 0-RTT
   3. 保护更多的 TLS 1.3 握手
7. TLS 握手–协商密码套件
   1. TLS 1.2 密码套件
   2. TLS 1.3 密码套件
   3. 那么，从 TLS 1.2 到 TLS 1.3 具体发生了什么变化？
8. TLS 握手–身份验证
   1. RSA vs. Diffie-Hellman / ECC –快速历史
   2. TLS 1.2 握手-身份验证
   3. RSA 认证
   4. Diffie-Hellman 身份验证
   5. TLS 1.3 握手–身份验证
9. TLS 握手–密钥交换
   1. RSA 密钥交换
   2. Diffie-Hellman 密钥交换
   3. TLS 1.2 握手– Diffie-Hellman 版
   4. DHE 与 RSA 相比有两个优势
   5. TLS 1.3 握手–密钥交换
10. 修复 SSL / TLS 握手失败错误
11. 包起来…

TLS 握手摘要

HTTPS 连接涉及两方：客户端（发起连接的一方，通常是您的 Web 浏览器）和服务器。这两方是“握手”的人。SSL / TLS 握手的目的是执行具有安全连接所需的所有加密工作。这包括验证正在使用的 SSL 证书，以及生成加密密钥。

就像我们在顶部说的那样，TLS 握手完成了 3 个主要任务：

• 交换密码套件和参数
• 认证一方或双方
• 创建 / 交换对称会话密钥

让我们从概念上解释每种情况的发生。

谈判密码套件

每个软件都不相同。Web 浏览器是最常见的客户端，不同的流行浏览器（例如 Google Chrome，Mozilla Firefox 和 Microsoft Internet Explorer）的功能可能会有所不同。同样，在服务器端，流行的操作系统（例如 Windows Server，Apache 和 NGINX）都具有非常不同的功能支持。当您添加自定义配置时，所有这些都变得更加复杂。因此，TLS 握手的第一步要求客户端和服务器共享其功能，以便它们可以找到相互支持的加密功能。

一旦客户端和服务器商定了它们将使用的确切加密方法（称为密码套件），服务器就会向客户端发送其 SSL 证书。

认证方式

客户在收到证书后会进行检查，以确保证书是“真实的”。这是非常重要的一步。为了真正建立安全的连接，您不仅可以加密数据，还需要知道数据已经发送到正确的网站 / 组织。SSL / TLS 证书提供了该身份验证。但是他们的方式取决于所使用的密码套件。

所有受信任的 SSL 证书均由证书颁发机构（CA）颁发，该机构是一家已被批准颁发数字证书的公司。这些组织必须遵循严格的发行和验证准则，以便他们发行的证书继续受到信任。这主要是为了确保您只能获得您真正拥有的网站或公司的证书。在这种情况下，您可以认为 CA 像公证人一样-它的签名表示证书上的实体就是它所说的那个人。

在 TLS 握手的身份验证部分期间，客户端执行几次加密安全检查，以确保服务器提供的证书是真实的。这包括检查数字签名并确保证书源自受信任的 CA。

在此阶段，客户端还将验证服务器是否拥有与证书关联的私钥。所有 SSL 证书都包含一个由公钥和私钥组成的密钥对。公钥用于加密数据，私钥用于解密。这被称为“非对称”公共密钥加密，因为这两个功能是由不同的密钥执行的。加密实际上是单向的。

使用最常见的公共密钥密码系统 RSA，客户端将使用需要用于生成会话密钥的公共密钥对随机数据进行加密。如果服务器具有提供所有权证明的私钥，则服务器将只能解密和使用该数据。

如果使用了另一种类型的密码系统（例如 ECC），则此过程会更改，但始终会检查拥有权证明。

密钥交换

TLS 握手的最后一部分涉及创建“会话密钥”，这是实际上将用于安全通信的密钥。

会话密钥是“对称的”，这意味着同一密钥用于加密和解密。与非对称密钥相比，这些密钥可以更有效地实现强加密，从而使其适合在 HTTPS 连接中来回发送数据。

生成密钥的确切方法因所选的密码套件而异，其中最常见的两种方案是 RSA 和 Diffie-Hellman。

为了结束握手，双方让对方知道他们已经完成了所有必要的工作，然后双方运行校验和以确保握手发生而没有任何恶意篡改或破坏。

整个 SSL 握手发生在几百毫秒内，而且一切都在幕后。这是 HTTPS 连接中必须发生的第一件事，甚至在加载网页之前也是如此。

SSL 握手完成后，加密并经过身份验证的 HTTPS 连接开始，并且您与服务器之间发送和接收的所有数据都将受到保护。

直到 TLS 1.3，每次您重新访问一个站点时，握手都会再次发生。TLS 1.3 握手支持 0 RTT 或零往返时间恢复，这大大提高了返回访客的速度。以前，许多服务器都实施了“恢复”过程以提高效率和速度，但是 0 RTT 会将其提高到 11。

TLS 1.2 握手：逐步

每个 TLS 握手都涉及一系列步骤，这些步骤完成了我们上面概述的三个主要任务：交换加密功能，认证 SSL 证书以及交换 / 生成会话密钥。

对于希望了解确切过程的人员，以下是 TLS 1.2 握手所涉及的步骤（使用 RSA –我们在本文的更深处有一个 Diffie-Hellman TLS 1.2 握手的示例）。

所说明的步骤在左侧显示客户端，在右侧显示服务器。

1. 第一条消息称为“ ClientHello”。此消息列出了客户端的功能，以便服务器可以选择两者用来通信的密码套件。它还包括一个随机选择的大素数，称为“客户随机数”。
2. 服务器礼貌地回应“ SeverHello”消息。在此消息中，它告诉客户端从提供的列表中选择了哪些连接参数，并返回其自己随机选择的素数，称为“服务器随机数”。如果客户端和服务器没有共同的功能，则连接将失败。
3. 在“证书”消息中，服务器将其 SSL 证书链（包括其叶证书和中间证书）发送给客户端。为了向连接提供身份验证，CA 签署了 SSL 证书，该证书允许客户端验证该证书是合法的。收到后，客户端将执行几项检查以对证书进行身份验证。这包括检查证书的数字签名，验证证书链以及检查证书数据是否存在任何其他潜在问题（过期的证书，错误的域名等）。客户端还将确保服务器拥有证书的私钥。这是在密钥交换 / 生成过程中完成的。
4. 这是一条可选消息，仅对于某些要求服务器提供其他数据的密钥交换方法（Diffie-Hellman）才需要。
5. “服务器已完成问候”消息告诉客户端它已经发送了所有消息。
6. 然后，客户端将其贡献提供给会话密钥。此步骤的细节取决于初始“ Hello”消息中确定的密钥交换方法。在此示例中，我们正在研究 RSA，因此客户端将生成一个随机的字节串（称为“主密码”），然后使用服务器的公钥对其进行加密并进行传输。
7. “更改密码规范”消息使另一方知道它已生成会话密钥，并将切换到加密通信。
8. 然后发送“已完成”消息，以指示客户端已完成握手。Finished 消息被加密，并且是会话密钥保护的第一个数据。该消息包含数据（Mac），该数据允许各方确保握手未被篡改。
9. 现在轮到服务器执行相同的操作了。它解密主密码，并计算会话密钥。然后，它发送“更改密码规范”消息，以表明它正在切换到加密通信。
10. 服务器使用刚生成的对称会话密钥发送其“已完成”消息，它还执行相同的校验和以验证握手的完整性。

这些步骤之后，SSL 握手完成。双方现在都有一个会话密钥，并将开始与经过加密和身份验证的连接进行通信。

此时，可以发送“应用程序”数据（属于双方将交流的实际服务的数据，即网站的 HTML，JavaScript 等）的第一个字节。

TLS 1.3 握手：逐步

让我们首先看一下正在运行的 TLS 1.3 握手，然后我们将深入研究所做的改进。如您所见，TLS 1.3 握手比以前的握手要短得多。

1. 与 TLS 1.2 握手一样，“客户端问候”消息开始握手，但是这次打包了很多信息。TLS 1.3 将支持的密码数量从 37 个减少到了 5 个。我们将在稍后详细介绍这意味着什么，但是在握手的上下文中，这意味着客户端可以猜测将使用哪种密钥协议 / 交换协议。除了从其猜测的协议中发送其密钥共享。
2. 服务器将以其自己的服务器 Hello 消息进行响应，同样，服务器非常客气。像 1.2 握手一样，它也会在此时发送证书。并且，如果客户端猜对了，并且两者已经就相同的 AEAD 协议达成共识，则服务器将发送其自己的部分密钥共享，计算会话密钥并以服务器完成的消息结束。
3. 现在，它具有所有相关信息，客户端将对 SSL 证书进行身份验证，并使用这两个密钥共享来计算自己的会话密钥副本。完成后，它将发送自己的“已完成”消息。

现在让我们谈谈 TLS 1.3 及其对 TLS 1.2 的改进。

TLS 握手的成本

从历史上看，对 SSL / TLS 的抱怨之一是它的额外开销给服务器造成了压力。这也使人们不再相信 HTTPS 比 HTTP 慢。

这完全是由于在 TLS 1.2 之前的握手是一个昂贵的过程，并且从规模上讲，它们会严重加重服务器的负担。如果同时执行足够的 TLS 1.2 握手，也可以减慢速度。认证，加密和解密都是昂贵的过程。

对于较小的网站，这可能不会明显降低速度，但是对于每天吸引成千上万访问者的企业网站来说，这可能是个大问题。

每次握手的新迭代都需要采取实质性步骤来简化流程。TLS 1.2 进行两次往返，而 TLS 1.3 进行一次往返，并支持 0 RTT。

但是 1.2 握手的部分问题实际上与 SSL / TLS 握手过程本身无关，而与实现它的一种方法有关：非对称加密。特别是密钥交换部分。非对称加密比对称加密慢 10,000 倍。

稍后我们将对此进行更深入的探讨。但是，特别是 RSA，是主要的犯罪者。如此之多，以至于它在 TLS 1.3 中已作为密钥交换选项被完全删除。它的公钥 / 私钥非常繁琐：2048 位及更高版本，这需要大量资源才能使用，并且再次大规模扩展时，确实会增加延迟。

这并不是说 RSA 并不快，速度和运行一个进程所需的计算能力不一定是同一回事。RSA 仍然可以很快，它只会给服务器增加负担。

这也不是唯一的罪魁祸首。相比之下，ECC / Diffie-Hellman（ECDH）密钥交换更轻便-但在某些配置中（特别是与 ECDSA 配对时）仍需要大量资源。

所有这一切都说明 SSL / TLS 握手历来很昂贵，而且如果配置不当，通常扩展性也很差。

这就是为什么大型组织将其 SSL / TLS 功能卸载到负载均衡器和其他边缘设备已成为一种相当普遍的做法的原因。减轻所有这些握手的负担并简化它们提供的加密功能可带来两个主要好处：它释放了应用程序服务器上的资源，并提供了检查流量的机会。

该方法如何与 TLS 1.3 配合使用，其完善的握手机制仍在充实。

TLS 1.2 握手与 TLS 1.3 握手–改进

了解 TLS 1.3 对 SSL / TLS 握手所做的改进的最好方法是从讨论往返行程开始。为了更容易理解，我们在上面的说明中将握手分为十个不同的步骤。实际上，许多事情是同时发生的，因此将它们组合在一起并称为往返是很常见的。

最佳情况下，TLS 1.2 握手进行两次往返。在某些情况下，可能需要额外的往返行程，因此，当我们指的是最佳情况下要讨论的往返行程数。我在这里说明了它：

相比之下，TLS 1.3 的握手仅进行一次往返，尽管可能很重要的一点是要指出这也可能会引起误解。我什至可以说这是一个半程往返。不过，它比 TLS 1.2 的速度要快得多。

简化密码套件

往返次数的减少归因于上述密码套件支持的减少。从来没有人提出过拥有 37 个可接受的套件，只是其中的一部分已经演变成这样。每次添加新算法时，都必须添加新组合，不久之后 IANA 将管理 37 个不同的密码套件。

不好有两个原因。答：大量的可变性导致错误配置，使互联网用户容易受到攻击。B.这使配置 SSL 的所有事情变得更加混乱。实话实说，SSL / TLS 足够小众，即使是很多安全专业人员也不十分了解其具体细节。不适当的复杂性不被赞赏。

因此，为了减少一些麻烦，TLS 1.3 将支持的密码数量从 37 个减少到了 5 个，它还通过减少密码协商所涉及的协商数量（包括用于协商的密码套件）减少了密码套件的大小：

• 支持的证书类型
• 哈希函数（SHA1，SHA2 等）
• 消息验证码（Mac）功能
• 数字签名
• 密钥交换算法
• 对称加密密码
• 密码模式

这就是为什么您通常会在 TLS 1.2 密码套件中看到四种不同的算法的原因：

• 密钥交换
• 认证方式
• 批量密码
• 散列算法

TLS 1.3 密码套件仅包含两个可协商的密码：

• 批量密码
• HKDF（基于 KMAC 的提取和扩展密钥派生函数）哈希

IETF 取消了对除最安全，最有效算法之外的所有算法的支持，从而通过合并选择消除了混乱。最值得注意的是，有关密钥交换的整个选择已被删除。Diffie-Hellman 临时方案现在是城里唯一的游戏，这使得客户端可以在握手的第一部分中与客户端 Hello 一起发送其关键共享信息。RSA 加密已与所有其他静态密钥交换方案一起被完全删除。TLS 1.3 已成为完善的前向保密性的要求。

话虽如此，但 TLS 1.3 中存在 PFS 的潜在致命弱点……

零往返恢复– 0-RTT

零往返恢复或 0-RTT 是技术界一直在追求的东西，它与 TLS 1.3 一起使用。正如我们刚刚介绍的那样，TLS 握手历来是昂贵的：增加服务器负担并增加连接延迟。因此，缩小它的想法很有吸引力。0-RTT 只是通过存储有关客户端的一些秘密信息（通常是会话 ID 或会话票证）来实现这一目的，以供将来在双方连接时使用。

对于 0-RTT 带来的所有好处，它实际上也存在一些潜在的陷阱。它使客户端容易受到重放攻击，在这种情况下，设法以某种方式设法访问加密会话的攻击者可以获取 0-RTT 数据，该数据包括客户端的第一个请求，然后再次将其发送到服务器。这是另一天的话题。

更大的问题是 0-RTT 握手可能会通过提供解密旧会话的方式来破坏完美的前向保密性。尽管如此，要开发一个非常有用的功能并不是一件容易的事情，而且付出很小的代价。

保护更多的 TLS 1.3 握手

早期与握手相关的最大担忧之一就是以明文形式发送的握手数量。显然，这为问题打开了大门，因此，可以保证的握手越多越好。

在 TLS 1.2 握手中，握手的协商阶段不受保护，而是使用简单的 Mac 来确保没有人篡改所传输的内容。

包括了：

• 客户您好
  • 客户端支持的密码套件
• 服务器你好
  • 服务器选择的密码套件
  • 关键共享
  • SSL / TLS 证书
  • 电子签名

该 Mac 充当监视程序，但不是安全措施。它不能阻止它首先发生。您可能之前曾听说过降级攻击，这是执行降级攻击的媒介。如果服务器和客户端都支持过时的密码套件（如果您正在侦听连接，则可以轻松获得此信息），中间人攻击者可以将服务器选择的密码套件换成较弱的密码套件，是相互支持的。

降级攻击实际上并不是真正的危害，它们只是打开了其他已知漏洞的大门，这些漏洞影响了降级到的任何版本。这就是为什么它们特别危险。

TLS 1.3 握手对早期部分进行了数字签名，从而使更多的握手变得安全并减轻了降级攻击的风险，并且通过扩展，它们促进了许多攻击。这也提供了一种途径，可以通过验证私钥的拥有来更快，更有效地认证服务器。

现在，让我们看一下这些对 TLS 1.3 握手的升级如何在 SSL / TLS 握手本身的三个主要功能中发挥作用……

TLS 握手–协商密码套件

首先让我们更深入地研究密码套件。过去，我们已经详细介绍了密码套件，但是如果您不想阅读所有内容，我们将在此处给出一个缩写版本。密码套件是确定安全连接参数的算法的集合。

在任何连接开始时，第一个交互（客户端 Hello）是受支持的密码套件的列表。服务器寻找相互支持的最佳，最安全的选项，并以其选择来响应。您可以查看一个密码套件，并找出握手和连接的所有参数。

让我们看几个例子：

TLS 1.2 密码套件

这是 TLS 1.2 密码套件的示例，我对其进行了颜色编码以使其更易于阅读：

• TLS 是协议
• ECDHE 是密钥交换算法
• ECDSA 是认证算法
• AES 128 GCM 是对称加密算法
• SHA256 是哈希算法。

在上面的示例中，我们使用椭圆曲线 Diffie-Hellman 临时密钥进行密钥交换，并使用椭圆曲线数字签名算法进行身份验证。DH 也可以与 RSA（用作数字签名算法）配对以完成身份验证。

正如我们将在下一节中介绍的那样，在 TLS 1.3 握手中，密码套件的整个部分都已从协商中删除。

TLS 1.2 共有 37 个可用密码，尽管并非所有密码都是可取的。以下是最广泛支持的密码套件的列表：

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

TLS 1.3 密码套件

TLS 1.3 对其前身进行了无数的改进，考虑到它已经开发了大约十年，这是一个很好的选择。IETF 取消了对旧的过时算法的支持，并简化了所有流程，将整个握手过程从两次往返缩短到一次，并将密码套件的大小从四个协商 / 算法减少到两个。

支持的密码套件的数量也从 37 个减少到 5 个。这是 TLS 1.3 密码套件的示例：

• TLS 是协议
• AES 256 GCM 是具有关联数据的身份验证加密（AEAD）算法
• SHA384 是哈希键推导函数（HKFD）算法

我们已经知道我们将使用某种版本的 Diffie-Hellman 临时密钥交换，我们只是不知道参数，所以这意味着不再需要 TLS 1.2 密码套件中的前两个算法。这些功能仍在发生，而不再需要在握手期间进行协商。

从上面的示例中，您可以看到我们正在使用 AES 或高级加密标准作为对称批量密码。它使用 256 位密钥在 Galois 计数器模式下运行。我们使用 SHA384（SHA2 系列的一部分）作为 HKFD 哈希算法。如果您只用法语，那么我们将在下届会议中进行解释。

以下是五个受支持的 TLS 1.3 密码套件：

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256
• TLS_AES_128_CCM_8_SHA256
• TLS_AES_128_CCM_SHA256

那么，从 TLS 1.2 到 TLS 1.3 具体发生了什么变化？

重要的是要记住，定义 1.3 的两个最大优先事项是使其更安全并提高性能。为此，TLS 1.3 重新考虑了密钥生成，并逐步淘汰了静态密钥生成方案以及具有已知漏洞的方案。减少密钥生成 / 交换选项的数量使客户可以猜测密钥协议方案并在“客户问候”期间发送其密钥份额-这将是基于 Diffie-Hellman 临时方案的方案。

TLS 1.3 握手还改进了某些过程，例如消息身份验证和数字签名。我们刚刚介绍了如何使用 TLS 1.3 的数字签名来保护更多的握手。好吧，在使用 Mac 功能作为校验和以确保消息完整性和使用数字签名方案进行身份验证之前，使用 TLS 1.3 握手，整个握手都经过了数字签名，同时处理消息和服务器身份验证。

最后，除了淘汰旧的密钥生成 / 交换算法之外，TLS 1.3 还消除了旧的对称加密或批量加密密码。进行对称加密时，有两种类型的密码：分组密码和流密码。

分组密码对固定大小的分组中的数据进行加密。但是，此方法存在一些问题。如果您的消息不是密钥的确切长度，那么您必须做一些额外的工作。短消息需要填充，较大的消息需要分解，填充然后重新组合。有许多针对分组密码使用的填充的利用。如果您可以成功猜测填充，则可以更轻松地解密消息或猜测密钥。

另一种类型的密码是流密码，它以任意长度的伪随机序列（称为密钥流）对数据流进行加密。流密码是一种流行的选择，因为它们易于实现且速度很快。实际上，解决上述分组密码问题的最佳方法是将分组密码设置为像流密码一样工作，这称为计数器模式，最流行的示例是密码分组链接（CBC）。

在上面的示例密码套件中，我们在 Galois 计数器模式下看到了 AES_256。AES 是一种分组密码，在这种情况下，它使用 256 位密钥，并且在 Galois 计数器模式下作为流密码运行。

这是因为 TLS 1.3 除了弃用了对具有 RC4 之类已知漏洞的流密码的支持之外，还完全取消了分组密码。TLS 1.3 允许的唯一对称密码类型称为带有附加数据的身份验证加密（AEAD）密码，它将加密和消息身份验证（Mac）结合到一个功能中。

现在让我们谈谈密钥。

TLS 握手–身份验证

就像我们刚刚谈到的那样，就服务器上 SSL / TLS 握手的负担而言，最大的因素之一是所采用的非对称加密，特别是用于身份验证和密钥交换的加密。

从历史上看，密钥交换的两个主要选项是 RSA 和 Diffie-Hellman（DH），如今您经常会看到与椭圆曲线相关的 DH。这两种密钥交换方法之间有一些主要的相似之处，但也有一些根本的区别。

或者换一种说法，RSA TLS 握手与 ECDH 握手不同。

RSA vs. Diffie-Hellman / ECC –快速历史

正如我们之前所介绍的，RSA 利用素数分解和模块化算法。很难分解大质数–这是吞噬 CPU 资源的一部分。Diffie-Hellman 有时也称为指数密钥交换，它表示使用指数（除模块化算术外）-但实际上 Diffie-Hellman 本身根本不加密或解密任何东西。因此，将其称为加密方法而不是数学基础可能会引起误解。

略作一堂历史课可能会更容易更好地理解这一部分。早在 1976年，惠特菲尔德·迪菲（Whitfield Diffie）和马丁·海尔曼（Martin Hellman）便根据拉尔夫·默克尔（Ralph Merkle）的工作创建了一个密钥交换协议，两个人认为，后者也应在上面加上他的名字。

他们试图解决的问题是，即使攻击者正在监视它，如何在不安全的通道上安全地交换密钥。他们解决了这一部分，但是存在一个主要问题：DH 密钥交换缺少身份验证，因此无法验证连接另一端的参与方。

那基本上就是公钥密码术和 PKI 的诞生。在 Diffie 和 Hellman 提出他们的密钥交换协议后不久，RSA 密码系统的最早迭代就已经完成。Diffie 和 Hellman 考虑了公钥加密的概念，但还没有弄清楚实际的单向加密功能。

经过一整夜的 Manischewitz 吸纳和观察逾越节之后，是 Ron Rivest（RSA 中的 R）创造了最终成为 RSA 密码系统的概念。

在许多方面，RSA 是 DH 的精神继承者。它处理：

• 密钥生成
• 密钥交换
• 加密
• 解密

因此，显然 RSA 更具功能，它可以处理密钥交换和数字签名，这意味着它可以安全地交换密钥，而且还可以进行身份验证。这就是使用 RSA 密钥更大的原因之一：签名需要有足够的安全性。

虽然 RSA 处理身份验证和密钥交换，但 Diffie-Hellman 仅促进密钥交换。DH 系列有四种常见变体：

• 迪菲·赫尔曼（DH）
• Diffie-Hellman 临时（DHE）
• 椭圆曲线 Diffie-Hellman（ECDH）
• 椭圆曲线 Diffie-Hellman 临时（ECDHE）

同样，Diffie-Hellman 本身不进行任何身份验证。它需要与数字签名算法配对。因此，例如，如果您使用的是 ECDH 或 ECDHE，则大多数密码套件都会将其与椭圆曲线数字签名算法（ECDSA）或 RSA 配对。

TLS 1.2 握手-身份验证

正如我们刚刚谈到的那样，RSA 具有的其他功能（用于通过数字签名进行身份验证）需要更大的密钥。它们还必须足够长才能抵抗暴力攻击。同样，这些密钥的大小使计算它们，在握手期间使用它们进行加密和解密的成本相当昂贵。

另一方面，如果 Diffie-Hellman 不进行身份验证，那该怎么办？如前所述，DH 通常与基于椭圆曲线的加密技术配对使用，以标记团队身份验证和密钥交换功能。

ECC 具有与其所基于的椭圆曲线相对应的较小的密钥大小。有五种适合此情况的曲线：

• 192 位
• 224 位
• 256 位
• 384 位
• 521 位

但这并不是 ECC 公钥 / 私钥与 RSA 密钥之间的唯一区别。在 TLS 握手期间，它们还用于两个完全不同的目的。

在 RSA 中，公钥 / 私钥对既用于认证服务器，又用于交换对称会话密钥。实际上，成功使用私钥解密预掌握机密的身份即为身份验证。服务器。

对于 Diffie-Hellman，不使用公共 / 专用密钥对来交换对称会话密钥。当涉及 Diffie-Hellman 时，私钥实际上与随附的签名算法（ECDSA 或 RSA）相关联

RSA 认证

RSA 身份验证过程与其密钥交换过程纠缠在一起。或更恰当地说，密钥交换实际上是身份验证过程的一部分。

当向客户端提供服务器的 SSL 证书时，它将执行一系列检查以验证证书是否有效和受信任。

• 它使用公共密钥检查数字签名。
• 它检查证书链，确保证书来自其信任库中的根证书之一。
• 它检查证书的有效期以确保它没有过期。
• 它检查证书的吊销状态。

假设所有这些都令人满意，那么当客户端使用公共场所对主密码进行加密并将其发送到服务器时，将进行最终测试。

任何服务器都可以尝试通过任何 SSL / TLS 证书。毕竟，这些是公开可用的证书。因此，当客户端通过验证证书上的签名来启动身份验证过程时，这将测试证书本身的有效性。它需要知道服务器是首先进行签名的私钥的所有者。为此，需要查看私钥的作用。

因此，如果服务器可以解密主密码之前的密码（该密码最初是用关联的公共密钥加密的），然后使用它来计算主密码，则密码会通过。验证服务器是所使用的公钥 / 私钥对的所有者。

Diffie-Hellman 身份验证

使用 Diffie-Hellman 和 ECDSA / RSA 时，身份验证和密钥交换并排展开。这可以追溯到按键及其不同用途。RSA 公钥 / 私钥用于密钥交换和身份验证。对于 DH + ECDSA / RSA，非对称密钥对仅用于数字签名 / 认证部分。

客户端收到证书后，仍将通过标准检查运行：

• 检查证书上的签名
• 检查证书链
• 检查有效性状态
• 检查撤销状态

但是私钥的拥有证明检查是不同的。在 TLS 握手的“服务器密钥交换”部分（第 4 步）期间，服务器使用其私钥对客户端和服务器随机变量及其 Diffie-Hellman 参数进行加密。这用作服务器的数字签名，并且客户端可以使用关联的公共密钥来验证服务器是否是密钥对的合法所有者。

TLS 1.3 握手–身份验证

在 TLS 1.3 中，身份验证和数字签名仍然扮演着主要角色，但已从密码套件中删除了它们，以简化协商。这些都是在服务器端实现的，由于其安全性和普遍性，它们继续利用几种已经受支持的算法。TLS 1.3 中允许的三种主要签名算法是：

• RSA（仅签名）
• 椭圆曲线数字签名算法（ECDSA）
• 爱德华兹曲线数字签名算法（EdDSA）

EdDSA 是一种基于椭圆曲线的算法。与 TLS 1.2 握手不同，TLS 1.3 握手的身份验证部分未与实际的密钥交换本身联系在一起。而是与密钥交换和消息身份验证一起处理。还记得我们之前讨论过如何加密更多的握手吗？这就是开始支付股息的地方。

服务器不运行对称的 Mac 方案来验证握手的完整性，而是在返回带有部分密钥共享的服务器 Hello 时，对整个脚本哈希进行签名。

客户端接收服务器 Hello 所包含的所有信息，并运行标准的一系列检查以验证刚刚提供的 SSL / TLS 证书。这包括检查证书上的签名，然后根据添加到成绩单哈希的签名进行检查。

匹配证明服务器拥有私钥。

TLS 握手–密钥交换

我们将在一秒钟内深入了解密钥交换的实际细节，但是如果您仅从本节中删除一件事，应该是这样的：

目前，这似乎有点抽象，但希望在本讨论结束时不会。这对您了解握手至关重要。

RSA 密钥交换

称其为 RSA 密钥交换实际上是不正确的。这实际上是 RSA 加密。还记得以前我怎么说过 Diffie-Hellman 密钥交换实际上没有进行加密或解密吗？

好吧，RSA 使用非对称加密来创建会话密钥。与 DH 不同，公钥 / 私钥对扮演着重要角色。

它在运动中：

1. 客户端和服务器交换两个素数（x 和 y），称为随机数。
2. 客户端生成一个主密码（a），然后使用服务器的公钥对其进行加密并将其发送给服务器。
3. 服务器使用相应的私钥解密预主密钥，双方现在都具有所有三个输入，并将它们与某些伪随机函数（PRF）混合以生成主密钥。
4. 双方将更多的 PRF 与主密钥混合在一起，并得出匹配的会话密钥。

同样，这两者之间有很多相似之处：它们基本上完成了同一件事，都使用了模块化算法，而 RSA 甚至受到 DH 的启发。

但是，在 TLS 1.3 中，Diffie-Hellman 被宣布为明确的赢家。

Diffie-Hellman 密钥交换

在进入 Diffie-Hellman 密钥交换过程之前，让我们谈谈模块化算法。或者更适当地浏览。模块化算术是一种数学形式，其中数字在达到固定值（称为模数）后重新开始或环绕。所以，想想一个时钟。那是模块化算术的一个例子。

好的，这是 ECDH 的工作方式：

1. 客户端和服务器交换两个素数（x 和 y），称为随机数。
2. 一方选择了一个称为高级密码（a）的秘密数字，并计算：x ^a mod y。然后它将结果（A）发送给另一个。
3. 另一方也做同样的事情，选择自己的主控机密（b）并计算 x ^b mod y，然后将其值（B）发回。
4. 双方通过获取给定值并重复操作来完成这一部分。一个计算 B ^a mod y，另一个计算 A ^b mod y。

有一个模数指数的属性，该属性指示各方将达到相同的值，这是在连接期间用于对称加密的密钥。

TLS 1.2 握手– Diffie-Hellman 版

之前我们介绍了 RSA 版本的 TLS 1.2 握手。但是，现在我们已经了解了 DH 与 RSA 不同的方式，让我们看看基于 DH 的 TLS 1.2 握手的外观。

同样，这两种方法之间有很多相似之处，但是不是一种处理身份验证和密钥交换的算法，而是将任务划分了。相反，我们将使用 ECDHE 进行密钥交换，并使用 ECDSA 进行身份验证。

1. 与 RSA 一样，客户端以“ ClientHello”消息开头，该消息包括密码套件列表以及客户端随机数。
2. 服务器以自己的“ ServerHello”消息作为响应，该消息包括其选定的密码套件和服务器随机数。
3. 服务器发送其 SSL 证书，就像使用 RSA TLS 握手一样，客户端将运行一系列检查以验证证书是否有效，但是由于 DH 本身无法验证服务器，因此需要其他机制。
4. 为了提供身份验证，服务器获取客户端和服务器的随机性以及将用于计算会话密钥的 DH 参数，并使用其私钥对其进行加密。此功能用作数字签名，客户端将使用公共密钥来验证签名-并且服务器是密钥对的合法所有者-并使用其自己的 DH 参数进行响应。
5. 服务器使用“服务器已完成”消息结束此往返。
6. 与 RSA 不同，客户端不需要使用非对称加密将主密码前的机密发送到服务器，而是客户端和服务器使用之前交换的 DH 参数来获取主密码前的机密。然后，每个用户都使用它刚计算出的主前机密来相互到达会话密钥。
7. 客户端发送“ Change Cipher Spec”消息，通知另一方其已切换到加密。
8. 客户端发送最终的“完成”消息，以表明它已经完成了握手的一部分。
9. 同样，服务器发送“更改密码规范”消息。
10. 握手以服务器“已完成”消息结束。

DHE 与 RSA 相比有两个优势

密码学界偏爱使用 Diffie-Hellman Ephemeral 而不是 RSA 的主要原因有两个：完美的前向保密性和已知的漏洞。

完善的前向保密

之前您可能想知道 DHE 和 ECDHE 末尾的“短暂”一词的含义。短暂的字面意思是“短暂的生命”。这可能有助于您了解完全向前保密（PFS），这是某些密钥交换（有时称为密钥协议）协议的功能。PFS 确保即使在服务器证书的私钥受到破坏的情况下，也不会破坏交换的会话密钥。换句话说，它可以防止以前的会话被检索和解密。在发生 Heartbleed 错误之后，PFS 成为了首要任务。它是 TLS 1.3 的主要组成部分

RSA 密钥交换易受攻击

我们在几个月前就对此进行了深入探讨，但已知的漏洞可以利用旧版 RSA（PKCS＃1 1.5）中的密钥交换期间使用的填充。这可以追溯到加密方面。请记住，使用 RSA 时，必须使用公钥对预掌握机密进行加密，并使用私钥对它进行解密。但是，当将较小的 Pre-master 秘密放入较大的公共密钥中时，必须对其进行填充。在大多数情况下，如果您尝试猜测填充并将虚假请求发送到服务器，您会出错，并且 Oracle 会识别不一致并过滤掉。但是您很有可能会用足够多的请求轰炸服务器，以猜测正确的填充。这将导致服务器发送错误的已完成消息，从而缩小了主密码前机密的可能值。

这就是为什么在 TLS 1.3 中删除 RSA 以支持 Diffie-Hellman Ephemeral 的原因。

TLS 1.3 握手–密钥交换

在 TLS 1.3 的握手中，由于密钥交换方案的选择有限，客户端可以成功地猜测该方案，并在握手的打开部分（客户端 Hello）期间发送其部分密钥共享。

RSA 并不是 TLS 1.3 中提出的唯一密钥交换方案。还取消了非临时性 Diffie-Hellman 方案，以及一些不够安全的 Diffie-Hellman 参数。

参数不足是什么意思？好吧，在不参加数学课程的情况下，Diffie-Hellman 和大多数公钥密码系统的难度在于解决离散对数问题的难度。前面我们提到客户端和服务器在握手开始时便会生成随机数吗？对于任何人都不知道它们的情况都必须足够困难地进行计算，以免使整个方案变得无用。对于 TLS 1.3，已经消除了无法提供足够大参数的 Diffie-Hellman 方案。

总共只有五种可接受的 DH 方案用于密钥交换，足以确保仅使用安全算法，但又足够大以补偿可能导致未来几年中其中一种不安全的任何更改。  

1. 在 TLS 1.3 握手开始时，由于知道将使用 DHE 命名的密钥协商方案，因此客户端将基于猜测的 KA 方案的密钥共享与其客户端 Hello 一起使用。
2. 服务器接收到此信息，并在客户端正确猜出的情况下，与服务器 Hello 一起返回其自己的密钥共享部分。
3. 客户端和服务器都计算会话密钥。

这与 DH 1.2 在 TLS 1.2 握手中发生的情况极为相似，但在 TLS 1.3 中，密钥共享发生在握手中的更早时间。

修复 SSL / TLS 握手失败错误

对于绝大多数人来说，唯一一次 SSL / TLS 握手是无法解决的事情是它失败并且他们无法访问他们尝试访问的网站。Mozilla Firefox 对此尤为挑剔。

幸运的是，我们已经对此进行了广泛的介绍。无论是什么原因导致 TLS 握手错误，我们都知道如何解决。不幸的是，大多数这些问题都发生在服务器端，而普通的互联网用户却无力修复它们。

不过，如果您遇到 TLS 握手错误的麻烦，请查看有关如何解决该问题的指南。

在其中，我们涵盖：  

• 不正确的系统时间修复
• 浏览器配置错误
• 中间人干扰
• 协议不匹配
• 密码套件不匹配
• 错误的证书错误
• 启用 SNI 的服务器错误

既然您已经阅读了有关 SSL / TLS 握手的所有内容以及具体发生的情况，那么您可能会明白为什么其中某些错误可能会发生。例如，不匹配的密码支持，协议不匹配和 MITM 漏洞利用可能会影响协商加密参数的第一阶段。而错误的证书或系统时间错误可能会阻止身份验证。

我们可以告诉您的最重要的事情是，无论是什么原因导致 TLS 握手失败错误，请勿关闭 SSL / TLS 或禁用安全设置。不要让网站失去安全保障。如果您停止访问，他们会进行修复。但是不要冒险。

SSL / TLS 握手是一个迷人的过程，对于安全的 Internet 至关重要，但是它在大多数人从未考虑过的幕后迅速而安静地发生。