这一次，彻底理解https原理

[vortesnail]

我的github/blog，若star，无比感谢

建议电脑观看，图有点挤，手机屏幕太小可能看不清楚。

放轻松

作为一个前端er，你总会在学习或工作中，听到这样的声音：什么是https？你对https理解多少？说一说https吧？等此类问题，这也是在前端面试中比较容易被问到的问题，目的在于考究被面试者的知识广度，我相信你也不想在被问到的时候是以下表情：

此篇文章旨在帮助对于https完全没有了解的小小前端er建立起一个宏观的理解，此处的“宏观”并非草草了事，而是涉及到一些加密算法不予解析以及技术细节不予解读，总之这篇文章不需要多少的思考与理解能力，只需要认真地阅读，我相信你一定会理解https原理的，请放轻松。好了，让我们先来进入以下一个场景。

Michael和琪儿长期合作的伙伴关系，他们之间经常有密切的交易联系，经常会涉及一些金额的绝密信息需要通过互联网发送至对方，然而拥有技术的黑客Jack早已凯觎已久，总想着盗取点什么信息。

一天，Michael和琪儿仍然按着原来的方式来进行通信，所谓原来的方式，就是不对想要发送的信息做任何处理，直接在网络上传输：

这下，黑客Jack可乐坏了，他截获了Michael的消息，并把其中的卡号改成了自己的，给琪儿发了过去：

此时琪儿并不知道Michael发过来的信息以及被篡改过了，于是将资金打入了黑客自己的银行账号(上图中的8888)，并且出于礼貌给了一个简单的回复，这条回复事实上也能被黑客Jack截获，但是他并不在意了，收到钱后的他扬长而去，直到Michael再次发消息给琪儿催款的时候，琪儿才知道自己被黑客攻击了。

我们将以上的各种关系与我们与服务端获取发送消息的关系对应一下：

Michael	琪儿	黑客Jack	原来的方式
客服端	服务端	中间人	http

解决办法之一：对称加密

这下坏了，Michael和琪儿已经不敢在如此的进行信息交换了，不然鬼知道还要送多少钱给黑客Jack，但是生意仍然要做啊，交易也不能停止，Michael不可能为了叫琪儿打个钱还得特意坐飞机去找琪儿，并当面告诉他卡号吧？（在此请不要问为什么不打电话，问就是为了场景需要，没有电话😊）

聪明的Michael想了一会儿说：“不如你设定一个规则，我给你发消息的时候，我用这个规则去对数据进行变换，让它不会被直接认出来我们说了什么，然后你收到之后你再用这个规则将变换后的信息转变回真正的信息。你现在先给我讲一下这个规则吧”，琪儿说：“那我们将每个中文字的拼音中的每个字母用1-26的数字代替，每个英语字母.....balablabala”(此处便是一个加密及解密的“算法”，也就是一个key，具体的算法有很多，不展开)，Michael听闻后说：“这个规则(加密算法)非常nice，就这样做吧”。

以上演示的就是对称加密算法，加密和解密用的都是同一个key，且双方都互有。

不久后，琪儿发现这个方式有严重的漏洞：

• 我的客户遍布全球，如果某黑客(比如Jack)冒充我的客户，获得了我的key，也就是我的加密算法，那他岂不是又可以像之前一样截获解密其他客户发给我的消息啦？
• 就算我对每一个客户生成一个不同的key，且不说我的记忆存储成本有多高，那黑客要是在我发送key给客户的时候就截获了这个key，那他又可以肆无忌惮地解密了。

这该死的黑客把Michael和琪儿搞的很头大，不过Michael刚好认识一个搞密码学的朋友，一次闲聊中Michael从他那里得知了一种加密算法，称为非对称加密算法(RSA)，这下Michael可乐坏了，立马告诉了琪儿。

解决办法之二：非对称加密

所谓非对称加密，其实原理很简单，之前琪儿只有一个公共的key，所有客户(其中也可以有黑客)都可以获取到，或者截获到，从而能解密其他人的消息。但是现在不一样了，琪儿有两个key，一个公钥(public key)，所有人都可以获取得到；另一个是私钥(private key)，只有琪儿一个人知道。

现在Michael发正式消息之前，先问琪儿索要公钥：

得到公钥之后，使用公钥去对要发送的正式消息进行加密，琪儿接收到之后，再用自己的私钥去解密（私钥只有琪儿有，只有她才能解开这个公钥加密的内容）

现在就算黑客Jack从中间截获了Michael的消息，由于他没有琪儿的私钥，他看到的也是一阵乱七八糟的字符，根本无从解密，黑客Jack存在感下降了许多。

