用信鸽来解释 HTTPS

本文正在参加「金石计划」。

HTTP 和 HTTPS 是常见的两种协议，但是要想让人很有印象的理解这两个概念，却不是一个容易的事情，而这篇文章做到了——HTTPS explained with carrier pigeons。本文不是翻译，是在这篇文章和个人的理解上随意画的草图，希望对大家有帮助。

HTTP 传输

Alice 和 Bob 要用信鸽通信，最简单的过程就是把写好的信直接绑在鸽子的腿上，直接放飞，这个过程就是 HTTP 传输。

HTTP 传输具有三个缺点：

1. 无状态，为了解决这个问题引入 cookie，相当于鸽子本身的「归巢」功能。
2. 明文
3. 不安全（明文的信可被 Mallory 删除一些内容、修改一些内容、添加一些内容）

接下来就是要解决剩下两个问题。

对称加密

明文通信这个问题不止现代人遇到，古代人也遇到过，比如罗马时期的凯撒大帝，如果明文通信凯撒大帝和前线将军通信万一被拦截，甚至被纂改损失是不可想象的，还没开战，大军开拔的时候凯撒和出征的将军约定，你收到我的消息，把每个字母字母表上右移动三个位置才能读取，你发给我的时候，把每个字母字母表上左移动三个位置。

比如：

明文字母表：ABCDEFGHIJKLMNOPQRSTUVWXYZ
密文字母表：DEFGHIJKLMNOPQRSTUVWXYZABC

凯撒密码这种方式就叫做对称式密钥加密，以相同的方式进行加解密。

在加解密的方法不被 Mallory 知道的情况下，确实很安全，解决了即使被 Mallory 获取，也不能破解，但依然有两个问题：

1. 密钥如何传输（线下这种约定加密方式很低效，想要和美国同学通信，坐飞机去一次美国现在约定对称加密密钥实在是费时间）
2. 信息完整性校验，虽然信息不可读，但是一旦被 Mallory 拦截并随意修改一些内容，再发送过来对接收者来讲，信息已经不完整了，比如 dog 和 god 是完全不一样的意思。

非对称加密

现在想到一个好办法，Bob 想要 Alice 回信的时候，给鸽子一条腿上绑个盒子，另一条腿上绑个锁（公钥），当 Alice 收到鸽子，把要传递的信息放入盒子，再用锁锁上盒子，放飞鸽子飞回 Bob ，Bob 用钥匙（私钥）打开盒子查看信息。

Alice 想要 Bob 回信也是这个过程，这个过程很安全。

但是鸽子每次都带着锁加盒子，实在太重了（非对称加密比对称加密更加费时，比如椭圆曲线加密计算耗时），现在优化下，第一次通信，放入盒子的信息是对称加密密钥，以后在通信用对称加密加解密信件就行了。

非对称加密解决了对称加密的密钥传输的问题。现在引发了新问题，现在 Mallory 假装自己是 Bob 放飞一个鸽子带着锁和盒子飞向 Alice，目前 Alice 是完全无法辨别的，这是问题一（身份认证），如果 Alice 被骗了，Alice 找到 Bob 赔偿 Bob 完全可以讲你怎么知道那个是我，这是问题二（不可否认）。

身份认证和不可否认

现在 Bob 讲了，我给你一个独家签名，就签在盒子上，像古天乐的薯塔签名一样独家，看到它就证明了是我：

现在问题来了，签名怎么传给你，签名本身也是密钥，我通过非对称加密给你好了，然后又遇到非对称无法识别身份的问题上来了，画个圈把自己全进去了。

这个时候 Ted 上场了说 Bob 你来我这，我给你一个独家签名，Alice 你收到签名来我这验证下，这不就解决了。

Ted 实际上就是证书签发机构——CA。

这样一举解决了身份认证和不可否认。

信息完整性校验

现在还剩一个问题——信息的完整性校验，这个也好解决，我们先用摘要算法给待传输的信息生成一个摘要，然后用对称加密的密钥加密一下，随加密信息一起发送给接收方。

收到信息的接收方用对称加密的密钥解开，用同样的摘要算法对解密的明文生成摘要，对比结果是否一致就解决了信息完整性的校验。

草图的在线地址