我们在网络的行为(例如看文章、购物、上传图片),简单来说都是向服务器发送消息、接收服务器的消息,这个过程很像信鸽传书。
为了更加形象,我们把通信过程中的主要角色服务器、客户端、黑客的称呼也替换一下,Alice、Bob、Mallory。
如果 Alice 想给 Bob 发送信息,那么她就把信绑在信鸽腿上,放出信鸽,Bob 接到信鸽,拿到信纸读消息,这个过程就完成了,很不错,简单方便。
但是,坏人 Mallory 出现了,他把正在愉快飞翔的信鸽抓了下来,并把信给换了,这就麻烦了,Bob 得到了假消息。
这就是 HTTP 的沟通方式,方便但极不安全,不能传递重要信息。
Alice 和 Bob 很聪明,想到了一个好办法,他们设定了一套编码规则:把字母偏移3个位置,例如,D → A、E → B、F → C,这样,原本的消息“secret message” 就变成了 “pbzobq jbppxdb”。
Mallory 截获到消息后就会一脸懵逼,看不懂改不了,但是 Bob 知道解码规则,可以轻松转化成原文。
这个方式就是“对称式加密”。
对称式加密很安全,只要保护好key,别让其他人知道即可,但也有个问题,如果 Alice 和 Bob 在通信之前不认识,他们就没办法设定加密规则。
为了解决这个问题,通信方式又一次升级了,比如 Bob 向给 Alice 发送信息,他们的通信流程如下:
这样 Mallory 就没招儿了,Alice 和 Bob 可以愉快的通信了。
这个方式就是“非对称加密”,这个箱子就是公钥,开锁的钥匙就是私钥。
细想一下,有个问题,Bob 怎么确认箱子来自 Alice 而不是 Mallory 呢?为此,Alice 决定给箱子签个名,Bob 收到后先检查一下签名就可以确认了。
但这样还不够稳妥,Alice 决定让最权威的 Ted 来签名,Ted 是干啥的?他非常有名望,是个绝对值得信赖的家伙,他的签名大家都认,Ted 就是大名鼎鼎的 CA(Certification Authority)。
Alice 与 Ted 建立了合作,Ted 收到 Alice 的请求就会为她签名,而 Mallory 是得不到 Tex 给 Alice 的签名的,这样 Bob 就可以放心了。
这就是 HTTPS 的通信原理了,是不是很好理解。
我们可以看到 HTTPS 比 HTTP 的流程重了很多,有个箱子,还有签名,还增加了往返过程,性能肯定有所影响,这一切都是为了安全,所以我们要根据自己的需求场景来选择什么时候使用 HTTPS,什么时候使用 HTTP。
本文翻译整理自:
https://medium.freecodecamp.org/https-explained-with-carrier-pigeons-7029d2193351