从原理到握手：深入剖析SSL/TLS协议与数字证书验证机制

A mind needs books like sword needs a whetstone. —— Game of Thrones《权力的游戏》

0 大纲

1 背景

互联网的基石是TCP/IP协议簇，它们负责将数据分割成小块（数据包）进行传输。这些数据包在全球网络中穿越成千上万公里，途经无数个节点。由于TCP/IP协议本身并不提供任何安全保证，任何能够访问通信链路的人都可以窃取甚至篡改数据包，而且可能不会被察觉。

那么，如何保障通信过程的数据安全呢？这正是SSL/TLS协议的使命。SSL全称为Secure Sockets Layer，TLS全称为Transport Layer Security。它们旨在为不安全的底层网络基础设施提供安全的通信通道，其位置介于TCP/IP协议之上，HTTP等应用层协议之下。

接下来，我们简单回顾一下SSL/TLS协议的发展历程。网景公司（Netscape）在1994年推出了HTTPS协议，使用SSL进行加密，这被视为SSL的起源。SSL先后经历了SSL 1.0、SSL 2.0、SSL 3.0三个版本，并成为了事实上的安全通信标准。

IETF后来对SSL进行了标准化，于1999年发布了第一版标准文档RFC 2246，并将其命名为TLS。从技术细节上看，TLS 1.0与SSL 3.0的差异非常微小。至今，TLS已发展出TLS 1.0、TLS 1.1、TLS 1.2、TLS 1.3等版本。出于安全考虑，前两个版本已被淘汰，目前广泛部署的是TLS 1.2和TLS 1.3。我们不必过于纠结SSL和TLS的名称差异，其本质是同一个技术在不同时期的称谓。在下文中，如无特别说明，将统一使用SSL/TLS来指代。

2 密码学知识

为了更好地理解SSL/TLS的工作原理，我们需要先掌握一些基础的密码学概念。

2.1 对称加密

对称加密也称为私钥加密。为了实现安全通信，通信双方（例如Alice和Bob）需要事先协商好一个共同的加密算法和一把相同的密钥。当Alice需要发送消息给Bob时，她用这把密钥加密数据。Bob收到密文后，使用同一把密钥进行解密。即使第三方截获了信道中的加密数据，由于没有密钥，也无法获知原始信息。只要Alice和Bob能确保密钥不泄露，他们就能持续进行安全通信。

RC4就是一种经典的对称加密算法。其加密过程基于异或运算，通信双方共享一个密钥流（密钥序列）。

2.2 非对称加密

非对称加密又称为公钥加密，它使用一对密钥：一个私钥和一个公钥。私钥必须严格保密，而公钥则可以公开给任何人。这一对密钥之间存在特殊的数学关系，从而赋予它们独特的用途。如果你用某人的公钥加密数据，那么只有对应的私钥才能解密，这保证了数据的机密性。反之，如果用私钥加密数据，任何人都可以用对应的公钥解密，这虽然不提供保密性，但却构成了数字签名的基础。

2.3 数字签名

数字签名是一种密码学方案，它使得验证电子消息或文档的真实性和完整性成为可能。借助非对称加密的特性，数字签名可以实现类似于现实生活中的手写签名功能。其核心思想是：发送方使用自己的私钥对消息的摘要（哈希值）进行加密生成签名；接收方则用发送方的公钥解密签名得到摘要，并与自己计算出的消息摘要进行比对，从而验证消息是否被篡改以及来源是否可信。

2.4 SSL/TLS与密码学

那么，SSL/TLS协议具体采用了哪种加密方式呢？可以用一句话概括：它利用非对称加密来安全地交换对称加密的会话密钥，随后使用该会话密钥进行高效的对称加密来传输实际的应用数据。此外，在验证服务器身份的真伪时，又会用到基于非对称加密的数字签名技术。接下来，就让我们一起深入SSL/TLS协议的详细握手交互过程。

3 SSL/TLS报文交互

SSL/TLS握手交互的整体流程如上图所示，各个报文的作用如下：

