Https 的前世今生

1、年前会议

马上要过年了，公司业务上的需求也少了很多，这不，王小二他们召开了一场技术会议，盘点年前能干点啥。

只见 C 哥写了一份清单，其中一项是全站升级 https。

C 哥说： https 是一种趋势，但目前我们接口还是 http 的。appstore 也一直要求使用 https，从安全性以及 appstore 审核的角度来看，我们年前得全站升级 https。有谁自告奋勇吗？

小二想了一下：我来做吧 C 哥，正好了解下 https。

C 哥：好，小二，那你接下来研究下 https，然后有时间再给我们分享下。

小二：好的 C 哥，保证完成！

2、深藏不露张三胖

听说小二要做 https，运维张三胖走到小二身旁。

张三胖：小二，听说你要做 https?

小二：是啊，三胖哥，我们得全站升级 https。你之前了解过吗？

张三胖：哈哈，我还真了解过，升级 https 是个不错的注意。

小二：三胖哥，那太好了，你有时间给我讲讲?我就不用花时间去查资料了。

张三胖：好，我现在正有时间，给你讲讲，也正好复习下。

小二：多谢三胖哥，今中午请你吃饭啊。

3、对称加密不足够

三胖：小二，假设你用 http 协议给你女朋友发一封私密消息。这样有没有泄密的风险呢？

小二：当然有了，http 协议是明文传输，传输数据过程中的任何第三方都可以截获并篡改该明文。

三胖微微一笑：是的，我们画幅图表示下，你就知道信息被篡改多尴尬了，哈哈。

小二：啊？确实是，那这样太尴尬了。我女朋友不打死我...

三胖：其实用 https 就可以规避。

三胖：小二，你了解对称加密与非对称加密吗？

小二：了解一些。对称加密就是加密与解密的秘钥是相同的。而非对称加密就是公钥加密的内容，必须用私钥才能解密，私钥加密的内容，必须用公钥才能解密。

三胖：小二了解的还挺多嘛，其实 https 就是利用了对称加密与非对称加密的特性。但你要注意，对称加密的速度是非对称加密速度的 100 倍左右。

小二：三胖哥我明白了，那你用刚才的例子给我讲讲 https 的原理吧。

三胖：好，就用刚才的例子。对称加密速度很快，所以你跟你女朋友的数据传输最好用对称加密。

小二：可以啊，那我跟我女朋友就先约定好一个秘钥呗？

三胖：是的，我们再画张图表示你们的数据传输过程。

小二：是啊，胖哥，这样别人就没法截获我的信息了。

三胖：对。并且因为对称加解密的速度很快，对你们数据传输速度的影响微乎其微。但是，你怎么跟你女朋友沟通协商秘钥呢？

小二：这还不简单，我直接通过网络告诉他就可以啊。

三胖：哈哈，不可以。你明文通过网络传输的秘钥被人截取了怎么办？

小二：啊？确实是，别人截取秘钥后又可以篡改我的信息了。

三胖：这时候就需要用到我们的非对称加密来协商你们对称加密的秘钥了。

4、非对称加密解忧愁

三胖：小美生成自己的公钥和私钥，通信之前，她告诉你她的公钥就可以了，这个公钥因为是公开的，所以可以随意在网络中传输了。

小二：这样啊，我明白了 C 哥。我得到小美的公钥后，然后用小美的公钥，对对称加密的密码进行非对称加密后发给小美。小美再通过他的私钥解密后，就获取了我生成的对称加密的密码了。是不是？

三胖：对，就是这样的。但是还有一个头疼的问题，你怎么确保你得到的就是小美的公钥呢？假设中间人给你截获篡改了呢？

小二：嗯...这确实是个问题。中间人把他的公钥发给我，这样我就使用中间人的公钥加密我们对称加密的密码了，然后中间人再用他的私钥解密出我们对称加密的密码。这时候中间人已经截取了小美的公钥，然后再把我们对称加密的密码通过小美的公钥加密后发给小美...太可怕了，我们对称加密的秘钥就这样被窃取了。

三胖：其实抓包工具 charles 之所以能抓 https 的包，就是利用的你说的这个原理，一会我们再细说。那现在问题就变成了，你怎么确保你得到的公钥就是小美的。

小二：哎，真让人头疼...

三胖：你知道我们平时都有公证处吧？这个公证处是一个可信的结构，经他公证的东西，都是具有可信力度的。

小二：知道啊，前几天还看新闻说一个老太把他在帝都的一套房产通过公证处公证给了一个没有血缘关系的小伙。

