这一次，完全理解 https 原理

个人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的原理，这也是我写此文的目的，若文笔有所不适之处，请尽量见谅。另外，本文参考了许多文章，奈何写该篇文章的时候已经不记得参考过的文章了，也没有去从新找过，故没有放出参考文章，至此抱歉。