• Client Hello：客户端发送其支持的加密套件列表、压缩算法列表、扩展字段以及一个客户端随机数 random_c。
• Server Hello：服务端从客户端提供的列表中选择一个加密套件和压缩算法，同时生成一个服务端随机数 random_s 并返回。
• Certificate：服务端将其数字证书发送给客户端，客户端将验证该证书以确认服务器身份。
• Server Key Exchange：服务端发送基于所选加密套件（如椭圆曲线）生成的公钥，用于后续协商出对称加密的会话密钥。
• Server Hello Done：服务端通知客户端，其握手消息已全部发送完毕。
• Client Key Exchange：客户端发送其基于加密套件生成的公钥（同样是椭圆曲线公钥），用于与会话密钥协商。
• Change Cipher Spec：通知对端，此后所有的通信都将使用刚刚协商好的会话密钥进行加密。
• Encrypted Handshake Message：通信双方各自将之前所有握手消息的摘要，用协商好的会话密钥加密后发送给对方。这是第一条被对称加密的握手消息，用于验证握手过程是否完整且未被篡改。
• Certificate Request（可选）：如果服务器需要验证客户端身份，则会发送此报文。但在大多数场景（如普通网页浏览）中，服务器通常不要求客户端证书验证。

下面，我们结合使用 Wireshark 抓取的真实网络数据包，来逐一解析每一条SSL/TLS报文。这些报文来源于使用Chrome浏览器访问 www.huawei.com 的过程。

3.1 Client Hello

Client Hello 报文包含了客户端的TLS版本、随机数、支持的加密套件列表、压缩方法列表以及扩展字段等信息。

• Version：客户端支持的最高TLS协议版本（例如TLS 1.2）。
• Random Bytes：客户端生成的28字节随机数 random_c。它将与后续交换的随机数一起，用于生成最终的会话密钥。
• Cipher Suites：客户端支持的所有加密套件列表（本例中列出了17种），服务端将从中选择一个它也支持的套件。
• Compression Methods：客户端支持的压缩算法。
• Extension: server_name：服务器名称指示扩展，指明了客户端想要访问的服务器域名（本例为 www.huawei.com）。
• Extension: application_layer_protocol_negotiation：客户端支持的应用层协议（如HTTP/2）。

3.2 Server Hello

Server Hello 报文包含了服务端做出的选择。

• Version：服务端决定使用的TLS版本。
• Random Bytes：服务端生成的随机数 random_s。结合客户端的 random_c，现已有两个随机数用于增强最终密钥的随机性。
• Cipher Suite：服务端最终选定的加密套件（本例为 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256）。这些套件名称均有公开的RFC文档规范。
• Compression Method：服务端选择的压缩算法（本例为 NULL，即不压缩）。压缩功能通常由应用层处理。

3.3 Certificate

Certificate 报文主要用于服务端向客户端发送其数字证书链。从抓包可以看到，服务器下发了三个证书：服务器自身证书、中间证书颁发机构证书 和 根证书颁发机构证书。客户端需要逐级验证这些证书，从而建立信任链。关于数字证书的细节，我们将在下一章详细讨论。

3.4 Server Key Exchange

Server Key Exchange 报文的核心内容是服务端生成的椭圆曲线公钥（Pubkey）。为了防止此公钥在传输中被篡改，服务端会用其证书对应的私钥对该公钥及相关参数进行数字签名。客户端收到后，使用服务端证书中的公钥验证签名。验证通过后，客户端结合 random_c、random_s 以及这个可信的服务器公钥，即可开始计算最终的对称会话密钥。

3.5 Server Hello Done

Server Hello Done 是一个简单的信号报文，告知客户端服务端的握手消息已全部发送完毕，等待客户端的下一步响应。

3.6 Client Key Exchange

Client Key Exchange 报文的作用与 Server Key Exchange 相对应。客户端在此报文中发送自己生成的椭圆曲线公钥给服务端。服务端结合之前交换的 random_c、random_s 以及这个客户端公钥，也能计算出相同的对称会话密钥。至此，双方都拥有了进行加密通信所需的密钥材料。

3.7 Change Cipher Spec

Change Cipher Spec 报文是一个协议信号，通知通信对端：“从下一条消息开始，我将使用刚刚协商好的加密套件和会话密钥，对所有后续的记录层数据进行加密。” 这意味着握手协商阶段已近尾声，安全通道即将建立。

3.8 Encrypted Handshake Message

Encrypted Handshake Message 是第一条使用协商好的会话密钥进行加密的握手消息。其内容是之前所有握手消息（收发双方）的哈希摘要。对方收到后，会先解密，然后验证该摘要。如果验证成功，则证明整个握手过程完整且未被篡改，双方协商的密钥一致。至此，SSL/TLS握手正式完成，接下来便可以开始传输受加密保护的应用数据（如HTTP请求）。

4 数字证书

在3.3小节中，我们提到了数字证书，本章将对其进行深入解析。数字证书是在互联网通信中用于标识和验证通信方身份的数字文件，我们可以用它来确认对方的真实身份。

