TLS握手时的随机数，本该是客户端和服务器各自独立生成的不可预测值。但2015年一个叫Logjam的攻击，直接把这个前提掀了桌子——攻击者能强制双方把加密强度降级到512位，这玩意儿用普通计算机几分钟就能暴力破解。当时我拿自家路由器测试，差点以为运营商劫持了流量，后来才发现是TLS库的漏洞在作祟。

更早的POODLE攻击更刁钻。它不碰加密算法本身，而是骗浏览器回退到SSL 3.0。这个1996年的老协议有个致命缺陷：填充字节的校验方式能被穷举。攻击者只需要在加密信道里注入恶意JavaScript，就能逐字节窃取Cookie。最讽刺的是，当年很多银行网银还在用SSL 3.0，因为兼容性太好——安全补丁反而成了攻击面。

你以为修完这些就完了？2018年的ROBOT攻击直接把RSA密钥交换方式钉在耻辱柱上。有个安全研究员在自家服务器上复现攻击时发现，只要向服务器发送精心构造的密文，通过观察响应时间差异，就能在几小时内还原出私钥。这种侧信道攻击根本不需要破解算法，纯粹利用的是服务器实现时的时序漏洞。当时我翻开源码一看，好家伙，OpenSSL里处理错误消息的函数居然多算了一次模幂运算。

说个冷知识：TLS 1.3发布前，光是设计草案就推翻了七次。为什么这么折腾？因为前几版协议里，前向保密是可选配置。这意味着只要服务器私钥泄露，之前录制的所有加密流量都能被解密。直到2016年Mozilla的一份报告显示，互联网上只有37%的服务器支持ECDHE密钥交换，剩下63%都在裸奔。这事逼得IETF直接把RSA密钥交换从TLS 1.3里彻底删了——不给你留退路。

但现实总比标准滞后。我去年检查某政府网站时，发现它还在用TLS 1.0。管理员理直气壮地说：“我们内网系统，别人又访问不到。”结果呢？通过一个子域名的DNS rebinding攻击，照样把Cookie偷出来了。漏洞从来不是孤立的技术问题，而是部署环境里那些“我觉得没问题”的侥幸心理。

现在回头看，TLS漏洞史就是一部打地鼠史。每次补上算法层面的洞，实现层面又冒出新的坑。你以为用AES-GCM就安全了？去年那个Lucky13攻击，照样能通过时序差异破解GCM模式下的填充校验。所以别迷信“完美协议”，真正的安全防线是快速响应机制——检测到异常握手就立即告警，而不是等漏洞被公布后才慌慌张张打补丁。