Https的前世今生

Https的前世今生

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

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

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

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

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

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

深藏不露张三胖

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

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

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

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

小二：那太好了，三胖个，你有时间给我讲讲?

张三胖：好，我现在正好有时间，我也顺便复习下。

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

对称加密不足够

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

非对称加密解忧愁

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

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

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

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

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

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

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

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

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

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

三胖：还真存在这样的公证处，我们把网络中的公证处称为CA(Certificate Authority)。不得不佩服前辈们，他们把一些可信的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在浏览器与服务器之间的运行流程，三胖哥你看下对不对。

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

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

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~

---

BTW : Https原理还是需要花时间了解的，刚开始自以为懂了，但是自己写文章的时候才发现好多地方有盲点。文中可能有错误，敬请斧正。