SSL/TLS 握手过程详解

1、SSL/TLS 历史发展

可以理解TLS是SSL的升级版本。

SSL 的第一个可用版本——SSL 2.0——由 Netscape 设计并于 1995 年发布。然而，SSL 2.0 中发现了漏洞，要求 Netscape 设计一个更好、更安全的版本。 一年后SSL 3.0问世。 SSL 3.0 仍然被广泛使用，直到 2014 年秋天，Google 安全团队发现了一个重大安全漏洞。

TLS 1.0 于 1999 年首次被设计为 SSL 3.0 的另一个协议升级。虽然差异并不显着，但它们足够重要，以至于 SSL 3.0 和 TLS 1.0 无法互操作。 SSL 3.0 被认为不如 TLS 安全。

TLS 1.1 创建于 2006 年，TLS 1.2 于 2008 年发布。TLS 1.2 是目前使用的版本，TLS 1.3 在2018年8月发布。 与任何其他协议升级一样，TLS 被认为比 SSL 3.0 更安全，因为每个版本都增加了阻止利用和缓解漏洞的措施。

正如您所看到的，SSL 3.0 多年来一直存在安全问题，这需要更安全的解决方案。 与任何其他技术更新一样，每个版本都存在差异，但最终用户的最终产品是相同的。 当人们提到 SSL 或 TLS 时，他们通常谈论的是同一件事，除非他们指的是协议的不同版本。

SSL 和 TLS 这两个术语可以互换使用，因为这些协议以相同的方式加密信息，并且在最基本的层面上执行相同的操作。 TLS 是 SSL 的简单升级且更安全的版本。 TLS 现已在整个网络中广泛使用，并且是交易安全的首选。 可以在服务器上同时启用所有版本的 SSL 和 TLS。

所有数字证书均与 SSL 和 TLS 协议兼容。 但是，由于 SSL 3.0 中存在显着漏洞，DigiCert 建议您在服务器上完全禁用 SSL 3.0（如果您尚未这样做）。 通过禁用 SSL 3.0 并启用 TLS，管理员将获得相同级别的加密且不会出现漏洞。 如果您不确定启用了哪些 SSL/TLS 版本，您可以使用证书检查器进行漏洞扫描、分析等。

2、SSL/TLS握手过程概览

https连接有两个方面组成：客户单和服务器端。
客户端负责发起连接，服务端接受连接。客户端和服务端即是握手的两方。
SSL/TLS 握手的目的是执行安全连接所需的所有加密工作。 这包括验证正在使用的 SSL 证书并生成加密密钥。

SSL/TLS 握手的目的是执行安全连接所需的所有加密工作

TLS 握手完成了 3 个主要任务：

1. 协商交换密码套件和参数
2. 验证一方或双方的身份
3. 创建/交换对称会话密钥

2.1、协商交换密码套件和参数

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

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

2.2、验证一方或双方的身份

收到证书后，客户会检查以确保证书是“真实的”。 这是极其重要的一步。 要真正拥有安全的连接，您不能只是加密数据，您还需要知道数据被发送到正确的网站/组织。 SSL/TLS 证书提供该身份验证。 但他们的做法取决于所使用的密码套件。

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

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

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

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

如果使用另一种类型的密码系统（例如 ECC），则此过程会发生变化，但始终会检查所有权证明。

2.3、创建/交换对称会话密钥

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

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

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

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

整个 SSL 握手发生在几百毫秒内，并且全部在幕后进行。 这是 HTTPS 连接中必须发生的第一件事，甚至在网页加载之前。

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

在 TLS 1.3 之前，每次重新访问站点时，握手都会再次发生。 TLS 1.3握手支持0 RTT，即零往返时间恢复，大大提高了回访者的速度。 此前，许多服务器为了效率和速度而实施了“恢复”过程，但 0 RTT 将其提高到 11。

3、TLS 1.2 握手过程详解

TLS 1.2 在 2008年发布,TLS 1.2 是目前使用广泛的版本。

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

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

这些步骤如下图所示，左侧是客户端，右侧是服务器。

1、第一条消息称为“ClientHello”。 此消息列出了客户端的功能，以便服务器可以选择两者用于通信的密码套件。 它还包括一个随机挑选的大素数，称为“客户端随机数”

2、服务器礼貌地回复“SeverHello”消息。 在此消息中，它告诉客户端它从提供的列表中选择了哪些连接参数，并返回自己随机选择的质数（称为“服务器随机数”）。 如果客户端和服务器不共享任何共同功能，则连接将无法成功终止。

