众所周知，http协议是一种未加密的协议，我们未加密的数据，在传输的过程中会经过一个又一个的物理节点，如果被人通过抓包的方式拿到了我们的数据，将会给我们造成无法估量的损失。
为了解决解决这个问题，https应运而生。https通过加密的手段，保障的数据的安全性。那https的怎么加密的呢？这就是我们接下来需要讨论的内容。

1、对称加密

什么是对称加密？
简单说就是有一个密钥，它可以加密一段信息，也可以对加密后的信息进行解密，和我们日常生活中用的钥匙作用差不多。
比如说小明需要给小红发送一条：Hello World,为了保证数据安全，小明把所有字母往后移动了一位，发送时的消息就变成了：Ifmmp Xpsm。

小红收到消息后，再把字母顺序往前移动一位，就得到了Hello World。

这样，即使攻击人拿到密文，他不知道怎么解密的密钥，也无法得到密文内容。

• 小明需要给小红发送一条：Hello World
• 小明使用对称加密得到密文Ifmmp Xpsm
• 传输密文
• 小红收到密文，进行解密，得到Hello World

使用对称加密，即使数据被截获，但是他没有密钥，他无法得到密文内容，也无法修改。
但是对称加密有一个问题，如何让双方都用同一个密钥进行数据加密，同时不被别人知道
如果浏览器内部就预存了网站A的密钥，且可以确保除了浏览器和网站A，不会有任何外人知道该密钥，那理论上用对称加密是可以的，这样浏览器只要预存好世界上所有HTTPS网站的密钥就行了！这么做显然不现实。

2、非对称加密

什么是非对称加密？
简单说就是有两把密钥，通常一把叫做公钥、一把叫私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。
如何使用非对称加密呢？
假如，客户端需要向服务器发送一条数据，浏览器需要保障数据的安全性，加密流程如下：

1. 某网站服务器拥有公钥A与对应的私钥A’；客户端拥有公钥B与对应的私钥B’。
2. 客户端请求服务器的公钥A，公钥A是公开的，可以明文传输
3. 客户端使用公钥A进行加密，将加密的数据发送给服务器
4. 服务器收到数据，使用私钥A`进行解密，拿到数据
   反之，服务器向客户端发送数据也是同样的流程。
   
   非对称加密算法在解决了双方交换密钥的问题，但非对称加密算法非常耗时，而对称加密快很多。那我们能不能运用非对称加密的特性解决前面提到的对称加密的漏洞？

3、非对称加密+对称加密

非对称加密能让双方进行数据交换，但性能不行，对称加密性能不错，但是无法确认双方的加密密钥，那用非对称加密完成对称加密的密钥交换，之后再用对称加密进行加密不就可以了吗？
流程如下：

1. 某网站拥有用于非对称加密的公钥A、私钥A’。
2. 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
3. 浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
4. 服务器拿到后用私钥A’解密得到密钥X。
5. 这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。

完美！这样非对称加密的性能问题也解决了。
但是，这里面还是有漏洞。

如果在数据传输过程中，中间人劫持到了数据，此时他的确无法得到浏览器生成的密钥X，这个密钥本身被公钥A加密了，只有服务器才有私钥A’解开它，然而中间人却完全不需要拿到私钥A’就能干坏事了。请看：

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

通过这一通操作，攻击者就知道服务器和浏览器之间的公钥了，这样，对称加密就形同虚设了。
为什么会发生这样的事？因为浏览器拿到公钥的时候，他无法确定这个公钥是服务器的。在传输过程中，公钥被篡改，一方用篡改后的公钥加密，非对称加密形同虚设。

4、数字证书

如何证明浏览器收到的公钥一定是该网站的公钥？这个时候，就要引入第三方机构了，也被称作CA机构。
CA机构怎么解决浏览器无法确认收到的公钥是不是网站自己的问题呢？
网站只需要向CA机构申领一份数字证书，这份证书里面，包括了网站的公钥，网站的域名和其他一些网站基本信息。
然后CA机构用自己的私钥对证书进行加密，同时生成一段密文，这段密码就叫做数字签名

数字证书的生成过程如下：

1. CA机构拥有非对称加密的私钥和公钥。
2. 网站需要申请数字证书，只需将自己网站的数据给CA机构(网站公钥，网站域名等)
3. CA机构对证书明文数据进行hash。
4. 对hash后的值用私钥加密，得到数字签名

证书的内容大概长这样

之后的浏览器验证流程如下：

• 拿到证书，从证书中得到公钥，数字签名等数据。
• 用CA机构的公钥对数字签名解密（浏览器内置CA机构的公钥），得到S。
• 用hash算法对明文进行hash得到T。
• 显然通过以上步骤，T’应当等于S‘，除非明文或签名被篡改。所以此时比较S’是否等于T’，等于则表明证书可信。如果证书的数据没有被改动过,S和T应该是相同的，则证书可信任，浏览器就用证书中的公钥加密数据。
• 如果S和T，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。

** 为什么S和T不一样，说明证书就被篡改了呢？**
这里是理解证书认证的关键，仔细思考，数字签名是用CA机构的私钥加密的，CA机构的私钥只有CA机构自己知道，如果证书被中间人劫持，他拿到证书，修改了证书中的公钥，因为公钥修改后，数据的Hash值，就和数字签名解密后的Hash值不同了，浏览器就知道证书被动过，而中间人无法伪造数字签名，因为数字签名是用CA机构的私钥加密的，他要伪造，就必须拿到CA机构的私钥！

中间人有可能把证书掉包吗
假设有另一个网站B也拿到了CA机构认证的证书，它想劫持网站A的信息。于是它成为中间人拦截到了A传给浏览器的证书，然后替换成自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了，这确实会导致上文“中间人攻击”那里提到的漏洞？

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

浏览器怎么得到CA机构的公钥
CA机构的公钥去通过网络获取，如果通过网络去获取，那CA机构生成的证书就没意义了。
一般浏览器会内置主流的CA机构的公钥。