SSL/TLS协议深度解析：记录、警报与握手

记录协议

协议栈中的位置与功能

SSL/TLS记录协议位于协议栈的关键位置，为上层协议提供透明的安全服务。从分层架构看，它建立在可靠的传输协议（如TCP）之上，为应用层协议（如HTTP）提供保密性和完整性保障。

协议栈结构 ：

记录协议的核心功能体现在两个方向：

对上：接收任意长度的数据流，不关心内容含义
对下：输出统一格式的、长度受限的、加密后的数据块，交给TCP传输

根据当前会话状态 给出压缩算法，Cipher Spec 给出对称加密算法、MAC算法、密钥长度、Hash长度、IV长度，以及连接状态中给出的Client和Server的随机数、加密密钥、MAC秘密值、IV，消息序列号等，对将要传送的数据实施以下操作：压缩/解压加密/解密 MAC计算/MAC校验

工作流程：五步处理流水线

Step 1: 分片：从上层接收任意大小的数据块(Records)
Step 2: 压缩 ：用当前会话状态中给出的压缩算法，将明文结构SSLPlaintext压缩为压缩记录SSLCompressed
Step 3: MAC计算 ：用当前会话状态中指定的MAC算法对SSLCompressed计算消息摘要
Step 4: 加密 ：用加密算法加密压缩数据和消息摘要，形成密文结构SSLCiphertext
Step 5: 封装发送：将数据封装为TCP数据报文并发送

警报协议：安全通信的哨兵

协议定位与分类体系

警报协议用于在SSL/TLS握手或数据加密等过程中，将相关的告警信息传输给通信对端，用以发出警告或立即中止当前连接。

消息的分类：

Alert消息主要依据两个维度进行分类：

按错误严重程度分类 ： 警告消息 ：发出警告，但连接可能继续。 致命消息：将导致连接被立即中止，并且与该连接相关的会话（会话标识符）会被作废，以防止此会话被继续用于建立新的连接。
按功能与影响分类 ： Close_Notify ：用于通知对端正常关闭该连接。以此种方式关闭的连接可以被恢复。 Error Alerts (Alert Error) ：用于因错误而通知对端关闭连接。以此种方式关闭的连接不能被恢复。

常见的具体消息类型示例

警告消息(Warning Msg) 包括：结束通知、无证书、证书出错、不支持的证书、证书撤销、证书过期、未知证书等。
致命消息(Fatal Msg) 包括：意外消息、MAC记录出错、解压失败、握手失败、非法参数等。

警报协议

警报协议格式

握手协议：信任建立的复杂舞蹈

协议本质与核心功能

定义与定位：

握手协议是TLS中最复杂的部分。
它在传递应用程序数据之前使用，允许客户端和服务器相互认证、协商加密和MAC算法，保护数据使用的密钥通过SSL记录传递。

主要功能：

客户和服务器之间相互鉴别。
协商密钥交换算法、加密算法和密钥、压缩算法。
生成密钥，完成密钥交换。

本质：

握手协议用于建立一个新会话或恢复一个已有会话。每次握手都会生成新的密钥、MAC秘密值和初始化向量等。
本质上，它是一个密钥交换协议 ，由于包含了认证功能，因此可以视为认证和密钥交换协议。
其核心功能是确保：双方协商的参数是安全的（抵抗保密性攻击），且协商时双方身份是可认证的（抵抗中间人攻击等）。

四阶段握手流程

TLS握手遵循严格的四阶段流程，传统上需要2个往返时延（2-RTT）：
Server Client Server Client 阶段1: 建立安全功能阶段2: 服务器认证和密钥交换阶段3: 客户端认证和密钥交换阶段4: 完成安全通信建立 ClientHello 版本, 随机数, 密码套件列表 ServerHello 选定版本, 随机数, 密码套件 Certificate (服务器证书) ServerKeyExchange (可选) CertificateRequest (可选) ServerHelloDone Certificate (客户端证书, 可选) ClientKeyExchange CertificateVerify (可选) ChangeCipherSpec Finished ChangeCipherSpec Finished

阶段1：建立安全功能

ClientHello消息：客户端发起握手，声明自身能力：

