TLS报文的一些内容

最新推荐文章于 2025-11-14 10:07:56 发布

原创最新推荐文章于 2025-11-14 10:07:56 发布 · 932 阅读

28 ·

CC 4.0 BY-SA版权

文章标签：

#TLS #HTTPS #密评 #密码

下载证书

证书发送的核心场景：TLS 握手流程

在标准的 TLS 握手（以 “RSA 握手” 为例，最常见的场景）中，证书的发送时机和角色如下：

客户端发起请求（Client Hello）
客户端先向服务器发送 “Client Hello” 消息，包含自己支持的 TLS 版本、加密套件列表、随机数等信息，表明 “我想和你建立加密连接”。
服务器回应并发送证书（Server Hello + Certificate）
服务器收到请求后，会通过 “Server Hello” 消息确认双方使用的 TLS 版本和加密套件，随后立即发送 “Certificate”（证书）消息，将自己的数字证书（通常是服务器证书，可能包含证书链）传递给客户端。
客户端验证证书合法性
客户端收到证书后，会通过内置的 “根证书库”（由操作系统、浏览器等预装，如 Verisign、Let’s Encrypt 等权威机构的根证书）验证服务器证书的真实性：

- 确认证书是否由可信的证书颁发机构（CA）签发；
- 检查证书是否在有效期内、是否被吊销（通过 CRL 或 OCSP）；
- 验证证书中的 “服务器域名” 与自己访问的目标域名是否一致。
  只有证书验证通过，客户端才会继续后续的加密连接建立步骤（如发送公钥加密的随机数、协商会话密钥等）。

默认情况下（单向认证），证书由服务器发送给客户端，用于证明服务器是可信的。

打开文件或开始抓包：打开已有的 pcap 文件，或者选择目标网络接口进行实时抓包。
过滤 TLS 协议：在显示过滤器中输入 “tls” 或者更具体的条件如 “tcp.port == 443” 来筛选 HTTPS 数据流。
定位证书消息：在 TCP 连接建立后的 TLS 握手阶段，服务器会发送一个名为 “Certificate” 的消息。在数据包详情窗口中，找到并展开该消息字段。
导出证书：右键点击对应的 “Certificate” 数据帧，在弹出菜单中选择 “Export Selected Packet Bytes...”导出分组字节流，然后指定保存位置和文件名，将文件扩展名设置为 “.crt” 或 “.cer” 以便于后续操作和识别，最后点击保存即可。

有时候会出现多个证书

多个证书是为了建立一个完整的、可被信任的“证书链”（Certificate Chain）

一个完整的证书链遵循一个层级结构：终端实体证书 -> (零个或多个中间CA证书) -> 根CA证书。需要注意的是，服务器发送的“Certificate”消息中不包含根CA证书本身，因为根CA证书应该已经预装在客户端的信任存储中。第一个通常是服务器自身的证书，后续的是中间 CA 证书。

加密套件

Client Hello 包的“Cipher Suites” 的字段，是客户端支持的加密套件。

Server Hello 包的“Cipher Suites” 的字段，是服务器选择的加密套件。

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) 是一个 TLS 加密套件（Cipher Suite），用于定义 TLS 握手过程中使用的加密算法、密钥交换方式、身份验证方法和消息摘要算法，命名遵循 TLS 标准的结构化格式，每个部分代表特定的功能：

识别加密套件名称

加密套件的命名规则为：
[密钥交换算法]_[身份验证算法]_[对称加密算法]_[消息认证算法]

对应 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 来说：

ECDHE（密钥交换算法）
全称 Elliptic Curve Diffie-Hellman Ephemeral（椭圆曲线 Diffie-Hellman 临时密钥交换），是一种密钥交换协议。

- 作用：在客户端和服务器之间安全地协商出一个临时的会话密钥（用于后续数据加密），而无需提前共享密钥。
- 特点：

- - “Ephemeral”（临时）表示每次会话都会生成新的临时密钥对，即使长期密钥泄露，历史通信也不会被解密（提供 “前向保密性”）。
  - 基于椭圆曲线（ECC）计算，相比传统的 RSA 密钥交换，在相同安全强度下效率更高（密钥长度更短，计算更快）。

RSA（身份验证算法）
基于 RSA 非对称加密算法的身份验证方式。

- 作用：在密钥交换过程中，服务器通过 RSA 私钥签名证明自己的身份（验证服务器证书的合法性），确保客户端连接的是真实服务器（防止中间人攻击）。
- 说明：这里的 RSA 仅用于身份验证，不直接参与密钥交换（密钥交换由 ECDHE 完成）。

AES_256_GCM（对称加密算法，用于握手后的数据传输阶段）
用于对实际传输的数据进行加密的对称算法，由三部分组成：