4.1 基本内容

数字证书的申请与验证流程如下图所示。

RFC 5280 标准定义了X.509数字证书的格式。一个标准的数字证书包含以下主要字段：

• 版本号：证书格式的版本，目前广泛使用的是版本3。
• 序列号：由证书颁发机构为每个证书分配的唯一标识符，用于追踪和撤销证书。
• 签名算法：CA用来对证书进行签名的算法，如 sha256WithRSAEncryption。
• 颁发者：签发此证书的证书颁发机构的标识信息。
• 有效期：证书有效的起止时间。
• 主体：证书持有者（通常是服务器或个人）的标识信息。
• 主体公钥信息：证书持有者的公钥及其使用的算法（如RSA、ECC）。
• 扩展：可选字段，包含更丰富的信息，例如：
  • 基本约束：指明此证书是否属于CA（即可用于签发其他证书）。
  • 密钥用途：限定此证书公钥的用途（如数字签名、密钥加密）。
  • 主题备用名称：允许证书关联多个域名或IP地址。
  • CRL分发点：证书吊销列表的获取地址。

下图是通过Wireshark解析的访问 www.bing.com 时收到的服务器证书详情。

4.2 在SSL/TLS中，为什么需要数字证书？

回忆一下SSL/TLS的加密过程：使用非对称加密交换对称密钥，再用对称密钥加密数据。这里隐含了一个至关重要的前提：你必须确信正在与你通信的对端就是你所期望的那个实体。例如，当你进行网上银行交易时，必须确保访问的网站确实是银行官方的服务器，而不是一个伪造的钓鱼网站。

数字证书正是为了解决这个“身份认证”问题而存在的。当浏览器连接一个HTTPS网站时，服务器会在握手过程中出示其数字证书。浏览器会验证该证书：

1. 是否由受信任的CA签发？
2. 证书中的域名是否与正在访问的网站域名一致？
3. 证书是否在有效期内？
4. 证书是否已被吊销？

如果任何一项验证失败，浏览器就会发出安全警告，阻止用户继续访问。网站运营商需要向公认的CA机构申请并购买数字证书。证书的内容（包含网站信息和公钥）由CA的私钥进行数字签名。由于CA的私钥是其最高机密（通常离线保存），极难泄露，因此伪造或篡改一个能通过验证的数字证书是极其困难的。

4.3 什么是证书链？

互联网上有数以亿计的服务器需要证书，单靠一家或几家顶级CA直接为所有服务器签发证书是不现实的。为了高效管理，CA体系采用了分层信任模型，主要分为根CA和中间CA。

• 根CA：处于信任链的顶端，其证书是自签名的，并被预先内置在操作系统或浏览器的信任存储中。根CA通常不直接为终端服务器签发证书，而是负责签发和认证中间CA的证书。
• 中间CA：由根CA授权，负责具体为最终用户（服务器）签发证书。即使中间CA的私钥不慎泄露，也只需吊销该中间CA的证书，而无需动摇整个根CA的信任基础。

这样，服务器证书、中间CA证书和根CA证书就形成了一个证书链。验证时，浏览器用内置的根CA公钥验证中间CA证书的签名，再用中间CA证书的公钥验证服务器证书的签名，层层递进，建立信任。

操作系统和浏览器会内置一个受信任的根证书列表。下图展示了Windows系统中存储的部分受信任的根证书。

5 总结

• SSL和TLS是同一安全协议在不同发展阶段的名称，本质相同，现在应优先使用TLS（如TLS 1.2/1.3）。
• 非对称加密使用公钥和私钥对，能够实现加密和数字签名两大核心功能，是建立安全信道和身份验证的基础。
• SSL/TLS握手过程的核心可概括为：利用非对称加密（和数字签名）安全地协商出一个共享的对称会话密钥，后续所有应用数据均使用该密钥进行高效的对称加密传输。
• 数字证书是SSL/TLS实现身份认证的关键。服务器通过Certificate报文下发其证书链，客户端通过验证证书链来确认服务器的真实身份。
• 证书链是一种分层信任模型（根CA -> 中间CA -> 服务器），它解决了大规模证书颁发和管理的难题。验证时从操作系统信任的根证书开始，逐级向下验证，最终建立对服务器证书的信任。

希望这篇从背景、密码学基础到握手流程和证书机制的系统剖析，能帮助你真正搞懂SSL/TLS协议。如果你想了解更多关于网络协议或其他底层技术的深度内容，欢迎持续关注云栈社区的分享。