HTTPS加密原理详解-Toy模板网

这篇具有很好参考价值的文章主要介绍了HTTPS加密原理详解。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

HTTPS是什么

HTTPS全称Hypertext Transfer Protocol Secure，意为安全的超文本传输协议，简称HTTP安全版。

HTTPS在网络协议层级上位于TCP/IP协议之上，HTTP之下，跟HTTP的区别就是加入了SSL/TLS协议以确保数据安全。

他们的关系如下：

HTTPS加密原理详解

为什么需要加密

加密的原因是因为在HTTP的情况下，客户端与服务端之间数据的传输为明文，且没有认证机制，就会很容易出现数据泄露、数据篡改的情况。

我们简单的举例，假设服务器A要通过服务器B的代理程序访问到服务器C，使用HTTP协议，如下图

HTTPS加密原理详解

注意此时代理程序作为中转站，完全可以获取服务器A的请求数据，那么服务器C的响应也可以获取到，此时如果数据为明文的话，可以试想一下会有多么危险，这种情况下数据被篡改是轻而易举的。

在现在的情况下，我们再次设想，代理程序不仅可以获取到明文的数据，还可以很轻易的对请求和响应数据进行篡改。如下图

HTTPS加密原理详解

很显然，在我们未进行加密的情况下，这种情况很容易就会发生，这种情况被称之为中间人攻击。

而这里仅仅是存在一个代理的情况下就如此危险，而真实情况下，我们公网场景下的网络请求经过的设备是非常多的，如出口路由器、防火墙、出口网关、运行商等等，只要中间任意一个设备不怀好意，那我们就是待宰的羔羊。

总结来看，在我们自身程序没有做加密的情况下，HTTP方式的请求跟裸奔没有区别。

所以HTTP请求的加密至关重要，对于我们程序而言，是安全的基础保障。

从上述的总结来看，HTTP不安全主要体现在：数据泄露、数据篡改。而HTTPS就是来解决HTTP所遇到的这两个问题。

如果使用对称加密，是否可行？

如果通信的双方都持有没有其他任何人知道的密钥，使用密钥将请求和响应进行加密，那么数据就不会泄露了，因为中间方没有这密钥是解密不出来数据的。

但问题是，这个密钥要怎么让双方都知道？这个双方绝大多数情况下就是浏览器与服务器。而且密钥由哪一方面生成？如果由服务器方生成，生成后发送后浏览器，但此时发送密钥的过程仍然是明文的，这个密钥如果被中间方劫持的话，加密就没有意义了。

那么使用对称加密最大的问题就是，密钥被明文传输了，以致于数据泄露和篡改都未解决。

如果使用非对称加密，是否可行？

前面用对称加密最大的问题就是密钥被明文传输，且该密钥是加解密都可以用的。那么如果使用非对称加密的话，情况也许会有好转。

非对称加密指的是，双方拥有私钥和公钥，私钥加密后公钥解密，公钥加密后私钥解密，而公钥加密无法使用公钥解密。

此时如果服务器方拥有私钥并生成公钥，将公钥通过明文方式传输给浏览器，浏览器请求使用该公钥加密数据后请求，此时中间方无法解密数据。

这样好像只解决了浏览器请求服务器的数据泄露问题，因为服务器响应时是需要使用私钥加密数据的，如果在前面服务器传输给浏览器的公钥被劫持了，那么服务器通过私钥加密后的响应数据就会被中间方劫持的公钥解出来。我们想一下，服务器传给浏览器公钥的时候，解决了浏览器到服务器的数据泄露问题，那么如果浏览器也给服务器一个公钥的话，自然也就能解决服务器响应浏览器的数据泄露问题。如图

HTTPS加密原理详解

此时看起来是解决了数据泄露问题，但其实并未解决，先说一下现在遇到的性能问题后再来说仍存在的问题。

注意：非对称加密性能消耗比对称加密大很多，网上有人做过测试大约1500倍左右，如果全使用非对称加密，那么效率是非常慢的。

此时我们需要权衡一下，既然对称加密快，但无法解决泄露问题，非对称加密慢，但能解决泄露问题。

我们中和一下，使用非对称加密来传输他们用于对称加密的密钥，真正的数据使用对称加密来处理，那么就是如下的流程：

1、浏览器创建私钥A并生成公钥A，传递给服务器

2、服务器拿到公钥A后，创建私钥B并生成公钥B，传递给浏览器

3、然后浏览器用公钥B加密用于对称加密的密钥C，传递给服务器

4、服务器使用私钥B进行解密得到密钥C

5、然后浏览器与服务器之间使用密钥C对称加密中间数据即可。

6、注意此时中间方只有公钥A、公钥B，而我们的密钥C是通过公钥B加密的，中间方无法解密，则密钥C是安全的。

此时密钥C是安全不会存在泄露的，后续的对称加密自然也就安全了，这就是对称加密+非对称加密的组合

