HTTPS 怎么工作

有人在半路偷看

前面看到，HTTP 是收发请求和响应的约定。可是用普通 HTTP 来往的内容，是原样在路上走的。
数据包要经过家里的路由器和许多路由器，途中只要有人往里看，密码和卡号都能原样读出来。这就像寄明信片，经手的每个人都能读。上一课担心的 Cookie 号码也一样。

点一下路上的“中间人”，偷看用普通 HTTP 发出的消息。秘密被原样读出来了。

我们确认了，一偷看就能原样读到，因为内容在路上完全暴露着。
那该怎么防呢？我们没法把路堵上，也没法把半路上的人都赶走，互联网本来就是一条要经过许多人手的路。所以要换个思路：就算被看到，也让人读不懂。也就是给内容上锁。

上锁

第一步是上锁。发送之前，按照定好的规则把内容打乱，让人认不出来。这叫加密；把打乱的内容还原，叫解密。
上了锁的内容是一堆乱码，中间人看了也不知道是什么意思。只有拿着钥匙的接收方，才能把它还原成原文。这就像把明信片放进上锁的箱子里寄出去：看得见箱子，看不见里面。

点一下消息给它上锁（加密）。上了锁，文字变成乱码，中间人看了也读不懂。

上了锁，中间人看了也读不懂。可是还剩一个难题：接收方要打开，就得有钥匙。
和第一次访问的网站不可能事先就分好钥匙，所以钥匙也得在路上送过去。可这样一来，中间人连钥匙也拿到手了。这就等于锁好箱子，又把钥匙一起寄出去。这个难题该怎么解呢？

锁分给大家，钥匙自己留着

有个巧妙的办法：把用来锁的锁和用来开的钥匙分开做。锁谁都能拿去，只能用来锁上，这叫公钥。用这把锁锁上的东西，只有配对的私钥才能打开。
所以把锁撒在路上也没关系，因为它只能锁，不能开。用接收方发出的锁锁好再寄，就只有接收方自己手里的私钥才能打开。

接收方发出公钥（锁）。用这把锁锁好再寄，只有那个人的私钥才能打开。中间人的钥匙打不开。

钥匙的难题解决了。锁可以随便分给别人，因为能打开的私钥只在接收方手里。
真正的 HTTPS 只在一开始用一次这个办法，安全地商定一把双方共用的秘密钥匙，之后就用那把钥匙快速地上锁和开锁。不过还剩一件事：把锁交给我的那一方，真的是我要找的那个网站吗？要是假网站递上了它自己的锁呢？

确认是真的

最后一块拼图是确认身份。网站在递上锁的同时，还会出示一张叫证书的身份证。证书是可信的机构出具的证明，担保“这把锁确实属于这个网站”。
浏览器事先存着一份可信机构的名单，看了证书就能确认真假。假网站拿不到这样的担保，所以证书对不上时，就会弹出警告，让我们停下来。

两个网站都出示了证书。分别点一下，确认是不是真的。真的就通过，假的会弹出警告。

现在都齐了。内容上锁让人读不懂，能打开的私钥只有接收方有，对方是不是真的由证书来确认。三样凑齐，就算半路有人也能放心：看了读不懂，假的会露馅。
地址栏里的锁形标志，意思正是这个约定已经打开。不过锁形标志只说明对话上了锁，并不担保这个网站本身可信。

小结

用一句话概括：普通 HTTP 的内容是敞开的，在半路全都看得见。HTTPS 给内容上锁（加密）。
作为锁的公钥分给谁都行，用它锁上的东西只有配对的私钥才能打开。还要用证书确认对方是真的。所以卡号也好，登录用的 Cookie 也好，都能放心地发送。

依次点要点回顾一下。（明文会被偷看 → 上锁 → 锁分给大家，私钥自己留 → 用证书确认真假）

现在你知道网络上来往的数据是怎么保护的了：上锁，守住钥匙，确认对方。
到这里，我们一样样看过了数据包、地址、找路、查名字、可靠的传送、Web 上的对话以及保护它的方法。下一课把这些拼图拼到一起，从在地址栏输入网址的那一刻，到页面出现在屏幕上为止，把中间依次发生的事从头到尾走一遍。