服务接口HTTPS加密改造实战 - 第1节
为什么我们非得聊HTTPS？
说实话，做了这么多年运维，我最怕听到的一句话就是：“接口又被人抓包了”。
HTTP 明文传输，说白了就是在网上裸奔。你发什么，中间人就看什么。密码、令牌、身份证号……全都是一览无余的。
2018年我接手过一个电商平台，用户登录接口走的还是HTTP。结果被中间人插了个广告脚本，用户下单金额被篡改，一晚上损失十几万。从那之后，我所有的接口改造项目，第一件事就是上HTTPS。
三大核心痛点，HTTP搞不定
- 窃听风险：数据明文传输，抓包就能看到全部内容。
- 篡改风险：中间人可以修改请求或响应内容，你根本察觉不到。
- 冒充风险：你以为是银行的接口，实际上是个钓鱼网站。
一句话总结：HTTP是明信片，HTTPS是挂号信。明信片谁都能看，挂号信只有收件人能拆。
| 对比维度 | HTTP | HTTPS |
|---|---|---|
| 传输协议 | TCP | TCP + SSL/TLS |
| 默认端口 | 80 | 443 |
| 数据加密 | 无 | 对称 + 非对称混合加密 |
| 身份验证 | 无 | CA证书验证 |
| 数据完整性 | 无校验 | MAC校验 |
| 性能损耗 | 低 | 握手增加1-2个RTT，CPU开销略高 |
注意：很多运维觉得HTTPS就是加个证书完事。不对！证书管理、密钥轮转、TLS版本配置，任何一个环节出问题，安全防护就是纸糊的。
HTTPS到底干了什么？讲透SSL/TLS握手
很多人觉得握手很复杂，其实拆开看就三件事：商定密钥、验证身份、加密通信。
我习惯把TLS握手理解成一个“三方会谈”：客户端、服务端、CA证书。CA是公证人，负责证明服务端不是冒牌货。
TLS 1.2 握手流程（最常用版本）
- Client Hello：客户端告诉服务端自己支持的TLS版本、加密套件列表，以及一个随机数。
- Server Hello：服务端选好加密套件，发回自己的证书和另一个随机数。
- 证书验证：客户端检查证书是否可信、是否过期、域名是否匹配。
- 密钥交换：客户端生成第三个随机数（预主密钥），用服务端的公钥加密后发过去。
- 会话密钥生成：双方用三个随机数算出对称加密的会话密钥。
- Finished：双方发一条加密的消息，确认握手成功。
我在实践中发现，很多人把TLS握手优化搞复杂了。其实最关键的就是两点：一是选择合适的加密套件，二是用好会话复用。后面改造章节我会详细讲。
下面这张图能帮你把整个流程串起来：
这里有个坑：我曾经遇到一个客户，TLS握手一直卡在第三步——证书验证失败。查了两天，发现是中间防火墙把证书链给截断了。嗯，网络设备对HTTPS证书的透传处理，往往是排查中最容易被忽略的环节。
TLS 1.3 做了哪些优化？
TLS 1.3 把握手从2-RTT降到了1-RTT。说白了，就是合并了Client Hello和Server Hello的部分内容，少了一次往返。对于高延迟场景，这个优化非常香。
- 移除了不安全的加密套件（RSA密钥交换、RC4、CBC模式等）
- 强制使用前向安全性（ECDHE）
- 简化握手流程，减少消息数量
我建议：新项目直接上TLS 1.3。如果必须兼容老客户端，至少把TLS 1.0和1.1关掉。这两个版本已经被攻破了，开着就是给自己留后门。
总结一下核心要点
HTTPS不是银弹，但它能堵住大部分常见攻击。改造之前，先把这三个问题想清楚：
- 证书从哪来？——自签还是CA？内部服务可以自签，对外接口必须CA。
- 密钥怎么管？——私钥不能硬编码，不能明文存储，定期轮转。
- 性能怎么扛？——SSL卸载、会话复用、硬件加速，手段很多别慌。
后面的章节我会带着你，一步步把这些东西落地到真实的服务接口上。实践出真知，干就完了。