一文详解SSL/TLS协议

技术文档

1 发展历程

2 协议原理

2.1 网络通信模型

2.2 TLS协议原理

3 TLS握手

3.1 概述

3.2 TLS 握手具体步骤

3.3 wireshark抓包解析

4 TLS应用

5 TLS 1.3协议

5.1 TLS 1.3加密套件

5.2 TLS1.3握手协议

6 SSL证书

6.1 工作原理

6.2 证书类型

6.3 获得证书

SSL/TLS（Secure Sockets Layer/Transport Layer Security）是一种用于保护网络通信安全的加密协议，通常用于Web浏览器和Web服务器之间的安全通信

SSL/TLS协议使用对称加密、非对称加密、数字证书、数字信封以及密钥协商等技术，实现数据的加密、身份验证、数据完整性验证等功能

1 发展历程

TLS协议：（Transport Layer Security）是用来保证网络通信安全的密码学协议，被广泛应用在电子邮件、即时通信、VoIP以及HTTPS协议中，其中HTTPS最为常见

TLS协议能够保证通信消息的隐私性、消息完整性以及通信实体的身份鉴别

TLS协议（前身SSL）从1986左右开始，经过了多个版本的发展：

SSL协议作为TLS的前身，由于存在诸多安全漏洞，已经在2015全部被废弃
TLS协议也经过了多个版本的迭代，其中TLS1.0和TLS1.1由于在协议中使用了MD5、SHA-1等因素，在2021年相继被废弃
TLS1.2解决了之前版本的安全问题。已成为使用最广泛的TLS协议，据统计99%以上的网站支持了TLS1.2
TLS1.3移除了不安全的密码算法，并在密码算法支持和握手效率上等方面进行了显著优化

2 协议原理

2.1 网络通信模型

网络安全通信模型：

无TLS协议保护

有TLS协议保护

在网络通信过程中，如果未使用tls保护，会存在通信消息被窃听、篡改的风险，同时攻击者可以伪造身份进行通信；而使用了TLS协议，能够保证消息的隐私性、完整性和通信实体身份实体的真实性

2.2 TLS协议原理

TLS协议包含多个子协议：

应用数据协议(Application Data Protocol): 用于密文传输
告警协议(Alert Protocol)：在TLS连接中，如果发生了错误或异常情况，TLS协议会使用Alert Protocol发送警报信息，以通知对方发生了什么问题
握手协议(Handshake Protocol)：用于密钥协商
更改密码规范协议(Change Cipher Spec Protocol): 在TLS连接中通知对方加密算法已经切换
记录协议(Record Protocol): 在TLS连接中对数据进行分段、压缩、加密和认证，上面4个子协议的数据都会通过Record Protocol进行处理，然后再通过网络传输

TLS协议使用公钥加密和对称加密两种方式来保证通信的安全性：

公钥加密：在通信开始时，客户端和服务器之间进行握手，验证对方的身份，并交换加密所需的公钥信息。使用服务器的公钥加密的方式，客户端可以安全地将对称加密所需的密钥传输给服务器，以便后续通信的加密和解密

对称加密：一旦握手阶段完成，客户端和服务器之间使用共享的密钥进行通信，对称加密算法更高效，因此在实际通信中使用它来加密数据。服务器和客户端使用该密钥进行数据加密和解密，确保数据的机密性和完整性

TLS协议在应用层和传输层之间建立了一个安全的通道，可以在许多应用层协议（如HTTP、SMTP、FTP）之上使用，它已被广泛应用于Web浏览器与服务器之间的安全网页传输，即HTTPS（HTTP over TLS/SSL）

3 TLS握手

3.1 概述

在数据传输过程中，通常通过 TLS/SSL 连接对数据进行加密，而建立这样的连接需要进行 TLS 握手（TLS Handshake）

TLS 握手是启动 TLS 通信会话的关键步骤，在握手过程中，通信双方（客户端和服务器）交换信息，互相验证身份，协商使用的加密算法，并生成一致的会话密钥

TLS 握手确保了通信的机密性和完整性，并为后续的数据传输提供加密保护

当用户访问一个使用 HTTPS 的网站时，浏览器会先定位网站的源服务器，并随后发起 TLS 握手，类似地，在所有涉及 HTTPS 的通信（如 API 调用、DNS over HTTPS 查询）中，TLS 握手同样会发生

