一个故事看懂HTTPS

我是一个浏览器，每到夜深人静的时候，主人就打开我开始学习。

为了避免让别人看到浏览记录，主人选择了“无痕模式”。

但网络中老是有不少坏人，他们经过抓包截获我和服务器的通讯，主人干了什么，请求了什么数据全被他们知道了！

光窃听也就罢了，他们还常常篡改内容，在网页里面插入诱人的小广告，真是太坏了！

为了保护主人的隐私还他一个干净的上网环境，我决定对通讯加密！

初版：直接简单加密

加密嘛，很简单，把原来要发送的数据加密处理后再发给服务器就好了。

 

 

为了安全，密钥固然不能固定，每一次通讯都要随机生成。

不过接下来我犯难了，我该怎么把这个秘钥告诉服务器呢，服务器没有秘钥就解不了密，也就不知道我在请求什么资源了。

也不能直接弄个字段告诉服务器密钥，那样别人也能拿到，就跟没加密同样了。

我冥思苦想，灵机一动，决定把密钥放在数据的开头几个字节藏起来，只要私下跟服务器约定好，他用这前几个字节做为密钥解密，就能解开我发送的数据了。

 

 

你还别说，这办法还真好使，我跟服务器开始秘密通讯起来。

后来，找我使用这种办法通讯的服务器变得愈来愈多。

再后来这事就在圈子里传开了，你们都知道数据的前几个字节是密钥了，谁都能解密了。

看来这个办法不行，我得从新思考加密方法了。

第二版：非对称加密

服务器告诉我，咱们以前用的那种加密算法叫对称加密算法，也就是加密和解密使用的同一个秘钥。

还有一种叫非对称加密算法，这种算法有两个秘钥，一个公开的叫公钥，一个私藏的叫私钥。

最关键的是，公钥加密后只能用私钥解开，反过来也同样。

只要在正式的数据传输前，服务器把他的公钥告诉我，我后面用它加密数据就好了，就算被别人抓包，他也解不开，由于只有拥有私钥的服务器才能解开。

不得不说，这非对称加密真是个好东西啊！

不过这样一来只能单程加密，服务器能解密我发的，但他发给个人，我却解不了，也不能让他用私钥加密，我用公钥解密，由于公钥是公开的，谁收到都能解，不安全。

没办法，我也弄了一对儿秘钥，通讯以前咱们双方都交换一下彼此的公钥，这样就能够双向加解密了！

虽然是有点麻烦，但为了数据安全，忍了吧！

第三版：非对称与对称加密结合

但我忍了没几天就忍不住了。

这个非对称加密算法好是好，就是加解密太费时间了，致使我渲染一个网页要花好久时间，卡的不行。

我打算去跟服务器商量一下办法，没想到服务器比我更头疼，他要服务不少浏览器，每个都这么加解密，把他累的够呛。

因而咱们决定，仍是用原来的对称加密算法，这样快得多。可是一开始的时候能够用非对称加密算法来传输后面要用的秘钥，把两种算法的优点结合起来。

 

 

这一来，我只须要把后面要用到的秘钥，经过服务器公钥加密后发给他就好了，我省去了很多事儿。

第四版：秘钥计算

有一天，服务器告诉我，咱们如今的秘钥就是一个随机数，而随机数并非真正随机的，可能被预测出来，因此咱们得提高这个秘钥的安全性。

一个随机数不够，那就多弄几个！

一端容易被猜出来，那就两端一块儿生成！

咱们决定各自生成一个随机数发给对方，我再额外加密传输一个随机数给服务器，这一来，我们双方都有3个随机数了，而后双方都用这三个随机数计算出真正的秘钥，这可比一个单纯的随机数要安全得多了。

 

 

不过为了验证双方计算出来的秘钥是同样的，咱们在正式数据传输前，须要先来测试一下，如今的流程变成了这个样子：

咱们的这一方案很快获得了你们的承认，圈子里的浏览器和服务器们纷纷用上了这套方案。

第五版：数字证书

原觉得这个方案已经万无一失了，没想到我和服务器的通讯仍是泄露了···

原来有个家伙冒充服务器跟我通讯，而后又冒充我跟服务器通讯，把个人请求进行了转发，咱们俩都被蒙在鼓里，这就是中间人攻击。

 

 

看来还缺少一个认证机制！我得知道和我通讯的是否是真的服务器。

通过你们的商量，圈子里的服务器们推选了一个德高望重的前辈作公证人，让这公证人准备一对非对称加密的密钥，并在圈子里公开了公钥，全部人都得把他的公钥记下来。

服务器得去公证人这里先登记，把本身的公钥、名字等等信息报上去，公证人拿到这些信息后，计算一个Hash值，而后再用公证人的私钥把Hash值进行加密，加密后的结果就是数字签名。

 

 

最后，公证人把登记的信息和这个数字签名合在一块儿，封装了一个新的文件发给服务器，登记就完成了，而这个新的文件就是数字证书。

服务器拿到证书后，可要好生保管，由于通讯的时候，服务器需要将他们的证书发给咱们浏览器验证。

咱们浏览器拿到证书后，把证书里面的信息也计算一遍Hash，再用提早记录好的公证人的公钥把证书里的数字签名进行解密，获得公证人计算的Hash，两个一对比，就知道这证书是否是公证人签发的，以及有没有被篡改过了！

只有验证成功才能继续后面的流程，要否则就是冒充的！

这一下总算解决了中间人冒充的问题，除非中间人偷到了公证人的私钥，不然他是没办法伪造出一个证书来的。

非对称加密除了加密数据，还能用来验证身份，真是YYDS！

第六版：信任链

咱们这加密方案一传十，十传百，很快就传遍了整个互联网，想要使用这套方案的服务器愈来愈多，毕竟，谁都不但愿本身的网站被人插入小广告。

可原来的那个公证人有些忙不过来了，因而，你们开始推选更多的公证人，公证人开始多了起来，不只多了起来，并且还造成了产业链。

原来的公证人变成了一代目，一代目能够给新的公证人签发证书，新的公证人就变成了二代目，还有三代目，搞得跟传销似的。

原来只有一个公证人的时候，你们直接保存他的公钥就好了。如今公证人愈来愈多，咱们没办法保存全部的公证人的公钥了，就算能保存得下，但有新的公证人出现的时候咱们也作不到实时更新。

因而，你们约定，让全部的一代目公证人本身给本身签发一个证书，叫作根证书，并安装在咱们的操做系统中。

之后在验证网站服务器的证书时，就得先去验证证书的签发者，而后再继续验证上一级签发者，直到验证最终的签发者是否是在根证书列表中。

只要最终的签发者在系统的根证书列表中，那这条链上签署的证书就都是受信任的，不然咱们就会弹窗提醒用户：

现在，这套方案已经推广到了全世界，如今遇到使用这套方案的网站服务器时，咱们浏览器就会在地址栏加上一把小锁，表示网站很安全，还把URL地址，从HTTP，改为了HTTPS···

 

 

PS：本文用故事形式讲述了HTTPS是如何工做的，只是起一个引领入门的做用，略去了不少细节，实际状况远比这复杂，好比对称加密秘钥的计算方式、秘钥的交换算法（RSA、DH、ECDH还有区别），双方测试秘钥正确性的方式都没有体现出来，有机会再写一篇正经的技术文来详细抓包剖析HTTPS详细流程。

但愿本文对你们理解HTTPS机制有一些帮助，再看其余专业介绍时再也不吃力。

往期相关推荐

一个故事看懂Redis

一个故事看懂Docker

一个故事看懂CPU中断技术