📚 课程目录第1章 TLS简介

TLS 简介

这一章我们聊聊 TLS 的来龙去脉。说白了，TLS 就是给网络通信加了一把锁——不过这锁的设计，超过二十年还在迭代。我个人最早接触 TLS 时还被它的配置搞得头大，后来踩了些坑，才发现理解它的历史比直接抠配置重要得多。

一句话记牢：TLS 是 SSL 的继承者，目标是解决互联网上数据不加密、不防篡改、不验身份的三个老大难。

故事要从九十年代中期讲起。Netscape 公司为了给浏览器通信加层保护，搞出了 SSL（Secure Sockets Layer）。

SSL 1.0（1994）——内部版本，从未公开发布。原因？漏洞太多。
SSL 2.0（1995）——第一个商用版本。但我可以告诉你，它现在基本等于裸奔。我曾在一次渗透测试中看见生产环境还开着 SSL 2.0，当场惊出一身冷汗。
SSL 3.0（1996）——大改版，引入了更安全的握手流程。可惜后来被 POODLE 攻击打穿了。
TLS 1.0（1999）——IETF 接管后改名，实际等同于 SSL 3.1。改动不大，但开启了标准化道路。
TLS 1.1（2006）——增加了 CBC 保护、IV 随机化，算是小迭代。
TLS 1.2（2008）——真正的大杀器。SHA-256 取代 SHA-1，支持 AEAD（如 GCM）。现在你去配服务器，默认都用它。我个人习惯：除非有特殊兼容要求，否则最低允许 TLS 1.2。
TLS 1.3（2018）——里程碑。握手从 2-RTT 降到 1-RTT，去除了一堆不安全算法，全面拥抱前向安全性。嗯，这里要注意：TLS 1.3 不再支持静态 RSA 密钥交换，所以很多旧代码直接废了。

下面这张表可以把版本关系看得更清楚：

实战经验：我几年前排查一个银行 App 的握手失败问题，发现服务端只配了 TLS 1.0，而客户端强制要求 1.2。升级服务端后，不仅安全评分直接拉满，页面加载速度还快了 30%——因为旧版本协商了太多冗余算法。

TLS 的核心目标就三个：机密性、完整性、身份验证。你想想看，没有加密的 HTTP 就像在明信片上写银行卡号——路上谁都能看。而 TLS 是在传输层和应用层之间加了一个安全垫层，所有数据先封装再送走。

HTTPS（HTTP over TLS）——最常见的场景。你在浏览器看到的绿色小锁，背后就是 TLS。我建议个人网站也全部上 HTTPS，哪怕只是博客。Chrome 已经开始把 HTTP 页面标为「不安全」了。
安全邮件（SMTPS/IMAPS）——邮件服务器之间的加密传输。我记得有次帮客户审计邮件系统，发现他们 MTA 之间用的是明文 SMTP，内部员工的邮件内容可以被同机房其他机器捕获。加上 TLS 后问题立解。
VPN（如 OpenVPN 基于 TLS）——远程办公经常用。控制通道走 TLS，数据通道再封装。
物联网（MQTT over TLS）——我见过很多 IoT 设备直接裸连云平台，结果被中间人劫持去操控空调。给设备固件集成 TLS 1.2 并不难，但很多团队嫌麻烦。
数据库连接（MySQL/PostgreSQL over TLS）——内网也不该裸奔。一次内部扫描发现测试数据库连了明文，DBA 吓得立刻全线上 SSL。

很多人会问：SSL 和 TLS 到底是不是一回事？从技术上讲，TLS 就是 SSL 的升级版。但从品牌上，SSL 已经被钉在了安全耻辱柱上。你可能会在配置文件中看到 ssl_protocols 或者 ssl_certificate 这种命名——这只是历史遗留，实际它们配置的都是 TLS。

我建议你在写代码或配置文件时，永远不要再自称 SSL。举个例子：我曾经接手一个项目，所有配置项叫 use_ssl，结果大家误以为还在用 SSLv3，花了两周才说服团队改名为 use_tls。虽然只是命名，但能减少新人理解偏差。

避坑：我曾经遇到过第三方支付接口只支持 SSL 3.0，理由是“很多老 POS 机”。这种场景必须要求对方升级 TLS，否则直接承担安全风险——POODLE 攻击能轻松截获支付令牌。

你可能已经会配置 Nginx 的 HTTPS 了——开个证书、贴个配置。但遇到奇怪的中断、协议降级、密码套件兼容性问题时，仅仅会配是不够的。你需要理解 TLS 的握手流程、证书链验证、密钥协商、记录层加密这些底层机制。

我见过多个团队因为不懂 TLS 状态机，在生产环境把「Session Resumption」配错，导致千万级用户的 App 每次连接都要完整握手，服务器直接被打挂。如果早点理解架构，就不会掉这个坑。