HTTPS是如何保证数据传输安全性的

date

May 28, 2022

slug

https-security

status

Published

在HTTP中引入安全层

由于HTTP明文传输的特性，交易、购物等场景变得毫无安全性可言，需要引入一个加密方案。

可以发现，HTTPS其实就是在HTTP协议的基础上增加了一个安全层，核心也就是对数据的加解密。接下来就在这个安全层上实现加解密的操作。

对称加密

最简单的肯定是对称加密。如果想在两台电脑上加解密一个文件，则需要知道加解密方式和密钥。所以在HTTPS发送数据前，浏览器会和服务器协商使用什么加密方式和密钥。

浏览器发送它所支持的加密方法列表和一个随机数 client-random，加密方法列表指浏览器能支持多少种加密方法。

服务器会从加密套件列表中选取一个加密套件，然后还会生成一个随机数 service-random，并将 service-random 和加密套件列表返回给浏览器。

最后浏览器和服务器分别返回确认消息。

这样，浏览器和服务器就有了相同的client-random和service-random，双方将两个随机数根据服务器选择的加密方法，生成一个密钥，接下来就可以进行传输了。

缺点：安全性低

client-random、service-random以明文传输

随机数合成密钥的算法也是公开的

非对称加密

非对称加密指的是，私钥与公钥不同。用A加密，只能用B解密；用B加密，只能用A解密。

在HTTPS中，服务器将公钥以明文返回给浏览器，而私钥只有服务器知道。大大增加了安全性。

浏览器发送加密套件列表给服务器。

然后服务器会选择一个加密套件，不过和对称加密不同的是，使用非对称加密时服务器上需要有用于浏览器加密的公钥和服务器解密 HTTP 数据的私钥，由于公钥是给浏览器加密使用的，服务器会将加密套件和公钥一道发送给浏览器。

最后就是浏览器和服务器返回确认消息。

这样一来，浏览器向服务器发送数据时，使用公钥加密数据；服务器使用私钥解密数据，保障了数据的安全性。

缺点：

非对称加密效率很低，影响了数据响应的速度。

只能保证服务器接受数据的安全，无法保证浏览器接受数据的安全。（浏览器解密用公钥，公钥还是以明文传输的）

混合加密（对称加密与非对称加密搭配使用）

一个完美的方案诞生了：传输数据依然使用对称加密，但对称加密的密钥使用非对称加密来传输。（我加密了我的密钥）

首先浏览器向服务器发送对称加密套件列表、非对称加密套件列表和随机数 client-random；

服务器保存随机数 client-random，选择对称加密和非对称加密的套件，然后生成随机数 service-random，向浏览器发送选择的加密套件、service-random 和公钥；

浏览器保存公钥，并生成随机数 pre-master，然后利用公钥对 pre-master 加密，并向服务器发送加密后的数据；

最后服务器拿出自己的私钥，解密出 pre-master 数据，并返回确认消息。

这样，浏览器和服务器就都拥有了相同的密钥（通过选择的加密套件列表+client-random+service-random+pre-master组合）

值得一提的是，相较于对称加密，混合加密传输的pre-master虽然仍然是以明文传输，但它是经过非对称加密处理后的，这样就算被攻击，对数据安全也没有影响

数字证书

混合加密看起来似乎完美无缺，对于数据传输的安全性已经有了保障。但仍然存在问题，如果我想访问A网站，而黑客通过DNS劫持，将A网站的IP替换成了黑客的IP，这样我访问的就是黑客的服务器了，会在黑客的服务器上实现混合加密。而对于浏览器来说，是不知道访问的是黑客的站点的。

即：服务器如何向浏览器证明“我是真正的服务器”呢？

服务器想要证明自己是真正的服务器，就得通过CA的数字证书，作用有两点：

通过数字证书向浏览器证明服务器的身份

数字证书里面包含了服务器公钥。

相较于混合加密

服务器不会直接将公钥返回给浏览器，而是通过数字证书返回。

浏览器会验证数字证书

CA数字证书原理

准备一套公钥和私钥。

将公钥、站点信息等提交给CA，等待认证。

认证完成后获得证书，包含站点信息、公钥、有效期、证书序列号、签名等，签名是经过Hash加密这些信息后得到的一串密文。

浏览器验证CA过程

通过相同Hash函数获得签名中的信息A。

通过公钥解密签名，获得信息B。

比对A和B是否相等，一致则合法。

总结

对称加密毫无安全性可言。

非对称加密解决安全性问题，但本身传输速率慢。

混合加密集二者长处，使用高效的对称加密，但对对称加密的key进行非对称加密。但无法保证服务器身份是否有效。

CA证书，保证了服务器身份的合法性。