Https——安全证书

作者：子路

链接：https://juejin.im/post/5a7146fd51882573351a9d99

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~

作者：子路

链接：https://juejin.im/post/5a7146fd51882573351a9d99