HTTPS 安全通信原理

发布网友 发布时间：2022-09-05 18:16

我来回答

共2个回答

热心网友 时间：2024-03-11 22:45

HTTP 是明文传输，存在三大风险：窃听风险、篡改风险、冒充风险
窃听风险：由于 HTTP 明文传输，中间人可以轻易获取到通信内容。
篡改风险：中间人可以篡改信息传输内容
冒充风险：中间人可以伪装成与 Client 通信的 Server，也即是钓鱼网站。

安全通信需要包括：机密性、完整性、身份认证以及不可否认
机密性：即中间人无法获取通信的真正内容
完整性：通信内容在传输过程中不被篡改
身份认证：确认通信双方的真实身份，不被钓鱼网站冒充身份通信
不可否认：不可否认已发生的行为

HTTP 是明文传输的，而 HTTPS 采用对称加密对传输的报文加密。对称加密具有加密解密速度快、性能高的特点。HTTPS 确保通信双方使用同一把密钥对通信内容加密，以保证安全通信的机密性。

但是，对称加密的密钥是怎么获取的？如果 Server 像 Client 直接传输密钥，这个密钥仍然会被中间人截取甚至替换，如此一来，安全通信的机密性和完整性依然不能得到保证。

非对称加密：加密和解密双方使用不同的密钥，一把作为公钥，可以公开；一把作为私钥不能公开。使用公钥加密，则只能私钥解密；使用私钥加密，则只能公钥解密。
对于 Server 而言，保管好私钥，将公钥发布给其他 Client。对于 Client 而言，将对称密钥通过公钥加密，传输给Client。Client 再通过自己保留的私钥解密获取对称密钥。然后通信双方就能通过对称密钥加密通信内容了。

但是， Server 如何做到将公钥安全地传输给 Client 呢？直接传输公钥，也会存在被中间人窃取甚至掉包的风险。

为了解决公钥传输的信任问题，第三方权威机构（Certificate Authority，简称 CA）应运而生。 Server 可以向 CA 申请证书，在证书中附上公钥，然后将证书传给 Client。Server 申请证书时，会提交 DNS 主机名等信息，CA 会根据这些信息生成证书。

但是，如果证书被篡改，Client 拿到了*书，同样会有风险。

1、首先使用摘要算法（如 MD5等），将证书明文内容生成摘要，然后再用 CA 的私钥对摘要进行非对称加密（这里不直接使用私钥对明文内容进行加密，是因为使用非对称加密是十分耗时的。所以先将明文内容压缩成小得多的定长字符串，再用私钥加密，公钥解密会快得多）
2、Client 获取证书后，首先使用同样的摘要算法对明文内容生成摘要。然后将传输的加密后的摘要通过 CA 的公钥解密，获取传输过来的摘要。再将两份摘要进行对比，就能够判断证书内容是否被修改过。
这里采用 CA 私钥加密，Client 公钥解密，是保证了 身份认证 的安全性。因为只有 CA 私钥加密，Client 才能公钥解密成功。

Server 将证书传给 Client 后，Client 验签过程：

注意，这里存在两个公钥：一个是附在证书上的，站点的公钥，用于加密对称密钥；一个是 CA 的公钥，用于解密证书的签名。
那么，这里的 CA 的公钥又是怎么传输的呢？实际上，此公钥是存在与 CA证书上，而此证书（也成为 Root CA 证书）被操作系统信任，内置与操作系统上的，不存在传输过程。这样一来，Server 传输 CA 颁发的证书，客户收到证书后使用内置的 CA 证书中的公钥解密签名即可。就不再存在 CA 公钥被掉包的危险。

正常站点和中间人都可以向 CA 申请证书，并且申请的证书都是合法的。那么如果中间人在传输过程中，将 Server 传输给 Client 的证书替换成中间人自己的证书呢？
实际上，这种操作是不可行的，因为 Client 校验证书是否合法，不仅要校验签名，保证证书不被篡改，还要校验证书上的域名和自己请求的域名是否一致。如果 Client 发现域名不一致，同样会校验不通过。

但是，如果 Client 在一开始，信任了一些非法的第三方机构（称为 charles），安装了 charles 的证书，那么中间人就可以将 Server 传给 Client 的证书掉包成自己的证书，因为此时的证书不是向 CA 申请的，charles 可以自主修改证书上的域名等信息。Client 在拿到此证书后，可以使用 charles 证书的公钥验签，并校验通过，继而将对称密钥发送给中间人，如下图：

所以，中间人能够抓取 HTTPS包的前提，是 Client 信任了非法的CA证书，通过替换证书的方式使 Client 实际和中间人通信。所以，我们千万不要随便信任第三方的证书，避免安全风险。

热心网友 时间：2024-03-11 22:46