三胖：那你想想，如果小美的公钥经过公证后，是不是就能证明这个公钥是小美的呢？

小二：当然能够证明。只是网络中存在这样的公证处吗？

三胖：还真存在这样的公证处，我们把网络中的公证处称为 CA 吧。不得不佩服前辈们，他们把一些可信的 CA 的证书都预先存在我们的电脑里了，证书包括 CA 的信息和 CA 的公钥。只要你电脑安装了系统，就安装了这些证书。来，你看看我电脑里默认安装的证书。

小二：哦哦，明白了，意思就说这些默认的 CA 证书是绝对可信的。

三胖：对，就是这个意思。所以，只要 CA 同时给小美颁发一个证书证明是小美就可以了。CA 给小美颁发的证书中，含有小美的个人信息以及小美的公钥。同时，CA 也会给小美颁发一个私钥。

你先把小美想象成百度，我们先来看 CA 给百度颁发的证书。

小二：也就是说，只要保证 CA 给小美颁发的证书能够安全传输到我这里来就可以了。

三胖：对，现在的问题就转换成了。小美的证书如何能够安全的传输到你这里？其实，CA 给小美颁发的证书中，包含 [小美的信息+公钥] 、以及数字签名。 数字签名的内容是：使用 CA 私钥加密过的 [小美的信息+公钥] 的 hash 值。

小二：哦哦，我好像明白了。CA 的证书包含 CA 的公钥以及 CA 的一些信息，并且 CA 的证书默认存储在我的电脑里了，那我就可以使用 CA 的公钥进行解密操作，从而验证小美的证书是否是正确的了。

三胖：对的。我们可以使用你电脑里 CA 的公钥解密小美证书里的数字签名，从而得到签名的 hash 值。然后，你再用同样的 hash 算法对 [小美的信息+公钥] 进行 hash 计算。如果小美证书里签名的 hash 值与你自己计算出来的 hash 值一致，就说明这个证书确实是小美的，否则就不是小美的证书。

小二：三胖哥，我算是明白了。https 还真是麻烦，但也确实保护了我们的隐私。

三胖：对，有失必有得嘛！

小二：嗯嗯。我现在通过小美的证书安全的获取了小美的公钥。那我这儿随机生成一个对称加密的秘钥，这个对称加密的秘钥再通过小美的公钥加密后，就能安全的传输给小美了。

三胖：是，小美再用他的私钥解密，就获取了你们约定的对称加密的密码了。以后，你们就可以使用对称加密来传输数据，暗送秋波了，哈哈~

小二：三胖哥真是太厉害了，从此再也不用担心跟我女朋友聊天被恶搞了。

三胖：哈哈。你把你自己想成浏览器，把小美想成服务器。这就是整个 https 的传输流程。

小二：明白了，我画一下 https 在浏览器与服务器之间的运行流程，三胖哥你看下对不对。

三胖：不错不错，小二很厉害嘛，基本就是这个流程。

小二：没有没有，还得多谢三胖哥的指教啊，哈哈。

5、Charles 抓取 https 包的原理

三胖：小二，我们知道 charles 抓包工具能够抓取 https 的包，你知道这是什么原理吗？

小二：这我还真不知道，按理说 https 是绝对安全的协议，内容不会被 charles 抓取啊。

三胖：你记不记得，使用 charles 抓 https 包的时候，需要在你手机上安装 charles 证书并且信任该证书？

小二：对对，是有这一步操作。

三胖：就是这一步操作，可以使 Charles 抓取你的 https 包。我给你画个流程图你就明白了。

小二：原来是这样，这不就是我刚才说的问题嘛。那么就说明 https 不是安全的协议了？

三胖：不是的。因为你安装并信任 charles 证书，是你自己主动的操作，也可以说是你自己主动泄密的结果。如果你不信任该 charles 证书，那么数据就不会被传输，连接会被直接中断。所以 https 还是安全的协议。

小二：我明白了，确实是这样，多谢三胖哥。

happy done

https 的原理明白了，接下来的事情自然就水到渠成了。

小二列出了接下来要做的事情： 1、向 CA(公证处)申请自己网站的证书； 2、修改代码里静态资源的 http 链接为 https 链接； 3、修改 ajax 里面的 http 链接为 https 链接； 4、将证书部署在 nginx 上； 5、自测完成。

按照这个列表，小二一步步的顺利完成了。

最终，https 上线完成，惬意的享受午后的阳光吧，happy done~