TLS协议概述

TLS，全称是 Transport Layer Security。说白了，它就是在网络传输层之上加了一层加密外壳。你想想看，HTTP 数据在网络上裸奔，谁都能抓包看到。TLS 就是给这个裸奔的数据穿上防弹衣。它是现代互联网安全的基石——从网上银行到即时通讯，离了它基本没法玩。

我个人习惯把 TLS 当做一个三层结构来看：底部是传输层（TCP），中间是 TLS 记录层，上层才是应用协议（HTTP、SMTP 等）。这个分层设计很巧妙，它让上层不用关心加密细节。

TLS 版本演进

从 SSL 到 TLS，版本迭代其实是在跟漏洞做斗争。我整理了一张表，方便你快速了解：

版本 发布年份 状态 审计关注点
SSL 2.0 1995 已废弃 见到即告警，存在严重设计缺陷
SSL 3.0 1996 已废弃（2015年后被禁用） POODLE 攻击风险，必须禁用
TLS 1.0 1999 已废弃（PCI DSS等要求禁用） BEAST攻击风险，应降级视为不安全
TLS 1.1 2006 已废弃 Lucky 13等攻击风险，尽快迁移
TLS 1.2 2008 当前主流 需配置强密码套件，禁用弱算法
TLS 1.3 2018 推荐使用 安全性高，握手更快，审计时优先推荐
注意：我在审计中遇到过不少系统还开着 TLS 1.0。有些是设备太老无法升级，有些是运维压根不知道。不管什么原因，只要你看到 TLS 1.0 或更早版本还在用，这就是一个高危发现。别听对方说「用了十年一直没事」——出事的时候你就被动了。

TLS 握手过程

握手是 TLS 最核心的流程。它负责完成三件事：协商加密参数、验证服务器身份、生成会话密钥。下面这张图展示了 TLS 1.2 的典型握手步骤，也是我们在审计中经常要检查的地方。

TLS 1.2 完整握手流程 客户端 服务端 ① ClientHello ② ServerHello + 证书 + ServerHelloDone ③ ClientKeyExchange + ChangeCipherSpec ④ ChangeCipherSpec + Finished 审计重点关注区域 • 服务器证书是否由可信CA签发    • 证书是否过期/域名是否匹配 • 密码套件协商结果是否安全    • 是否使用了安全的密钥交换算法（如ECDHE）

嗯，这里要注意：TLS 1.3 把握手压缩到了 1-RTT（首次往返时间），而且废弃了 RSA 密钥交换。我在审计时更倾向于用这个握手图来跟团队对齐——毕竟大多数弱配置问题都出在握手阶段。

实战技巧：用 OpenSSL 命令行可以快速查看握手的每个步骤。比如 openssl s_client -connect example.com:443 -tls1_2，你能看到完整的握手参数。我以前排查一个证书链问题，就是靠这个命令逐行对比的。

密钥交换与密码套件

密码套件决定了用什么算法做密钥交换、用什么算法做身份认证、用什么算法做对称加密、用什么算法做消息完整性校验。这四个部分缺一不可。

套件示例 密钥交换 认证 加密 MAC 安全评级
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDHE RSA AES-128-GCM SHA256 ✅ 推荐
TLS_RSA_WITH_AES_128_CBC_SHA RSA RSA AES-128-CBC SHA1 ⚠️ 不推荐（无前向安全性）
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 ECDHE ECDSA ChaCha20-Poly1305 SHA256 ✅ 推荐（移动端优化）
TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA RSA 3DES SHA1 ❌ 已弃用（SWEET32攻击）

我个人审计时最关注两个点：是否存在 RSA 密钥交换（无前向安全性），以及是否使用了 CBC 模式的加密（容易引发 padding oracle 攻击）。你想想看，如果服务端同时支持 RSA 和 CBC，那几乎等于半个秒表。

证书链与信任模型

握手过程中，服务端必须发送证书。审计时我们要检查证书链是否完整——从服务器证书到中间 CA 证书再到根证书。我曾经遇到一个案例：服务端只发了服务器证书，没带中间证书。大部分浏览器能自动补全，但一些老客户端直接报错，导致用户访问失败。

审计要点回顾：
  • 证书是否由受信任的公共 CA 签发（内部 PKI 需单独评估）
  • 证书有效期是否还剩至少 30 天
  • CN/SAN 是否与访问域名匹配
  • 证书链是否完整（server → intermediate → root）
  • 是否使用了 RSA 密钥交换（推荐 ECDHE）
  • 是否启用了 TLS 1.0/1.1（必须禁用）
  • 是否使用了弱密码套件（如 RC4、3DES、CBC 系列）

记录协议与警报

TLS 记录协议负责把上层数据分片、压缩（可选）、加 MAC、加密、加上记录头。审计时我们主要关注最大分段大小和是否启用压缩。嗯，压缩曾引发 CRIME 攻击，所以 TLS 1.3 直接删除了压缩支持。

警报协议用于报告错误或关闭连接。比如证书过期时会发 bad_certificate 警报。我在审计日志中经常看到大量 decryption_failed 警报——这往往说明有人在尝试重放攻击或篡改数据。

避坑指南：我曾经在客户环境看到一台负载均衡设备，TLS 配置里同时开启了 SSL 3.0 和 TLS 1.2。运维说「兼容老设备」。但 SSL 3.0 有 POODLE 漏洞，攻击者可以降级攻击。最终我们的建议是：关闭 SSL 3.0，如果实在要兼容，换成 TLS 1.0 并打上 BEAST 补丁——实际上更推荐直接迁移客户端。
同样的坑我也在 OpenSSL 自身遇到过：早期版本默认开启了 SSL_OP_ALL，包含了不安全的选项。所以审计时一定要看具体的密码套件白名单，不要相信「默认安全」。

本章小结

← 上一章 📖 返回目录 下一章 →