在建立 TCP 连接（完成 TCP 握手）后，TLS 握手随即开始，以确保通信加密和安全性

在 TLS 握手过程中，客户端与服务器将共同完成以下关键步骤：

协商 TLS 版本（如 TLS 1.0、1.2、1.3 等）
选择密码套件，确定加密算法及密钥交换方式
验证服务器身份，通过服务器的公钥和 SSL 证书颁发机构的数字签名确保其可信度
生成会话密钥，用于在握手完成后进行对称加密通信

3.2 TLS 握手具体步骤

主要包括以下几个阶段：

1.客户端问候（Client Hello）

客户端向服务器发起通信请求，并在此过程中提供：

支持的 TLS 版本
支持的密码套件列表
随机数（Client Random）

2.服务器问候（Server Hello）

服务器响应客户端请求，并进行以下操作：

确保 TLS 版本兼容
选择一个客户端支持的密码套件
发送服务器证书
生成并发送服务器随机数（Server Random）
发送公钥

3.证书验证

客户端通过证书颁发机构（CA）验证服务器证书的有效性，确保服务器身份的真实性

4.预主密钥（Pre-Master Secret）

客户端生成一个预主密钥，使用服务器的公钥加密后发送给服务器，由于只有服务器拥有对应的私钥，因此只有服务器可以解密该密钥，从而增强通信安全性

5.会话密钥生成

服务器解密预主密钥，客户端和服务器根据客户端随机数、服务器随机数和预主密钥计算出相同的会话密钥，用于后续通信加密

6.完成握手

双方互相发送“握手完成”消息，并验证生成的密钥是否匹配，握手完成后，会话密钥将用于加密和解密客户端与服务器之间传输的数据

3.3 wireshark抓包解析

以服务器单向认证为例, 并结合wireshark抓包，分析TLS握手协议详细流程：

概览

从抓包结果可以了解到：

使用的TLS版本为TLSv1.2
握手过程中的关键字有：

- Client Hello- Server Hello- Certificate, Server Key Exchange, Server Hello Done- Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message- New Session Ticket, Change Cipher Spec, Encrypted Handshake Message- Application Data

客户端 -> 服务端：Client Hello

可以看到：

握手协议消息类型为Client Hello
客户端支持的TLS版本为TLS 1.2 (0x0303), 其中0x0303为内部版本号，如TLS1.3为0x0304
客户端生成的32字节随机数
客户端支持的加密套件，优先级从上到下

服务端 -> 客户端：Server Hello

可以看到：

握手协议消息类型为Server Hello
服务端确定的TLS版本为TLS 1.2
服务端生成的32字节随机数
服务端确定的加密套件为TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，该加密套件各字段用途如下：

服务端 -> 客户端：Certificate, Server Key Exchange, Server Hello Done

可以了解到，本次通信tcp包携带了3个tls握手协议包：

1. Certificate消息：

服务端证书，id-at-commonName=*.pku.edu.cn\"表示为北京大学服务器网站
证书链，该证书链包含根证书id-at-commonName=DigiCert Global Root CA, 该根CA为知名签发机构（隶属于美国）

2. Server Key Exchange消息：

服务端DH参数，参与生成主密钥
服务端签名，用于验证消息有效性

3. Server Hello Done消息：通知客户端加密套件协商结束

客户端 -> 服务端：Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message

可以了解到，本次通信tcp包携带了3个tls握手协议包：

1. Client Key Exchange消息

客户端DH参数，参与生成主密钥

2. Change Cipher Spec消息：通知服务端，客户端已准备好进行密文通信

3. Encrypted Handshake Message消息：同Finished消息（密文形式）

服务端 -> 客户端： New Session Ticket, Change Cipher Spec, Encrypted Handshake Message

可以了解到，本次通信tcp包携带了3个tls协议包：

New Session Ticket消息: 服务器在TLS握手过程中生成一个新的会话票据（Session Ticket），并将其发送给客户端，客户端可以在后续的TLS握手中使用该会话票据来恢复之前的会话状态，从而避免了重新进行完整的TLS握手流程，提高了握手的效率和安全性
Change Cipher Spec消息：通知客户端，服务端已准备好进行密文通信
Encrypted Handshake Message消息：同Finished消息（密文形式）

客户端服务端：Application Data

可以看到：

该消息不属于TLS握手协议，属于Application Data Protocol，是TLS协议的另一个子协议
Encrypted Application Data: 所有应用数据都被加密传输

