那把锁：HTTPS 到底保护了什么，以及密码是怎么真正丢的

「跟着 AI 学任何东西」系列第 59 篇。这一篇想同时回答两件事，而它们的答案几乎是相反的：

地址栏那把锁保护得非常好；而绝大多数密码丢失，根本不发生在它保护的那一段。

先把那把锁的职责范围说清楚

很多人对 HTTPS 那把小锁的理解是：「这个网站是安全的 / 可信的」。

不是。它的保证要窄得多，也精确得多：

① 你和这个域名之间的通信内容，中间人看不到（保密性）。② 也改不了，改了你能发现（完整性）。③ 你确实在跟这个域名的持有者说话，而不是冒充者（身份认证）。

注意第三条的措辞：它认的是域名，不是人品。

一个专门用来骗钱的钓鱼网站，完全可以有一把合法的锁。 因为它确实拥有那个域名，证书也确实是签给它的。锁没有说谎——它从来没打算证明网站是不是好人。

这一条是整篇文章里最有实用价值的一句：看锁没有用，要看域名。

一、加密的第一个死结：钥匙怎么送过去

先看对称加密：加密和解密用同一把钥匙。它很快，现代算法在硬件上极其高效，非常适合处理大量数据。

但它有一个致命的前提：双方得先有同一把钥匙。

问题就在这：你和一个从没见过面的服务器，在一条完全可能被监听的线路上，怎么把这把钥匙交给对方？ 你要是能安全地传钥匙，那你本来就能安全地传数据了。

这是一个真正的死结，而它被解开的方式是二十世纪最漂亮的想法之一。

二、非对称加密：一把锁配两把钥匙

非对称加密的核心是：加密和解密用的不是同一把钥匙。

• 一把叫公钥：可以完全公开，谁都能拿。用它可以加密。
• 一把叫私钥：只有你自己有。只有它能解开用对应公钥加密的东西。

不用任何数学也能理解它的形状——想象一个带投信口的信箱：

投信口是公开的，任何人都能把信投进去；但只有你有开箱的钥匙。 投信的能力和取信的能力被分开了。

这就把死结解开了：你不需要偷偷把钥匙给对方，你只需要公开地把「怎么给我加密」告诉全世界。

（反过来用也成立：用私钥「签名」一段内容，任何人都能用公钥验证这确实是你发的。这就是后面证书的基础。）

三、真实的 HTTPS：两种加密一起用

那为什么不全用非对称加密？

因为它慢——比对称加密慢得多，用它传一部视频是不现实的。

所以真实的做法是把两者的优点各取一半：

第一步（用非对称）：双方在不安全的线路上，协商出一把只用于这次会话的临时对称密钥。这一步的关键是：即使全程被监听，旁观者也推不出这把密钥。

第二步（用对称）：接下来所有的实际数据，都用这把临时密钥加密传输——快。

这个设计还带来一个重要性质：这把密钥是一次性的。下次连接会重新协商一把新的。所以即使某一天服务器的私钥泄露了，攻击者也无法用它去解开之前录下来的通信——这个性质叫前向保密。

四、最脆弱的一环：你凭什么相信那个公钥是它的

现在有一个漏洞：公钥是公开的，那中间人为什么不能把自己的公钥发给你，冒充服务器？

解决办法是证书和信任链：

1. 服务器的公钥被装进一份证书里。
2. 证书由一个证书颁发机构（CA）用它的私钥签名——相当于第三方作证「这个公钥确实属于这个域名」。
3. 你的浏览器/操作系统里预置了一批根 CA 的公钥，用它们来验证签名。

于是整个体系的信任被归结成一句话：

你信任你的操作系统和浏览器预置的那批根证书，进而信任它们签过的一切。

这是一个非常成功的设计，但也是整个体系最脆弱的地方，因为信任被委托出去了。两个具体后果：

• CA 出问题，一大片跟着出问题。 历史上有 CA 因为签发不当或被入侵而被浏览器集体不再信任的案例。
• 只要能往你的设备里塞一个根证书，就能合法地做中间人。 这就是为什么某些公司或校园网能看到员工/学生的加密流量——它们在设备上装了自己的根证书。加密没有被破解，是信任的起点被替换了。

五、那么密码到底是怎么丢的