3、在“Certificate”消息中，服务器将其 SSL 证书链（包括其叶证书和中间证书）发送给客户端。 为了向连接提供身份验证，SSL 证书由 CA 签名，这允许客户端验证证书是否合法。 收到证书后，客户端会执行多项检查来验证证书。 这包括检查证书的数字签名、验证证书链以及检查证书数据是否存在任何其他潜在问题（证书过期、域名错误等）。 客户端还将确保服务器拥有证书的私钥。 这是在密钥交换/生成过程中完成的。

4、这是一条可选消息，仅对于需要服务器提供附加数据的某些密钥交换方法 (Diffie-Hellman) 才需要。

5、“Server Hello Done”消息告诉客户端它已经发送了所有消息。

6、然后，客户端提供其对会话密钥的贡献。 此步骤的细节取决于在初始“Hello”消息中决定的密钥交换方法。 在此示例中，我们将研究 RSA，因此客户端将生成称为预主密钥的随机字节字符串，然后使用服务器的公钥对其进行加密并传输。

7、“Change Cipher Spec”消息让对方知道它已经生成了会话密钥并将切换到加密通信。

8、然后发送“Finished”消息以表明客户端的握手已完成。 Finished 消息已加密，并且是受会话密钥保护的第一个数据。 该消息包含允许各方确保握手未被篡改的数据 (MAC)。
9、现在轮到服务器做同样的事情了。 它解密预主密钥并计算会话密钥。 然后，它发送“更改密码规范”消息以指示它正在切换到加密通信。

10、服务器使用刚刚生成的对称会话密钥发送“完成”消息，它还执行相同的校验和来验证握手的完整性。

经过以上这些步骤后，SSL 握手就完成了。 双方现在都拥有会话密钥，并将开始通过加密且经过身份验证的连接进行通信（数据传输）。

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

通过实际抓包看TLS 1.2 的握手过程

4、TLS 1.3 握手过程详解

让我们首先看一下正在运行的 TLS 1.3 握手，然后我们将深入研究已做出的改进。 如您所见，TLS 1.3 握手时间明显短于其前身。

1、与 TLS 1.2 握手一样，客户端 Hello 消息会启动握手，但这次它包含了更多信息。 TLS 1.3 将支持的密码数量从 37 个减少到 5 个。我们稍后会详细了解这意味着什么，但在握手的上下文中，这意味着客户端可以猜测将使用什么密钥协商/交换协议 除了从它猜测的任何协议发送其密钥共享之外。

2、服务器将用自己的 Server Hello 消息进行响应，同样，服务器非常有礼貌。 与 1.2 握手一样，此时它也会发送证书。 并且，如果客户端猜对了并且两者已就相同的 AEAD 协议达成一致，则服务器会发送自己的密钥共享部分，计算会话密钥并以服务器完成消息结束。

3、现在已经拥有所有相关信息，客户端将验证 SSL 证书并使用两个密钥共享来计算自己的会话密钥副本。 完成后，它会发送自己的 Finished 消息。

5、The TLS 1.2 handshake – Diffie-Hellman Edition

之前我们介绍了 TLS 1.2 握手的 RSA 版本。 但现在我们已经了解了 DH 与 RSA 的不同之处，让我们看看基于 DH 的 TLS 1.2 握手是什么样子的。

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

1、与 RSA 一样，客户端以“ClientHello”消息开始，其中包含密码套件列表以及客户端随机数。

2、服务器用自己的“ServerHello”消息进行响应，其中包括其选择的密码套件和服务器随机数。

3、服务器发送其 SSL 证书，就像 RSA TLS 握手一样，客户端将运行一系列检查来验证证书是否有效，但由于 DH 本身无法验证服务器，因此需要额外的机制。

4、为了提供身份验证，服务器获取客户端和服务器的随机数以及将用于计算会话密钥的 DH 参数，并使用其私钥对其进行加密。 这起到了数字签名的作用，客户端将使用公钥来验证签名——并且服务器是密钥对的合法所有者——并用自己的 DH 参数进行响应。

5、服务器以“Server Hello Done”消息结束此往返。

6、与 RSA 不同，客户端无需使用非对称加密将预主密钥发送到服务器，而是客户端和服务器使用之前交换的 DH 参数来获得预主密钥。 然后双方使用刚刚计算出的预主密钥来相互得出会话密钥。

7、客户端发送“Change Cipher Spec”消息，通知对方切换到加密。

8、客户端发送最终的“完成”消息，表明它已经完成了握手的部分。

9、同样，服务器发送“更改密码规范”消息。

10、握手以服务器“完成”消息结束。

参考链接: https://www.thesslstore.com/blog/explaining-ssl-handshake/#comments