当前位置：首页 > wzjs >正文

网站转化路径新能源网站开发

wzjs 2025/9/8 12:32:29

网站转化路径,新能源网站开发,租房网站那些地图区域统计怎么做的,页游网站建设详解 Https 和加密、摘要、签名、数字证书我们知道网络包是可以被截获的，那么如果涉及到敏感信息的发送，例如各种密码，就不能明文在网络上传输了，因此需要进行加密，即在网络上传输密文，到服务端后服务端经…

详解 Https 和加密、摘要、签名、数字证书

我们知道网络包是可以被截获的，那么如果涉及到敏感信息的发送，例如各种密码，就不能明文在网络上传输了，因此需要进行加密，即在网络上传输密文，到服务端后服务端经过解密进行后续操作。

加密

加密分为两种

对称加密，双方使用相同的秘钥或者算法来进行加密解密，例如异或操作，客户端发送 111 给服务端，使用全 1 字符串进行异或操作，得到 000，服务端收到 000 后，使用全 1 字符串进行异或解密，得到原数据 111（这里不考虑网络过程中出现的意外情况）。
- 优点：简单，效率高
- 缺点：怎么通知对方使用同一个秘钥（即上文的全1字符串），放在公网上传输有暴露的风险，且长时间使用同一个对称秘钥容易被破解
非对称加密，双方各生成一套公钥私钥，客户端发送数据时，使用服务端的公钥加密，服务端收到后，使用自己的私钥解密。双方都保存自己的私钥，传递消息时使用对方的公钥加密，这样即使网络包被截获，由于没有接收方的私钥，也无法被破解。
- 优点：安全
- 缺点：效率低；存在如何获取对方的公钥且保证对方的公钥真的是对方的公钥的问题（伪造者冒充服务端，把自己的公钥发送给客户端，客户端无法验证这个公钥到底是服务端还是伪造者）

数字证书

为了解决非对称加密的获取及验证对方公钥的问题，有了数字证书。

我们想一下现实生活中如何确定对方的身份，可以要求对方拿出【公安机关】开具的【身份证明】，如果【公安机关】是可信的，且【身份证明】确实是该【公安机关】开具的，那么【身份证明】也认为是可信的。

如何验证【公安机关】是可信的呢？可以去【上级公安机关】验证，依次递归，最后可以去【顶级公安机关】验证。
如何验证【身份证明】确实是该【公安机关】开具的？【身份证明】需要【公安机关】使用私钥加密，这样如果可以使用【公安机关】的公钥解密，就可以证明了。

上述流程中提到的【公安机关】我们认为是【权威机构】（即CA（ Certificate Authority）），而【身份证明】称之为【证书】（Certificate）。

现在我是服务端，我希望让客户端相信我的身份，那我就需要去 CA 备案，于是我把我的公钥、域名等信息发给了 CA，CA 在核实了我的身份之后，会将我的公钥、域名等信息封装进一个证书，并用自己的私钥对其进行签名。签名后的证书相当于一个【身份证明】，证明我是该公钥的合法拥有者，相当于 CA 为我背书。

当客户端访问服务端的时候，服务端不需要把公钥给客户端，而是给客户端一个证书，证书里有 CA 的信息，客户端自己拿 CA 的公钥校验，校验通过后就确认了服务端的身份，也拿到了服务端的公钥。

签名

在数字证书的过程中，签名是一个至关重要的步骤，通常是通过证书颁发机构（CA）来完成。

签名的过程：

摘要：CA 会对证书的内容（如公钥、证书有效期、持有者信息等）计算一个哈希值（摘要）。
私钥加密：然后，CA 使用自己的私钥对这个哈希值进行加密，生成数字签名。
数字签名：数字签名会附加在证书中，作为证书的一部分，客户端在验证时会使用 CA 的公钥来解密数字签名，并比对摘要值，确保证书内容没有被篡改。

这里顺便提一下：为什么不对证书的内容进行签名而是对其哈希值（摘要）进行签名呢？因为数据本身内容可能会很多，如果数据量大的情况下，计算出数字签名会很耗时。

摘要

**摘要（或哈希值）**是指通过特定的算法对数据进行处理，得到一个固定长度的唯一表示。这个过程是不可逆的，即从摘要值无法恢复原数据。摘要在数字证书中有非常重要的作用，特别是在签名过程和数据验证中。

摘要的过程：

数据摘要：CA 对证书内容（如公钥、有效期、持有者信息等）进行哈希计算，生成唯一的摘要值。
确保完整性：摘要算法确保数据的完整性。如果证书的任何部分被修改，摘要值就会发生变化，从而可以检测到证书是否被篡改。

Https

在最开始的加密中我们提到，对称加密效率高但不安全，存在双方传递秘钥的问题，非对称加密安全但效率比较低，那么能不能对二者进行结合，利用非对称加密传输对称加密的秘钥，之后都用对称加密的秘钥来加密数据呢？

Https 就是这么设计的，参考图示（图来自于趣谈网络协议-Https）：

这是一个双向验证证书（客户端验证服务端证书 && 服务端验证客户端证书）的流程图，流程如下：

客户端会发送 Client Hello 消息到服务器，以明文传输 TLS 版本信息、加密套件候选列表、压缩算法候选列表等信息。另外，还会有一个随机数，在协商对称密钥的时候使用。
服务器返回 Server Hello 消息, 告诉客户端，服务器选择使用的协议版本、加密套件、压缩算法等，还有一个随机数，用于后续的密钥协商。
随后，服务器会给客户端一个服务器端的证书，然后说：“Server Hello Done”。
客户端会从 CA 仓库中，拿 CA 的证书里面的公钥去解密服务器的证书，这个过程可能会递归一直找到可以验证的 CA（因为 CA 是有层级的），验证通过后就进行后续步骤。
客户端计算产生随机数字 Pre-master，发送 Client Key Exchange，用证书中的公钥加密，再发送给服务器，服务器可以通过私钥解密出来。
双方此时都有了 3 个随机数，分别是自己的、对端的、Pre-master，通过这三个随机数，可以在客户端和服务器产生相同的对称密钥。
客户端发送：“Change Cipher Spec，以后都采用协商的通信密钥和加密算法进行加密通信了”。然后发送一个 Encrypted Handshake Message，将已经商定好的参数等，采用协商密钥进行加密，发送给服务器用于数据与握手验证。
同样，服务器也可以发送 Change Cipher Spec”，并且也发送 Encrypted Handshake Message 的消息试试。当双方握手结束之后，就可以通过对称密钥进行加密传输了。

以上流程省略了服务端验证客户端证书的过程，在安全性要求比较高的环境里，可以才用服务端和客户端双向验证证书的方式。