现在到了这篇文章的另一半。上面那套体系保护的是数据在路上。而现实中账号被盗，几乎都不发生在路上。

真实的路径主要是这几条：

① 服务方的数据库被拖走。 这不取决于你，取决于对方怎么存密码。合格的做法是不存密码本身，而是存一个慢速哈希（bcrypt、scrypt、Argon2 这类）并且加盐：

• 哈希：单向变换，从结果算不回原文。
• 加盐：给每个用户拼一段随机值再哈希，让攻击者不能用一张预先算好的表批量反查，也让两个用同一个密码的人存下来的值不同。
• 慢：故意设计成计算耗时，让暴力尝试的成本高上几个数量级。

（所以「网站能把明文密码发回给你」是一个明确的危险信号——它意味着它存了原文。）

② 撞库。 上一条泄露之后，攻击者拿着「邮箱 + 密码」的组合去批量试其他网站。这一条完全取决于你：

只要你在两个网站用了同一个密码，其中任何一个泄露，另一个就等于也泄露了。 密码复用是普通人面临的最大单一风险，没有例外。

③ 钓鱼。 一个长得一模一样的登录页，域名差一个字母。你自己把密码输进去了——全程加密，全程有锁，一切正常。

这是为什么第一节那句话重要：钓鱼网站的锁是真的。锁证明「你在和这个域名安全通信」，而问题恰恰是这个域名不对。

④ 设备端。 键盘记录、恶意软件、共用电脑上残留的会话。加密对此完全无能为力——数据在被加密之前就已经被看到了。

⑤ 绕过密码本身。 通过客服、通过「忘记密码」流程、通过控制你的手机号或邮箱来重置。账号的强度等于它最弱的那条恢复路径，而这条路径常常比密码本身弱得多。

六、于是真正有效的三件事

从上面五条直接推出来，而且顺序就是重要性顺序：

① 不复用密码。 这是唯一能一次性掐掉「撞库」这整条路径的做法。人脑记不住几十个不同的强密码，所以现实的解法是用密码管理器——把「记住」外包出去，你只需要记住一个主密码。

② 开启两步验证，并优先选强的那种。 强度大致是：硬件安全密钥 / 通行密钥 > 验证器 App 生成的动态码 > 短信验证码。短信最弱，因为手机号可以被转移（SIM 劫持），而且它同时也是很多账号的恢复路径。

③ 认域名，不认锁，也不认页面长相。 页面可以像素级复制，锁可以合法拥有，域名不能。从收到的邮件或短信里点链接去登录，是所有习惯里风险最高的一个——正确的动作是自己打开书签或手动输入域名。

七、顺带：长度比「复杂度」重要

最后清掉一个被误导了很多年的直觉。

传统建议是「要有大小写、数字、符号」，于是人们造出了 P@ssw0rd! 这类东西。问题是：

这些替换规则（a→@、o→0、末尾加感叹号）是极少数几条固定套路，早就被写进破解字典里了。 它增加的是你输入的痛苦，而不是攻击者的成本。

真正决定强度的是可能性空间的大小，而它随长度指数增长。所以：

一个由几个不相关词组成的长通行短语，通常比一个短而「复杂」的密码强得多，同时还好记好输入。

（这里的「可能性空间」在信息论里有个正式的度量，也叫熵——和讲熵那篇里的那个「熵」是不同语境下的两个概念，但共享同一个直觉：它衡量的是「有多少种可能」。 密码的强度，就是猜的人要面对多少种可能。）

需要补一句边界：这一条的前提是那几个词是随机选出来的。 用一句名言或者歌词当通行短语，长度再长也没有意义——它在字典里只算一条。

收束

回到开头那个对照。

加密解决的是「路上被偷看」这个问题，而且解决得非常彻底。

而现实中账号丢失，几乎全都发生在路的两头——服务器怎么存的、你在哪儿输的、你有没有在别处用过同一个。

这是一个挺常见的模式：一个问题被解决得非常好之后，风险不会消失，它会搬到没被解决的那部分去。 而人的注意力常常还留在原地——盯着那把锁，而真正的入口在别处。

本文为学习笔记，为讲清楚做了大量简化（密钥交换的具体算法、TLS 握手细节、签名与哈希的区别等都未展开），不构成安全方案建议。具体实践请参考权威安全指南。