- AES：Advanced Encryption Standard（高级加密标准），最常用的对称加密算法。
- 256：密钥长度为 256 位，属于高强度加密（安全性高于 128 位，破解难度极大）。
- GCM：Galois/Counter Mode（伽罗瓦 / 计数器模式），一种认证加密模式。

- - 不仅能加密数据，还能同时验证数据的完整性和真实性（防止数据被篡改或伪造）。
  - 相比传统的 CBC 模式，GCM 更高效且支持并行计算，适合高吞吐量场景。

SHA384（消息摘要算法，仅用于握手阶段）
全称 Secure Hash Algorithm 384，是一种密码学哈希函数。

- 作用：在 TLS 握手阶段生成消息验证码（MAC），验证握手过程中交换的信息是否被篡改。
- 特点：输出 384 位的哈希值，安全性高于 SHA256（抗碰撞能力更强）。

0xc030 是该加密套件的数值标识符，由 IANA（互联网号码分配机构）标准化，方便 TLS 协议在握手时通过数字快速协商加密套件。

该加密套件属于现代安全加密套件，支持前向保密性（ECDHE 的 “Ephemeral” 特性）、高强度加密（AES-256）和认证加密（GCM），被广泛用于 HTTPS、VPN 等场景，符合当前主流的安全标准（如 PCI DSS、GDPR 等对数据传输的安全要求）。

秘钥计算相关

客户端随机数在Client Hello

服务端随机数在Server Hello

服务器临时公钥在Server Key Exchange 的EC Diffie-Hellman Server Params

客户端临时公钥在Client Key Exchange 的EC Diffie-Hellman Client Params

计算预主密钥 (Pre-Master Secret)

这是整个密钥体系的源头。

所需数据:

1.服务器的临时私钥 (server_tmp_priv) → 本地秘密

2.客户端的临时公钥 (client_tmp_pub) → 来自报文 (Client Key Exchange)

或

3.客户端的临时私钥 (client_tmp_priv) → 本地秘密

4服务器的临时公钥 (server_tmp_pub) → 来自报文 (Server Key Exchange)

算法: 椭圆曲线迪菲-赫尔曼 (ECDH) 计算。

公式: PMS = ECDH(server_tmp_priv, client_tmp_pub) = ECDH(client_tmp_priv, server_tmp_pub)

结果: 双方独立计算出一个相同的共享秘密（一个字节串），即为PMS。

关键点：计算PMS所需的私钥始终是本地秘密，绝不会在网络上传输。公钥则在报文中明文交换。

计算主密钥 (Master Secret)

主密钥是生成所有会话密钥的“根密钥”。

所需数据:

1.预主密钥 (PMS) → 上一步的计算结果

2.客户端随机数 (Client Random) → 来自报文 (Client Hello)

3.服务器随机数 (Server Random) → 来自报文 (Server Hello)

算法: 伪随机函数 (PRF)，在TLS 1.2中默认基于HMAC-SHA256。

公式: MS = PRF(PMS, "master secret", ClientRandom + ServerRandom)[0..47]

"master secret"是一个固定的标签字符串。

[0..47]表示输出截取前48个字节。

结果: 一个48字节的主密钥。

计算会话密钥 (Session Keys)

会话密钥是最终用于加密和认证应用数据的对称密钥。

所需数据:

1.主密钥 (MS) → 上一步的计算结果

2.客户端随机数 (Client Random) → 来自报文 (Client Hello)

3.服务器随机数 (Server Random) → 来自报文 (Server Hello)

算法: 同样的PRF函数。

过程:

1.首先计算一个足够长的密钥块 (Key Block):

key_block = PRF(MS, "key expansion", ServerRandom + ClientRandom)

2.从这个密钥块中按顺序、按长度要求切分出最终的对称密钥：

client write MAC key (TLS 1.2中用于CBC模式，GCM模式不需要)

server write MAC key (同上)

client write encryption key (如AES-128密钥为16字节)

server write encryption key (如AES-128密钥为16字节)

client write IV (初始化向量，用于CBC等模式)

server write IV (用于CBC等模式)

密钥类型	所需数据	数据来源	是否在报文中？
预主密钥	服务器临时私钥	服务器本地生成	否 (绝对保密)
	客户端临时公钥	`Client Key Exchange`报文	是 (明文)
	客户端临时私钥	客户端本地生成	否 (绝对保密)
	服务器临时公钥	`Server Key Exchange`报文	是 (明文)
主密钥	预主密钥	计算得出	否
	客户端随机数	`Client Hello`报文	是 (明文)
	服务器随机数	`Server Hello`报文	是 (明文)
会话密钥	主密钥	计算得出	否
	客户端随机数	`Client Hello`报文	是 (明文)
	服务器随机数	`Server Hello`报文	是 (明文)