这样来看，性能问题也得到了改善，但即使这么复杂的玩法却出现了其他问题，也就是中间人攻击问题！

中间人攻击

前面对称加密+非对称加密确实看似解决了数据泄露问题，但这个操作在遇到中间人攻击的情况下，数据泄露仍然未被解决，而且数据篡改的问题也会体现出来。

不仅数据泄露但如果遇到了中间人攻击问题但却无法避免中间人攻击问题，如下图来解释中间人攻击的情况：

HTTPS加密原理详解

① 当服务器传给浏览器公钥A的时候，中间方劫持公钥A，并生成需要的公钥C传递给浏览器。

② 当浏览器传给服务器公钥B的时候，中间方挟持公钥B，并生成需要的公钥D传递给服务器。

③ 当浏览器发送请求时，则会使用前面得到的公钥C进行加密，此时中间方则使用已经生成好的私钥C解密，此时数据已经泄露，然后再使用劫持的公钥A重新加密数据并转发至服务器，此时数据已经被篡改

④ 相反服务器响应浏览器时也会有③步骤一样的问题。

这里问题的根源在于，服务器给浏览器公钥的时候，浏览器无法得知当前拿到的公钥是否为正确的，是否没有被篡改过？那么此时是否可以再将传输的公钥进行加密？如果这样做，就会造成一个循环了，无论如何都会有一个关键密钥处于明文传输过程中。

数字证书和数字签名

那么如果浏览器提前就知道了服务器的公钥，那么就可以避免问题，因为密钥不会进行明文传输，但这明显是不现实的。不现实的原因是互联网上的服务器很多，浏览器没有办法知道所有服务器的公钥。此时，CA机构的作用就体现出来，如图

HTTPS加密原理详解

他们的完整过程为：

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

2、CA机构将证书信息使用私钥加密、然后组装成一份完整的证书颁发给服务器。这被称之为数字证书。

3、不仅如此，CA机构颁发的证书信息中还存在签名信息，将证书信息进行hash用私钥加密，这被称之为数字签名。

4、注意证书中不仅包含证书信息，还包含数字签名。

5、在浏览器请求服务器的时候，服务器将证书(域名基本信息、颁发机构信息、公钥信息、有效期、序列号、签名算法、数字签名、扩展信息)传给浏览器。

6、假设此时证书明文信息为A，签名为B，注意因为浏览器已经提前保留了CA机构的公钥信息，所以此时验签的过程为，浏览器使用预留的公钥对签名解密后得到C1，并将证书中明文信息进行hash得到C2，此时如果C1==C2，则说明当前证书是正确的，否则说明证书存在篡改的风险。不仅校验证书信息，还会校验证书信息中的域名站点信息、有效期是否符合要求。

7、注意，到这一步时证书是不可被篡改的，因为验签是浏览器使用系统内置的CA机构公钥，中间人无法修改这一事实。

8、浏览器验证证书完成后，随机生成一个随机数X，并使用证书中公钥加密后发送给服务器。注意此时中间人无法得知密钥真实内容，因为它没有证书中私钥信息。

9、服务器使用证书的私钥解密浏览器传递过来的随机数X。

10、注意浏览器和服务器都会使用随机数X+密钥导出算法计算出随机数Y。

11、然后基于随机数Y，双方各自利用算法生成对称加密的密钥M，然后浏览器与服务器之间传输数据都是用密钥M进行对称加密操作的。

12、除了使用密钥M对称加密传输的数据以外，还会使用密钥M对原数据包进行签名，得出HMAC值，该值用于校验数据包完整。

以上就是加入了CA机构后，完整的HTTPS数据加密和交互流程，那么又会有如下的疑问：

浏览器从哪得知的这些CA机构

不是浏览器保留的，这些CA机构是由系统自身预留的，正经系统都是有预留的

如何保证证书是合法的？

如果不是被系统信任的机构颁发的证书，那么就无法使用系统预留的CA公钥信息验签成功，自然就可以确认证书合法性了。

而此时中间人如果想修改、掉包证书信息都不现实，如果修改则验签失败，如果掉包则浏览器预留的公钥解密不出来，自然验签也失败！

服务器的证书中公钥信息是明文传输给浏览器的，中间人拿到这个公钥信息后是否有风险？

注意，这个公钥信息的主要作用是加密随机数X后传递给服务器，服务器会使用私钥解密，然后双方使用相同的规则生成对称加密的密钥。这里中间人只要没有私钥信息，那么就无法得知当前的随机数X，哪怕是中间人将随机数X改了，那么导致的结果就是浏览器与服务器各自生成的密钥不一致，进而导致后续数据传输出错中止。这里最重要的就是欺负中间人没有证书私钥，在这种情况下，中间人无法解密数据，如果篡改数据则会造成浏览器与服务器双方出现错误，进而在这个时候解决了数据泄露和篡改问题。