HTTPS加密原理

http协议是一种未加密协议，未加密的数据在传输过程中会经过一个又一个物理节点服务器内容加密，如果被人通过抓包的方式拿到了我们的数据，将会给我们造成无法估量的损失。

为了解决这个问题，就有了http+SSL/TLS = https。https通过加密内容的手段，保障了数据内容的安全性。接下来介绍https的加密方式。 1. 对称加密

加密对称：简单来说，就是有一个密钥，它可以加密一段信息，也可以对加密后的信息进行解密，这样，即使中间人拿到了密文，他不知道解密的密钥，就无法得到密文的内容。

使用加密对称，即使数据被截获，没有密钥就无法得到密文内容，也就无法修改。但是对称密钥有一个问题，如何让双方都用同一个密钥进行数据加密，同时不被别人知道。

如果浏览器内部就预存了网站A的密钥，且可以确保除了浏览器和网站A，不会有任何外人知道该密钥，那理论上用对称密钥是可以的，这样浏览器只要预存好世界上所有的网站密钥就行了，但这么做显然不现实。

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加密解密即可。

到这里我们可以总结到：

http通讯是不安全的，存在信息劫持，篡改的风险。https是加密传输，是信息安全的，在介绍https加密的时候我们首先介绍的是对称加密，但是在对称加密的过程中容易出现加密密钥被劫持的风险，因此我们采用了非对称加密的算法解决上面存在的问题，因此，https是集对称加密和非对称加密同时存在的一种加密通讯方式。

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

4. 中间人攻击

如果在数据传输过程中，中间人劫持到了数据，此时他的确无法得到浏览器生成的密钥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

通过这样的操作后，中间人就知道了服务器和浏览器之间的公钥了，这样，加密就形同虚设了。发生这种漏洞的原因：因为浏览器拿到公钥的时候，它无法确定这个公钥是服务器的，在传输过程中，公钥被篡改，一方用篡改后的公钥加密，加密形同虚设。

5. 数字证书

如何证明浏览器收到的公钥一定是该网站的公钥，这个时候就要引入第三方可信任机构，也被称作CA机构。CA机构用来解决上述浏览器无法确认收到的公钥是不是网站自身的问题。

网站只需要向CA机构申领一份数字证书，这份证书里面，包含了网站的公钥，网站的域名和其他一些网站基本信息。然后，CA机构用自己的私钥对证书进行加密，同时生成一段密文，这段密文就叫做数字签名。

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

1. CA机构拥有非对称加密的私钥和公钥

2. 网站需要申请数字证书，只需将自己网站的数据提交给CA机构（网站公钥、域名等其他信息）

3. CA机构对明文数据进行hash

4. 对hash后的值用CA机构*(此处可以称为签名者)*的私钥进行加密，得到数字签名

证书的内容大概长这样：

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

1.拿到服务器发来的数字证书，从证书中得到数字签名、公钥、域名等数据。

2. 用CA机构的公钥对数字签名解密（浏览器内置有CA机构的公钥），得到S’

3. 用hash算法对明文进行hash得到了T’

4. 通过上述步骤后，S’应当等于T’，除非明文或签名被篡改。此时比较S’是否等于T’，等于则表明证书可信。如果证书的数据没有被改动过，S和T应该是相同的，浏览器就用证书中的公钥加密数据。如果S’和T’不相等，则说明证书已经被修改，证书不可信，终止向服务器传输信息，防止信息泄露给中间人

为什么S‘和T’不一样，说明证书被篡改了呢？

这里是理解证书认证的关键，数字签名是用CA机构的私钥加密的，CA机构的私钥只有CA机构自己知道，如果证书被中间人劫持，他拿到证书，修改了证书中的公钥，因为公钥被修改后，数据的hash值就和数字签名解密后的hash值不同了，浏览器就知道证书被篡改过了，而中间人无法伪造数字签名，因为数字签名是用CA机构的私钥进行解密的。

中间人有可能把数字证书掉包吗

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

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

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

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!