反过来也是同样地，如果琪儿想要给Michael发消息，也得先索要Michael的公钥，琪儿得到后用其加密发送，Michael再用自己的私钥解密。为了便于理解，我们现在只讨论单向通信，默认双方都完成了同样建立通信的动作。

在双方用非对称加密通信了一段时间后，他们又发现了这个方式通信效率特别低(这是非对称加密算法的问题，不做深究)，比之前的对称加密慢了100多倍，实在让人难以忍受，于是聪明的Michael将对称加密和非对称加密结合在一起，分两步走：“(1)琪儿先生成一个临时的对称加密的算法，也就是一个临时key，然后将该key以非对称加密(RSA)的方式发给Michael;(2)Michael安全拿到对称加密算法key之后，之后他们的通信就以对称加密方式进行”。

现在看起来解决了安全地传递对称密钥的问题，又解决了速度问题，简直妙！

在Michael为自己的聪明沾沾自喜时，黑客Jack表示这就是雕虫小计，Jack发起了恶名昭彰的中间人攻击

中间人攻击

根据以上的对称 + 非对称加密算法可知，Michael需要一开始问琪儿拿到公钥，因为黑客Jack也有自己事先设好的公钥和私钥，当他截获了Michael问琪儿索取公钥的消息，Jack就把自己的公钥发给了Michael，并假惺惺地把这条消息通过自己继续传给琪儿。

琪儿收到索取公钥的请求，将公钥发送回并附带了一条信息，黑客Jack截获了这个公钥之后，只将信息发给Michael，琪儿的公钥自己保留。

之后Michael就用Jack的公钥去加密自己想要发送给琪儿的数据信息，并被黑客Jack截获，Jack再用自己的私钥去解密，便能获取Michael的信息，而且可以随意篡改消息内容，用之前保留的琪儿的公钥去加密发送给琪儿，这一切可以用以下一张图解释：

是的，Michael和琪儿再一次被恶心到了，但是问题还是得解决啊，日子还得过，生意还得做啊。

解决办法之三：第三方公证机构涉入

上面的核心问题是Michael无法确保自己拿到的公钥是琪儿的公钥，那可不可以建立一个公证处(CA)，只要琪儿拿着自己的公钥去公证处开个证明，把一些琪儿的个人信息、开具的证明和琪儿的公钥包装成一个证书，凡是收到这个证书的客户，就能确认这是琪儿的公钥，从而再进行安全地传输。这就好像一个人去jc局开身份证一样，去开一个能证明自己身份的东西。

公证处(CA)有自己的私钥和公钥

可是一个无解的问题又冒出来了，Michael又怎么知道这个证书在传输过程中没有被黑客篡改呢？？不用担心，数字签名帮助我们～

数字签名

琪儿现在准备去公证处(CA)开具证明，但是会出现上面我们想到的无解的问题，于是琪儿先把自己的公钥和个人信息以及一些其他必要的信息用一个 hash算法 生成一个 数字摘要 ，这个 hash算法 有很好的特性，只要信息内容有一点的更改，重新使用该算法生成的 数字摘要 内容将会产生巨变。

之后，公证处(CA)使用自己的私钥对该 数字摘要 进行加密，生成一个叫做 数字签名 的东东。

数字证书

再之后，把琪儿的原始信息和 数字签名 合并，形成一个全新的东西，叫做 数字证书 

这时候，Michael问琪儿索要公钥的时候，琪儿就把该颁发的证书发送给Michael

Michael收到该证书后，先用从证书内拿到的 hash算法 对琪儿的原始信息生成新的 数字摘要 ，再用公证处(CA)的公钥对 数字签名 进行解密，也生成一个 数字摘要 ，还记得我们说过的该hash算法的特性马？只要有一点内容变动，摘要就会产生巨大变动，所以如果琪儿的一些信息被篡改了，hash生成的摘要将会与CA公钥解密得到的摘要有巨大的不同，由此可判定传过来的公钥等其他信息是否被中途篡改过。

(我知道你想问CA的公钥是如何获取的，大家先暂时理解为存在了你的操作系统里，或者自定义添加的)

如果现在Michael终于确认了是琪儿的公钥后，他就可以高枕无忧的使用非对称加密算法先获取琪儿临时生成的对称加密算法key，进行安全通信了。

结语

非常感谢大家的认真阅读，文中大量图片都是本人为了帮助大家理解绘制，希望大家通过本篇文章的阅读，真的理解了https的原理，这也是我写此文的目的，若文笔有所不适之处，请尽可能见谅。另外，本文参考了许多文章，奈何写该篇文章的时候已经不记得参考过的文章了，也没有去重新找过，故没有放出参考文章，至此抱歉。

[MJC237]

看完之后，2个字牛逼

[yang-zhifei]

讲故事的能力可以的

[JinXuanLing]

nice