Web 安全之 HTTPS 加解密的基本过程和中间人攻击

牵涉大量信息安全的知识，想真正理解该过程有必要了解下

小知识：HTTP 的默认端口为80，HTTPS 的默认端口为443；HTTPS = HTTP + TLS

基本加密流程

客户端和服务器同意使用 TLS 协议时，通过握手创建安全连接

1. 客户端和服务器协商支持的 TLS 版本，和支持的加密方式
2. 基于非对称密钥的身份人认证

• 服务端将公钥以证书的形式发送给前端，证书包含服务端的公钥、证书颁发机构、证书有效期、服务端域名等信息
• 客户端接收后，会选择是否信任证书，这里是否信任可依据域名、颁发机构、有效期等信息来判断，不信任则会断开连接；信任则会生成随机数，用作对称加密的密钥，并取出证书中的公钥，用公钥对随机数加密，加密结果发送给服务端
• 对称密钥是临时生成的，用一次就作废

3. 基于对称密钥的数据加密

• 服务端接收，用私钥解密，得到对称加密的密钥，用该密钥加密一段信息发给客户端，客户端解密成功，则 HTTPS 连接成功

为什么两种加密方式结合？

• 对称加密缺点：密钥一旦传输过程中被截取或者破解，没有秘密可言
• 非对称加密缺点：加解密效率低
• 结合后：用非对称加密安全传输对称加密的密钥，这样双方可以用对称加密宝保护数据，同时密钥传输过程得到保护

如何防止中间人攻击？（数字证书）

中间人攻击含义：客户端无法识别公钥的来源是否是真正的服务端，可能被替换

• 服务端通过向 CA 等被信任的机构申请 CA 私钥，并对服务端的公钥等信息进行 hash 加密生成消息摘要，用 CA 私钥对该消息摘要加密，生成数字签名，将该签名装入证书一起发给客户端
• 客户端（保存有）收到证书，用 CA 公钥对签名解密，再对服务端公钥等信息用 hash 算法生成消息摘要，将其与解密的结果对比，若一致，则证明来源可靠

好像消息摘要有所多余？直接用 CA 私钥加密不行？

• 性能问题：非对称加密效率差，而 hash 加密快很多。数据较多所以用 hash 加密，加密后的消息摘要较少再用非对称加密
• 安全问题：hash 加密具有不可逆性

如果觉得对你有帮助的话，点个赞呗~

反正发文又不赚钱，交个朋友呗~

如需转载，请注明出处foolBirdd