version：支持的最高TLS版本
random：客户端随机数，防止重放攻击
session_id：会话ID，用于会话恢复
cipher_suites：支持的密码套件列表
compression_methods：支持的压缩方法

ServerHello响应：服务器选择双方都支持的参数：

从客户端列表中选定一个密码套件
确定压缩方法（现代TLS通常为null）
生成服务器随机数

密码套件语法 ：TLS_密钥交换算法_WITH_加密算法_MAC算法

示例：TLS_RSA_WITH_AES_256_GCM_SHA384

通俗理解：

可以理解为如下对话：

Client："我想和你安全地通话，我这里的对称加密算法有DES、RC5，密钥交换算法有RSA和DH，摘要算法有MD5和SHA。"
Server："我们用DES-RSA-SHA这对组合好了。"

阶段2和3：认证与密钥交换

常见密钥交换算法：

以下是公钥密码体制在加密、签名和密钥交换方面的应用能力概览：

算法	加密/解密	数字签名	密钥交换
RSA	是	是	是
椭圆曲线	是	是	是
Diffie-Hellman	否	否	是
DSS	否	是	否

密钥套件参数中需要指明密钥交换算法，支持以下四种：

RSA：用接收者的RSA公钥加密，必须拥有接收者公钥的数字证书（用于验证）。
固定D-H：使用D-H密钥交换，需要有包含D-H公钥的数字证书。
瞬时D-H：用于一次性的密钥。D-H公钥交换时使用发送者的RSA或DSS私钥签名。接收者使用相应的公钥验证签名。由于是临时的，因此是三种D-H算法中最安全的。
匿名D-H：基本的D-H算法。

RSA密钥交换详解：

核心逻辑 ：

客户端产生预主密钥，并用服务器公钥加密预主密钥同步到对方，服务器用私钥解密。

认证：

服务器强制认证（基于RSA证书），客户端可选认证。

前向安全性 ：
无。服务器端收到预主密钥后，由服务器私钥解密，私钥泄露则历史会话可被破解。

握手消息流程与说明：

certificate：服务器RSA证书链（含服务器公钥、CA签名、证书有效期、密钥用途="密钥加密"）。用于向客户端提供加密预主密钥所需的公钥。
client_key_exchange：加密的预主密钥。这是用服务器公钥加密的16字节随机数（预主密钥）。
server_key_exchange：不需要。
certificate_verify：不需要。

客户端收到certificate后的验证：

证书链是否可信（追溯至根CA）。
证书未过期/未吊销。
公钥用途合法。

若服务器要求客户端认证：

certificate_request：服务器需要客户端认证。
certificate（客户端发送）：客户端RSA证书。
certificate_verify：用客户端私钥签名握手摘要，证明持有私钥。
服务器验证：确认客户端签名，证明身份合法；证书链可信。

固定DH密钥交换：

核心逻辑：

客户端与服务器基于各自的静态DH密钥对，协商共享预主密钥。

认证：

服务器强制认证（基于DH证书），客户端可选认证。

前向安全性：

无。服务器使用长期静态DH公钥，私钥泄露则历史会话可被破解。

固定DH密钥交换小结：

固定DH的核心------静态密钥对：服务器长期使用同一对DH私钥/公钥，公钥通过证书绑定身份。
DH参数协商 ：服务器的DH参数（p/g）可通过Certificate消息发送，也可在ServerKeyExchange中发送（若证书中未包含）。
预主密钥计算：客户端和服务器无需传输预主密钥本身，而是通过DH算法各自独立计算得到相同的预主密钥，仅需交换公钥。

详细流程与验证：

certificate （服务器发送）：服务器DH证书链，含固定DH公钥、DH参数p/g、CA签名、密钥用途="密钥协商"。
certificate（客户端发送，可选）：客户端DH证书链（含静态DH公钥、CA公钥、CA签名）。
certificate_request（可选）：可接受的CA列表、支持的客户端认证算法（如DH_RSA）。
server_key_exchange：不需要。
certificate_verify：用客户端私钥签名握手摘要，证明持有DH私钥，身份合法。

客户端验证：

证书链可信。
证书未过期/未吊销。
DH参数合法（p为大素数，g为生成元）。
DH参数与服务器兼容。

服务器验证：

