一篇流传甚广的技术随笔提出一个简单却扎人的判断:所有宣称"端到端加密"的网页应用,本质上都是蛇油密码学。理由不复杂——网页的客户端代码永远由服务器自己分发,服务器随时能推送一份被篡改的JS来绕过加密,所谓"连服务商都看不到你的数据",从结构上就立不住。这话听起来像民间吐槽,但安全学界早就给这个漏洞起了正式名字,也开发出一整套缓解方案,只是这些方案至今几乎没有一款主流产品愿意认真用上。
服务器分发代码,这道题从一开始就解不开
TLS能防的是第三方窃听——你和服务器之间的通道是加密的,中间人插不进来。但"端到端加密"承诺防的是另一件事:防服务器运营方本身偷看。问题在于,网页每次加载都要重新信任同一个服务器发来的代码,这两个威胁模型天然打架。
Lavabit事件是这个矛盾最直接的例证。斯诺登曾用Lavabit的邮箱,该服务号称用浏览器里的JS加密邮件,连自己都解不开。FBI盯上斯诺登后,直接要求Lavabit所有者修改网站代码来解密特定用户的邮件——这说明所有者本来就有能力做到这件事。他最终选择关站,而不是照办,但这恰恰证明了"我们看不到你的数据"这句话是可以被随时推翻的承诺,不是技术上的不可能。
服务器如果说谎,加密只是它自己写的说明书
学界不是没想办法,是办法总卡在同一环节
CISPA的一份研究论文《Trust on Reload》把这个问题正式形式化:只要没法在执行前验证客户端代码的完整性,网页应用里"真正的端到端加密"就不成立。这不是孤立吐槽,而是被学界认真对待的开放问题。
围绕这个问题,已经出现好几条工程思路。浏览器内置的Subresource Integrity(SRI)机制可以对引用的外部脚本做哈希校验,防CDN被攻破或缓存投毒。NIST把代码签名定位为防伪造、防篡改的手段。微软研究院提出过HTTPi方案,主张光靠HTTPS管不住可缓存内容的完整性,得额外签名。MIT的Mylar系统则更进一步,试图在"服务器可能恶意"的假设下,仍保证客户端代码本身可信。近两年还有WAIT提出的"二进制等价透明化",以及NDSS会议上关于"可问责JS代码分发"的研究,思路都是让恶意或针对性投毒的代码变得可被审计发现。
但这些方案都在同一处卡壳:SRI管得住引用的第三方脚本,管不住首方HTML或加载器本身被服务器直接替换——而这恰恰是最原始那条攻击路径。签名验证逻辑如果还是由同一个不可信源头分发,信任链就会绕回原点,形成一个循环论证。
- 风险.SRI能防住CDN被篡改,防不住服务器直接替换首方HTML,这一层几乎无人在实际产品里补上。
Signal、WhatsApp该不该被同样定罪
原文把WhatsApp、Signal与网页蛇油加密并列批判,理由是二者都禁止第三方客户端,厂商同样保留"随时能改代码"的能力。这个类比方向是对的,但严厉程度值得打个折扣:Signal的做法更接近"不鼓励"非官方客户端,而不是文中所说的强制封禁并严格执行;它的客户端也开源,理论上第三方能做可复现构建来核对官方发布的二进制是否与源码一致。这跟一个完全闭源、连源码都看不到的网页加密工具,不是同一个信任量级。
FBI诉Apple案提供了另一个参照。Apple当年的辩护重点是"我们不愿意",不是"我们做不到"——iOS的安全控制最终靠Apple自己签名的固件强制执行,厂商想解开随时能解开。按这篇随笔的定义,iOS本身也算是"带后门"的系统,只是这把钥匙握在一家愿意打官司的公司手里,而不是一个可能随时被传票压垮的小服务商。
- 结论.判断一个"端到端加密"是否经得起推敲,先问一句能不能独立复现并核对正在运行的代码,答不上来的,基本都是营销话术。
对普通用户和企业采购方,这意味着"端到端加密"这个标签本身已经不够用了。真正该问的问题是:客户端开不开源、能不能做可复现构建、有没有透明日志记录每次代码更新。没有这几样,加密再响亮,厂商依然握着那把随时能重新铸造的钥匙。