TLS 协议概述

做安全审计这么多年，我几乎每天都要跟 TLS 握手日志打交道。不管你是搞运维、做开发还是管安全，只要你的服务暴露在公网上，TLS 就是第一道防线。这一章咱们聊聊 TLS 是什么、它怎么来的、有哪些版本、都用在什么地方。

嗯，先别急。不是要背历史，而是要让你知道——为什么你现在应该只用 TLS 1.2 和 1.3，为什么看到 SSL 就该拉警报。

故事要从 90 年代说起。网景公司搞了个 SSL（Secure Sockets Layer） 协议，用来保护浏览器和服务器之间的通信。SSL 1.0 从未公开，因为漏洞太多。2.0 在 1995 年发布，结果很快被攻破。3.0 在 1996 年发布，算是勉强能用。

后来 IETF 接手，把 SSL 3.0 改进后改名为 TLS（Transport Layer Security）。所以严格来说，TLS 1.0 就是 SSL 3.1。但命名上划清了界限——SSL 时代已经过去了。

我记得刚入行时，公司内部还在用 SSL 3.0 做邮件加密。那会儿没人觉得有问题。直到 POODLE 攻击曝光，所有 SSL 3.0 连接一夜之间变成高危。那次紧急升级把我折腾得够呛。打那以后，我养成了一个习惯：但凡看到 SSL 字样，直接标红。

下面是 TLS 协议的演进脉络：

避坑指南：我曾经在审计中发现某银行核心交易系统还在用 TLS 1.0，理由是“兼容老客户设备”。我建议他们至少同时启用 TLS 1.2，并在前端加一层代理灰度升级。后来 PCI DSS 合规检查一次通过，再也不用写风险说明文档了。

你看看上面那张图，红橙蓝绿，一目了然。我来列个详细的对比表，方便你写策略时直接抄作业。

版本	发布年份	核心密码套件	已知严重漏洞	审计状态	我的建议
SSL 2.0	1995	RC4, DES	多个致命漏洞	红色禁用	直接拦截，任何环境中都别出现
SSL 3.0	1996	RC4, 3DES	POODLE	红色禁用	同 SSL 2.0，必须禁用
TLS 1.0	1999	RC4, 3DES, AES	BEAST, Lucky13	橙色不建议	尽快迁移，PCI DSS 已禁止
TLS 1.1	2006	AES-CBC	部分 CBC 攻击	橙色不建议	同样应禁用，除非有极特殊兼容要求
TLS 1.2	2008	AES-GCM, ChaCha20	无通用漏洞（需正确配置）	蓝色推荐	当前主力版本，所有新服务必须支持
TLS 1.3	2018	仅 AEAD (AES-GCM, ChaCha20)	无已知漏洞	绿色强烈推荐	性能更好、更安全，优先启用

  关键结论：你的服务只要允许 TLS 1.0/1.1 甚至 SSL，就等于在自己门口贴了“欢迎攻击”的标签。我在做渗透测试时，最喜欢看到这种老协议，因为大概率能抓到明文的会话 Cookie。

你可能会问：TLS 1.2 和 1.3 到底差在哪？我简单说几个关键点。

握手轮次减少：TLS 1.2 完整握手需要 2-RTT（两次往返），TLS 1.3 只用了 1-RTT。再加上 0-RTT 模式（需要谨慎使用），体验差距很明显。
密码套件大瘦身：TLS 1.3 只允许 AEAD 套件，彻底废弃了 CBC 模式、RC4、3DES 这些拖油瓶。配置变得简单多了。
前向安全性强制：TLS 1.3 必须使用基于临时密钥的密钥交换（ECDHE/DHE），不能退回到静态 RSA。

我个人习惯是：新系统直接上 TLS 1.3，老系统至少升级到 1.2（并禁用 1.0/1.1）。如果因为客户端兼容性问题必须保留 1.0/1.1，一定要用 WAF 或者代理层做安全加固，同时写清楚风险接受文档。

说了半天，TLS 到底用在哪？很多人第一反应就是 HTTPS。没错，这是最大头的应用场景，但远不止于此。

注意：千万不要以为只有 Web 服务才需要 TLS。任何涉及敏感数据传输的网络通信，都应该考虑用 TLS 加密。

我给你列个清单，都是我在实际审计中遇到的典型场景：

HTTPS（HTTP over TLS）：浏览器访问网站、API 接口、WebSocket — 这些是最常见的。我建议所有 HTTP 流量都强制走 HTTPS，连重定向都不要给 HTTP 留机会。
邮件传输：SMTP over TLS（SMTPS）、IMAP over TLS、POP3 over TLS。你想想看，如果邮件明文传输，别人在 Wi-Fi 上随便抓个包就能看到你的密码和邮件内容。
VPN 与远程接入：很多企业 VPN 基于 DTLS（TLS 的 UDP 版本）或 OpenVPN（基于 TLS）。我记得有次帮客户审计远程办公方案，发现他们用的老旧 PPTP 居然还在跑，连加密都没开。
数据库连接：MySQL、PostgreSQL、MongoDB 都支持 TLS 连接。内网里很多数据库默认不走加密，我强烈建议你在生产环境开启。
消息队列与微服务：Kafka、RabbitMQ、gRPC 都可以配置 TLS 加密。微服务之间的通信往往被忽视，但实际上最容易成为攻击者的突破口。
物联网与移动 App：设备与云端之间的通信，如果不用 TLS，等同于裸奔。我见过一些智能家居设备用自定义加密，结果被逆向出密钥。

个人经验：我审计过一家金融科技公司，他们对外宣称“全链路加密”，结果我在内部日志里发现微服务之间的 RPC 调用全是明文。后来他们用 mTLS（双向 TLS）补上了这个缺口。说实话，双向认证在服务网格里越来越流行，但配置不当也会踩坑，我们后面的章节会专门讲 mTLS 的日志审计要点。

总结一下：TLS 不是 HTTP 的附属品，而是所有 TCP 应用层加密的标准答案。你只要把握住一条原则——任何传输层之上跑的敏感数据，都应该用 TLS 包裹。