第4章 HTTPS与TLS协议：为RESTful API保驾护航
说实话，很多开发者在设计RESTful API时，都默认加了一层HTTPS，觉得这就够了。但你真的了解TLS在背后做了什么吗？我在项目中遇到过太多次“加个S就安全了”的想当然，结果性能崩了，或者证书链验证失败导致服务不可用。这一章，咱们就聊聊HTTPS到底是怎么给API“保驾护航”的。
4.1 TLS握手：不只是加密那么简单
你发一个HTTPS请求，客户端和服务器之间会先握个手。这个握手，说白了就是双方商量怎么加密、怎么验证身份。我习惯把TLS握手理解成两个阶段：先验明正身，再商量密码。
4.2 握手流程拆解
一个完整的TLS 1.3握手，大概就四个步骤。我画了张图，你一看就明白了。
我总结了一下，这四个阶段的核心任务是这样的：
- ClientHello：客户端打个招呼，告诉服务器自己支持哪些加密套件、TLS版本，以及一个随机数。
- ServerHello + 证书：服务器选好加密套件和版本，发回自己的数字证书（含公钥）。
- 证书验证 & 密钥协商：客户端验证证书是否可信，然后双方用非对称加密交换出对称加密的“会话密钥”。
- Finished & 加密通信：握手确认，后续所有API数据都用对称加密传输。
4.3 密码套件选择：别什么都往里装
密码套件（Cipher Suite）是TLS握手中要商量的一件事。它决定了用什么算法来加密、用什么算法做密钥交换、用什么算法做消息认证。
我个人习惯，对于RESTful API，安全性和性能要平衡。一味追求高强度的加密，可能会让服务器算力打满。我见过有人把TLS 1.2的套件全开着，结果一握手就慢几秒，API直接超时。
下面是我对现代API建议的密码套件配置清单：
| 用途 | 推荐套件 / 策略 | 备注 |
|---|---|---|
| 密钥交换 | ECDHE（首选） / DHE | 提供前向安全性，服务器私钥泄露不影响历史会话 |
| 身份验证 | RSA 2048+ / ECDSA | ECDSA 算法性能更好，证书体积更小 |
| 对称加密 | AES-256-GCM / ChaCha20-Poly1305 | GCM 模式是AEAD，自带完整性校验 |
| 消息认证（HMAC） | SHA-384 / SHA-256 | SHA-1 已不建议使用 |
| TLS 版本 | TLS 1.3 首选, TLS 1.2 兼容 | 屏蔽 TLS 1.0 / 1.1 / SSLv3 |
4.4 证书链验证：别只看浏览器里的绿锁
HTTPS安全性的核心基础，是数字证书。服务器发来证书后，客户端需要验证它是否被信任的根证书颁发机构（CA）签发。这个过程叫证书链验证。
我遇到过这样一个问题：一个内部API服务，自签了证书，结果客户端代码里没做证书校验，直接把verify参数设成false。后来被安全审计发现，这个API其实等于裸奔，没有任何加密保证。
4.5 安全配置清单
要真正为RESTful API保驾护航，光有HTTPS还不够。我整理了一份最小安全配置清单，你可以拿来对照自己的项目：
- 禁用不安全的TLS版本： SSLv2、SSLv3、TLS 1.0、TLS 1.1一律禁用。
- 禁用弱密码套件： 比如RC4、3DES、CBC模式下的AES（容易受Lucky13攻击）。
- 启用HSTS： HTTP Strict Transport Security，告诉浏览器强制使用HTTPS，杜绝降级攻击。
- 证书有效期管理： 证书最多用1年（建议更短），并设置自动续期监控。我习惯提前30天告警。
- OCSP Stapling： 开启它，可以提升证书状态查询的性能，避免客户端再去连接CA。
- 禁用不安全的重新协商： 防止中间人通过重协商注入明文。
说白了，加密不只加个S就完事。你是配置对了，还是只是让客户端和服务器“握了个寂寞”？
4.6 性能优化：加密到底有多重？
很多人一提到HTTPS就说“慢”。确实，握手阶段有额外消耗，但一旦建立了会话，对称加密的开销其实很小。
我记得有一次做性能压测，同一个API，HTTP和HTTPS的差异基本在5%以内。真正影响性能的，往往是证书链的复杂度，或者频繁建立新的TLS会话。
我的优化策略非常简单：
- 启用会话复用： 客户端和服务器保持TLS Session ID或Session Ticket，避免重复握手。
- 启用False Start： TLS 1.3里的特性，客户端可以在握手还没完全结束时就开始发数据。
- 使用OCSP Stapling： 减少客户端验证证书时的额外网络请求。
- 硬件加速： 如果服务器软负载很大，可以考虑使用支持AES-NI指令集的CPU，或者专门的SSL加速卡。
4.7 避坑指南：我曾用血泪换来的教训
最后分享几个我亲自踩过的坑，希望能帮你避免类似问题。
有一次我配置了一个从Let's Encrypt申请的证书，只配了服务器证书，没把中间证书链配上。结果一些老旧的客户端，因为本地没有完整的信任链，直接握手失败。后来我每次部署都会用openssl s_client -connect ... 命令模拟完整握手，检查证书链是否完整。
在一个高并发的API集群里，我默认开启了客户端的TLS重协商。结果服务器突然涌入了大量重协商请求，直接导致了CPU 100%，API大面积超时。从那以后，我明确禁止了不安全的TLS重协商，只允许服务器发起的重协商。
第一次配HSTS时，我把max-age设得很短，想着先试试。结果发现生产环境有些请求还是走了HTTP，绕过了HSTS。后来我严格按照规范，把max-age设为了6个月，并加了includeSubDomains属性，才彻底禁用了HTTP访问。
嗯，到这里，关于HTTPS和TLS协议的核心内容就说完了。加密这件事，本质上就是信任的传递。你只有把证书、版本、套件都配得恰到好处，RESTful API才能真正做到“固若金汤”。