HTTP的加密
2021-04-21 19:26
标签：审核 非对称加密 完全 如何 cli 管道 严格 个数 图片 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是安全且高效的一种协议。 参考刘超老师《趣谈网络协议》 HTTP的加密 标签：审核 非对称加密 完全 如何 cli 管道 严格 个数 图片 原文地址：https://www.cnblogs.com/CherryTab/p/12248268.html