不知道HTTPS的加密原理,相信我,看这一篇就够了!

---

前言

HTTP传输信息以明文的方式,不提供加密,因此不适合密码等重要信息。为了提高安全性,HTTPS加入了SSL协议,SSL依靠证书来验证服务器的身份,并对数据进行加密,以保障数据传输安全性,端口一般是443。本篇文章详细介绍一下HTTPS的加密原理,供大家参考学习。

---

一、对称加密和非对称加密

对称加密:加密和解密是一把钥匙。简单说就是有一个密钥，它可以加密一段信息，也可以对加密后的信息进行解密,常见的对称加密算法：DES，AES，3DES等等。
例如:和我们日常生活中用的钥匙作用差不多,我们既可以用钥匙锁门,也可以用钥匙开门。

现在我们来思考一下对称加密可不可行?
试想一下如果由服务器生成一个密钥并传输给浏览器，那在这个传输过程中密钥被别人劫持到手了怎么办？之后他就能用密钥解开双方传输的任何内容了，所以只用对称加密这么做当然不行。下面就来介绍一下另外一种加密方法:非对称加密。

非对称加密:有两把密钥，通常一把叫做公钥、一把叫私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开,常见的非对称加密算法：RSA，ECC。

鉴于非对称加密的机制，我们可能会有这种思路：

1. 服务器先把公钥以明文方式传输给浏览器
2. 之后浏览器向服务器传数据前都先用这个公钥加密好再传。
3. 服务器收到浏览器发送的数据后用私钥进行解密。

这下数据的安全似乎可以保障了,因为只有服务器有相应的私钥能解开公钥加密的数据。但如果我们继续思考一下这个流程很快又会发现问题。
公钥是一开始通过明文传输给浏览器的，若这个公钥被中间人劫持到了，那他也能用该公钥解密服务器传来的信息了,即服务器向浏览器发送数据时是不安全的。

结论:非对称加密只能保证由浏览器向服务器传输数据的安全性,那为了两端的安全,我们还能想到什么办法呢?
我们可能会想到使用用两组公钥私钥,流程如下所示:

1. 服务器拥有公钥A与对应的私钥A’；浏览器拥有公钥B与对应的私钥B’。
2. 浏览器把公钥B明文传输给服务器 , 服务器把公钥A明文给传输浏览器。
3. 浏览器向服务器传输的内容都用公钥A加密，服务器收到后用私钥A’解密。由于只有服务器拥有私钥A’，所以能保证这条数据的安全。
4. 同理，服务器向浏览器传输的内容都用公钥B加密，浏览器收到后用私钥B’解密。同上也可以保证这条数据的安全。

简单来说:就是我用你的公钥加密数据传输,你用我的公钥加密数据传输,而能解开数据的私钥分别在我们两个手中,别人就不能破解了。

这种方案看起来可以,但HTTPS的加密却没使用这种方案，为什么？
很重要的原因是非对称加密算法非常耗时，而对称加密快很多。那我们能不能把对称加密和非对称加密的特点结合起来使用,既保证安全又保证效率?

---

二、HTTPS的加密原理

既然非对称加密耗时，那非对称加密+对称加密结合可以吗?请看一下这个过程：

1. 某网站拥有用于非对称加密的公钥A、私钥A’。
2. 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
3. 浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
4. 服务器拿到后用私钥A’解密得到密钥X。

小结:这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。

看到这里大家悬下的心终于放下了,HTTPS基本就是采用了这种方案。但是这样子完美吗?

答案:这个方案还是有漏洞!归根到底的原因还是我们在数据传输过程中,有可能会被劫持数据,即中间人攻击。下面看一下这个方案的漏洞在哪里。

1. 某网站有用于非对称加密的公钥A、私钥A’。
2. 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B。
3. 浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。
4. 中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
5. 服务器拿到后用私钥A’解密得到密钥X。

从上面我们可以看出,中间人通过掉换数据包中的公钥来获取了密钥X,根本原因是浏览器无法确认收到的公钥是不是网站自己的。

如何证明浏览器收到的公钥一定是该网站的公钥？
例如:现实生活中，若想证明某身份证号一定是小明的，可以看他身份证，而身份证是由政府作证的。那能不能类似地有个机构充当互联网世界的政府？让它作为一切证明的源头，给网站颁发一个“身份证”？
答案:它就是CA机构，它是如今互联网世界正常运作的前提，而CA机构颁发的“身份证”就是数字证书。

1. 网站在使用HTTPS前，需要向CA机构申领一份数字证书,数字证书里含有证书持有者信息、公钥信息等。
2. 服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明“该公钥对应该网站”。

经过了上述的踩坑,大家不由自主就会思考如果数字证书被篡改了怎么办？接下来就来聊聊数字证书是如何进行防伪的。

---

三、如何防止数字证书被篡改？

我们把证书原本的内容生成一份“签名”，比对证书内容和签名是否一致就能判别是否被篡改。这就是数字证书的“防伪技术”，这里的“签名”就叫数字签名：

中间人有可能篡改该证书吗？
浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。

中间人有可能把证书掉包吗？
其实这并不会发生，因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了。

为什么制作数字签名时需要hash一次？
最显然的是性能问题，前面我们已经说了非对称加密效率较差，证书信息一般较长，比较耗时。而hash后得到的是固定长度的信息（比如用md5算法hash后可以得到固定的128位的值），这样加解密就快很多。

总结:证书的作用是为了证明某公钥是可信的，即“该公钥是否对应该网站”。

---

总结

关于整个HTTPS的加密原理以及流程已经介绍完毕,可能第一遍看完会有点晕,但只要多看几遍,相信下一次在遇到这个问题时,你一定能从容的回答出来。最后,附上HTTPS加密的整个流程。

---