HTTP的加密

Posted 2021-03-13 cherrytab

client向server请求时，server向client响应时，都通过HTTP协议，那么涉及交易和个人信息的传递如何保证安全性？加密和管道。

 

加密有两种：对称加密，非对称加密

 

对称加密

 

在对称加密算法中，加密和解密使用的密钥是相同的。也就是说，加密和解密使用的是同一个密钥。因 此，对称加密算法要保证安全性的话，密钥要做好保密。只能让使用的人知道，不能对外公开。

这个很简单，也不安全，因为一旦黑客知道了密钥，基本你的内容就完全暴露了出来。

 

非对称加密

 

在非对称加密算法中，加密使用的密钥和解密使用的密钥是不相同的。一把是作为公开的公钥，另一把 是作为谁都不能给的私钥。公钥加密的信息，只有私钥才能解密。私钥加密的信息，只有公钥才能解 密。

 

私钥是放在client和server端的，不再网上传递，公钥是在网上传递的。

 

比如说你用公钥加密，说“我要定外卖”，黑客在中间就算截获了这个报文，因为它没有私钥也是解不 开的，所以这个报文可以顺利到达外卖网站，外卖网站用私钥把这个报文解出来，然后回复，“那给我 银行卡和支付密码吧”。

 

外卖网站回复的话，不可能用自己的私钥加密，那样谁都解不了，但是公钥又不可对称，所以一对公钥私钥是不够的，客户端也需要有自己的公钥和私钥，并且客户端要把 自己的公钥，给外卖网站。就像外卖网站把公钥给客户端一样。

 

这里的问题就是如何确定你的公钥可信度？

 

数字证书

数字证书的一个问题就是谁不都可以制造证书？真伪？那就涉及到一个第三方机构了，专门用于审核和签发可信度证书，就跟盖公章一样，为这个公钥背书。

 

HTTPS

因为非对称加密性能明显差于对称加密，而实际上我们不需要每个数据都非对称，我们可以结合起来，钥匙传输用非对称，大量数据用对称。我们可以简单形容为先打通一个管道。

 

 

 

由于是 HTTPS，客户端会发送 Client Hello 消息到服务器，以明文传输 TLS 版本信息、加密套件候选列表、压缩算法候选列表等信息。另外，还会有一个随机数，在协商对称 密钥的时候使用。

这就类似在说：“您好，我想定外卖，但你要保密我吃的是什么。这是我的加密套路，再给你个随机 数，你留着。”

 

然后，外卖网站返回 Server Hello 消息, 告诉客户端，服务器选择使用的协议版本、加密套件、压缩算 法等，还有一个随机数，用于后续的密钥协商。

这就类似在说：“您好，保密没问题，你的加密套路还挺多，咱们就按套路 2 来吧，我这里也有个随机 数，你也留着。”

 

然后，外卖网站会给你一个服务器端的证书，然后说：“Server Hello Done，我这里就这些信息了。”

你当然不相信这个证书，于是你从自己信任的 CA 仓库中，拿 CA 的证书里面的公钥去解密外卖网站的 证书。如果能够成功，则说明外卖网站是可信的。这个过程中，你可能会不断往上追溯 CA、CA 的 CA、CA 的 CA 的 CA，反正直到一个授信的 CA，就可以了。

 

证书验证完毕之后，觉得这个外卖网站可信，于是客户端计算产生随机数字 Pre-master，发送 Client Key Exchange，用证书中的公钥加密，再发送给服务器，服务器可以通过私钥解密出来。

到目前为止，无论是客户端还是服务器，都有了三个随机数，分别是：自己的、对端的，以及刚生成的 Pre-Master 随机数。通过这三个随机数，可以在客户端和服务器产生相同的对称密钥。

 

有了对称密钥，客户端就可以说：“Change Cipher Spec，咱们以后都采用协商的通信密钥和加密算法 进行加密通信了。”

然后发送一个 Encrypted Handshake Message，将已经商定好的参数等，采用协商密钥进行加密，发 送给服务器用于数据与握手验证。

 

同样，服务器也可以发送 Change Cipher Spec，说：“没问题，咱们以后都采用协商的通信密钥和加 密算法进行加密通信了”，并且也发送 Encrypted Handshake Message 的消息试试。当双方握手结束 之后，就可以通过对称密钥进行加密传输了。

 

上面的过程只包含了 HTTPS 的单向认证，也即客户端验证服务端的证书，是大部分的场景，也可以在更 加严格安全要求的情况下，启用双向认证，双方互相验证证书。

 

 

小结

非对称效率低，因为解决了密钥传输的风险，所以安全。对称效率高，不太安全。

 

非对称的打通关系主要靠一个“红头文件”的保证合法性。

 

HTTPS是安全且高效的一种协议。

 

 

参考刘超老师《趣谈网络协议》