证书链可信。
DH参数与服务器兼容。
验证客户端签名：确认客户端持有DH私钥，身份合法。

瞬时DH密钥交换：

核心逻辑 ：

客户端与服务器基于临时DH密钥对协商共享预主密钥，身份认证依赖独立证书，非DH证书

认证：

服务器强制认证(基于RSA/DSA证书)，客户端可选认证

前向安全性 ：

有：每次会话生成临时DH密钥对，会话结束后销毁，私钥泄露不影响历史会话

消息交互：

certificate (服务器发送)：服务器RSA/DSA证书链，含服务器公钥、CA签名、密钥用途="数字签名"。
server_key_exchange ：
1. DH参数p和g；
2. 服务器临时DH公钥（b*g mod p）；
3. 签名，用服务器私钥签名DH参数+临时公钥+ClientHello/ServerHello哈希值。
certificate (客户端发送，可选)：客户端RSA/DSA证书链，用于提供客户端身份认证的公钥。
certificate_request (可选)：可接受的CA列表、支持的客户端认证算法（如RSA）。
certificate_verify (可选，当客户端发送证书时)：用客户端私钥签名的握手消息摘要，含DH参数、临时公钥、所有握手消息哈希值。

验证要求：

客户端验证 ：
1. 证书链可信；
2. 未过期/未吊销；
3. 密钥用途合法，用于签名验证。

瞬时Diffie-Hellman密钥交换小结

DHE与固定DH的核心区别 ：
DHE的DH密钥对是临时生成的，每次会话不同，会话结束后私钥立即销毁，因此具备前向安全性。
服务器认证的双重保障 ：
1. 证书验证（身份合法性）
2. ServerKeyExchange的签名验证（DH参数和临时公钥未被篡改）
性能特点 ：
DH参数生成和密钥计算耗时略高于RSA，但安全性更强（前向安全）。

匿名DH密钥交换：

核心逻辑 ：

客户端与服务器基于临时DH密钥对协商共享预主密钥，但无身份认证易受中间人攻击。
认证：

无，服务器和客户端均不认证身份。
前向安全性 ：

有，临时DH密钥对，会话结束后销毁。
现状：

TLS 1.2中仍支持，但实际部署极少(因无认证)，TLS 1.3已完全移除。
匿名Diffie-Hellman密钥交换

消息交互：

certificate：无。
server_key_exchange ：
1. DH参数；
2. 服务器临时DH公钥。
certificate_request：无。
Client_key_exchange：客户端临时DH公钥。
Certificate_verify：无。

客户端验证 ：无(无证书，无签名验证)。
匿名Diffie-Hellman密钥交换

匿名性的代价 ：
无身份认证，攻击者可作为中间人拦截 ClientHello和 ServerHello，替换双方的DH公钥，从而窃取预主密钥（中间人攻击可行）；
应用场景 ：
仅适用于"无需身份验证、仅需加密传输"的场景（如公共Wi-Fi的匿名数据传输），但实际中因安全风险极少使用。
与DHE的核心区别 ：
ADH无Certificate和CertificateVerify消息，服务器无需提供证书，因此无法验证身份。

密钥交换算法对比分析

前向安全性本质：取决于会话密钥是否依赖于长期密钥。仅当使用临时密钥对（如DHE）时才具备前向安全性。

认证与密钥交换分离：DHE是典型代表，身份认证依赖证书，密钥交换依赖临时DH参数。这种分离设计提高了系统的灵活性和安全性。

中间人攻击防御：防御前提是存在身份认证。匿名DH因无认证而脆弱，其他机制通过证书和签名验证确保身份合法性。

阶段4：握手完成与密码切换

第四阶段是握手过程的收尾，完成密码参数切换：

ChangeCipherSpec消息：严格来说，这属于独立的"修改密码规范协议"。它通知对方："从现在开始，我将使用新协商的密码参数"。这是一个简单的一字节消息，但具有关键作用。

Finished消息：握手协议中第一条使用新密码参数保护的消息，包含之前所有握手消息的摘要。它的双重作用：

完整性验证：确认握手过程未被篡改
密钥确认：证明发送方拥有正确的密钥

完成后的状态转换：

复制代码

握手完成 → 启用新密码参数 → 应用数据加密传输