4 TLS应用

TLS协议广泛应用于互联网中，以便保护通信实体信息交换的安全性

TLS在网络协议中的位置：

TLS协议工作在传输层和应用层之间

TLS协议一种常见的应用就是：

HTTPS = HTTP + TLS  #用于保护http请求和响应的数据安全性

此外，在gRPC中的应用，我们称之为gRPCs

5 TLS 1.3协议

tls1.2作为主流的网路安全协议，被广泛应用，但tls1.2仍存在一些安全隐患和性能问题，如：

MD5、SHA-1算法已被破解，不再安全
RSA密钥协商存在安全隐患，不支持前向安全
加密模式CBC存在Padding Oracle攻击的潜在风险
tls1.2在进行密钥协商时，需要2-RTT，效率较低等

为了解决TLS1.2存在的问题，tls1.3协议应运而生，tls1.3废弃了一些存在安全隐患的加密套件，并新增了一些安全级别较高的加密套件，同时在性能上，TLS1.3能够实现1-RTT密钥协商，以及0-RTT连接恢复（tls1.2连接恢复需要1-RTT），握手效率提升了1倍左右

RTT = Round Trip Time，表示交互次数

5.1 TLS 1.3加密套件

TLS1.3支持的加密套件如下：

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256

从加密套件上看，与tls1.2相比（如：tls_ecdhe_ecdsa_with_aes_128_gcm_sha256）, tls1.3协议支持的加密套件不再包含密钥协商算法和签名算法，仅包含加密和摘要算法，这是因为在TLS 1.3中：

所有密钥协商默认使用ECDHE算法，这意味着在握手过程中，客户端和服务器都使用椭圆曲线密钥协商来生成共享的对称密钥，椭圆曲线Diffie-Hellman密钥交换提供了强大的安全性和前向保密性，可以抵抗主动攻击和被动监听
TLS1.3允许客户端和服务器选择适当的签名算法，以实现身份验证和握手完整性的保护。这种灵活性和可扩展性是TLS 1.3设计的一部分，以提供更安全和可靠的通信
TLS1.3仅支持AEAD带认证的加密算法，不再支持CBC模式的加密算法，提高了加密数据的安全性

尽管TLS1.3默认使用ECDHE作为密钥协商算法，但仍然可以通过配置选择其他密钥交换算法，如基于RSA的密钥交换（RSA Key Exchange）

然而，在TLS 1.3中，推荐使用ECDHE来获得更高的安全性和性能

5.2 TLS1.3握手协议

TLS1.3协议握手流程如下

+表示在先前提到的消息中发送的值得注意的扩展

*表示可选或情境依赖的消息/扩展，不一定总是发送

{}表示使用从 [sender]_handshake_traffic_secret 导出的密钥保护的消息

[]表示使用从 [sender]_application_traffic_secret_N 导出的密钥保护的消息

握手可以看作有三个阶段：

密钥交换（Key Exchange）：建立共享的密钥材料并选择加密参数，此阶段之后的所有内容都是加密的
服务器参数（Server Parameters）：建立其他握手参数（如客户端是否经过身份验证、应用层协议支持等）
身份验证（Authentication）：对服务器（以及可选地对客户端）进行身份验证，并提供密钥确认和握手完整性

密钥交换（Key Exchange)

在密钥交换阶段，客户端发送ClientHello消息，其中包含：

随机的nonce（ClientHello.random)
所提供的协议版本
一组对称密码算法/HKDF哈希对
Diffie-Hellman共享密钥(在\"key_share\"扩展中)、预共享密钥标签集合(在\"pre_shared_key\"扩展中), 或两者都有
可能的其他扩展

服务器处理ClientHello并确定适当的加密参数，然后通过ServerHello响应，指示协商的连接参数

ClientHello和ServerHello的组合确定了共享密钥

如果使用了(EC)DHE密钥协商，则ServerHello包含服务器临时生成DH公钥的key_share扩展
如果使用PSK密钥协商，则ServerHello包含一个pre_shared_key扩展，指示选择了客户端提供的PSK中的哪一个
请注意，实现可以同时使用(EC)DHE和PSK，在这种情况下ServerHello将提供两个扩展

服务器参数(Sever Parameters)

然后，服务器发送两个消息以建立服务器参数：

EncryptedExtensions：对于不需要确定密码参数的ClientHello扩展的响应。
CertificateRequest：如果需要客户端身份证书验证，则为该证书的所需参数。如果不需要客户端身份验证，则省略此消息

身份验证（Authentication)

最后，客户端和服务器交换身份验证消息。具体来说：

Certificate：服务端证书和证书相关的扩，如果不使用证书进行身份验证，则服务器会省略此消息；如果使用原始公钥[RFC7250]或缓存的信息扩展[RFC7924]，则此消息将不包含证书，而是包含与服务器的长期密钥对应的其他信息
CertificateVerify：使用Certificate消息中公钥对应的私钥对整个握手消息进行签名，如果不通过证书进行身份验证，则省略此消息
Finished：对应整个握手的消息认证码MAC，此消息提供密钥确认，将客户端/服务端的身份与交换的密钥绑定，并在PSK模式下还进行握手身份验证

收到服务器的消息后，客户端通过其身份验证消息（即Certificate和CertificateVerify（如果有请求）和Finished）做出响应此时，握手过程完成，客户端和服务器生成了记录层所需的密钥材料，以通过加密来交换应用层数据，在发送Finished消息之前，不得发送应用数据

6 SSL证书

SSL证书通过加密算法保证用户和网站或两个系统之间传输的数据是加密，这些数据可能包括用户名、地址、信用卡号码或其他财务详细信息等敏感信息

6.1 工作原理

SSL证书的工作原理如下：

浏览器或服务器尝试连接到一个受SSL保护的网站（即Web服务器）
浏览器或服务器要求Web服务器进行身份验证
Web服务器以其SSL证书的副本作为响应发送给浏览器或服务器
浏览器或服务器检查是否信任该SSL证书，如果信任，则向Web服务器发送信号进行确认
Web服务器随后返回一个数字签名的确认信息以开始SSL加密会话
加密的数据在浏览器或服务器和Web服务器之间共享

6.2 证书类型

SSL证书有几种不同的类型，每种类型具有不同的身份验证级别和用途。以下是一些常见的SSL证书类型：

域名验证证书（DV）：最基本的SSL证书类型，验证域名的所有权，确保证书持有者拥有指定的域名，域名验证证书通常是最便宜和最快速获得的证书，然而只验证了域名的真实性

组织验证证书（OV）：验证了域名的所有权，并对证书持有者的组织身份进行验证，CA会检查域名持有者的组织信息，如名称、地址和联系信息等，OV证书提供了更高的可信度，显示了拥有者的组织信息

增强验证证书（EV）：最高级别的SSL证书，提供了最大的可信度和认可，EV证书旨在验证网站所有者的合法性和业务身份，持有EV证书的网站在浏览器地址栏中显示绿色的地址栏和公司名称，以增强用户信任度，获取EV证书需要进行更严格的验证流程和文件提交

除了上述常见的证书类型，还有一些特殊用途的SSL证书，如：

通配符SSL证书：允许人们在单个证书上保护基本域和无限子域，可以作用于一个域名以及其所有的子域名，提供灵活性和便利性，一个通配符证书可以适用于*.example.com，以用来保护www.example.com、mail.example.com、blog.example.com等所有相关的子域名

多域名SSL证书：可以用于保护多个不同的域名，一个证书可以涵盖多达数十个域名或子域名，它适用于企业拥有多个域名或网站的情况，可简化管理和成本

6.3 获得证书

要获得SSL证书，需要遵循以下步骤：

首先，选择合适的SSL证书类型——根据网站需求和预算，选择适合的SSL证书类型

其次，选择CA（证书颁发机构）——选择一个可信的证书颁发机构，以确保获得有效和受信任的SSL证书

再次，购买和注册SSL证书——在选择的证书颁发机构的网站上购买并注册SSL证书，将需要提供一些关于个人和网站的信息

然后，通过验证过程——完成CA要求的验证过程，以证明您对域名和网站的拥有权

最后，安装和配置SSL证书——获得SSL证书后，按照证书颁发机构提供的指南，将其安装和配置到您的网站服务器上

一旦SSL证书成功安装和配置，网站就会获得安全的HTTPS连接，为用户提供更安全的浏览体验。同时，搜索引擎也会对启用SSL证书的网站给予更高的排名，从而提升网站的可信度和可访问性

但，这并不意味着结束，定期更新SSL证书至关重要，人们需要确保在证书过期之前更新证书

一文详解SSL/TLS协议

1 发展历程