【网络编程】揭秘 HTTPS 数据安全：加密方案与证书体系的协同防护

半桔：个人主页
 🔥 个人专栏: 《网络编程》《手撕面试算法》《C++从入门到入土》

🔖消极的情绪往往来源于对过去的回忆或对未来的恐惧，专注于当下是解决问题的关键。 -埃克哈特·托利-

---

前言

在互联网蓬勃发展的今天，应用层协议的通信可靠性与安全性，直接关系到用户数据隐私、业务交互可信度等核心问题。

传统的 HTTP 协议作为应用层基础通信协议，采用明文传输模式 —— 这意味着数据在网络链路中毫无 “隐藏” 地传递，面临着三大致命风险：

• 窃听风险：第三方可轻易捕获并读取 HTTP 传输的敏感信息（如账号密码、支付订单、个人隐私数据）；
• 篡改风险：恶意主体能对传输内容进行非法修改（比如植入恶意代码、篡改交易金额），却难以被察觉；
• 伪造风险：通信双方的身份可能被冒充，导致 “和假网站 / 假服务器通信” 却浑然不知。

为解决 HTTP 的安全缺陷，HTTPS 协议（HTTP Secure）应运而生。它作为 HTTP 的 “安全增强版”，通过一系列加密技术与身份认证机制，为应用层通信构建起可靠的安全保障体系。

本文将围绕 HTTPS 保障应用层通信可靠性的核心逻辑展开，分为三大板块：

1. 加密解密的方式，以及数据指纹概念；
2. HTTPS加密过程中遇到的问题；
3. HTTPS如何解决这些问题。

接下来先解释一下有哪些加密的方式：

一. 基础知识

1.1 加密方式

加密方式分为两种：

1. 对称加密：只采用一个密钥进行加密，速度快；
2. 非对称加密：加密和解密使用不同的密钥进行；比如有两个密钥A和B，使用A进行加密后的密文可以通过B来解密，但不能通过A来解密；同样使用B加密的密文可以通过A来进行解密。非对称密钥两个密钥，其中有一个是公开的，被称为公钥，另一个不进行公开，被称为私钥。

1.2 数据摘要 && 数据指纹

“数据摘要”，可以把它类比为数据的 “数字指纹”—— 它是通过特定算法对原始数据（比如文件、文本、图片等）进行处理后，生成的一段固定长度、唯一对应原始数据的字符串。

• 其核心价值在于能够通过该指纹形成的字符串是否被修改了，而非加密（不能反向还原原始数据）。

百度网盘通过这个原理来对文件进行筛选。

• 百度网盘上的数据进行存储前，会先形成该文件的数据指纹，如果百度网盘将该数据指纹与自己服务器中已经存储过的文件进行对比，如果发现已经存在该数据指纹了，就说明服务器中存储的有，不需要再对用户上传的文件进行拷贝了。

接下来根据上面的知识，我们就可以开始自己设计一套方案来看能不能保证数据传输的稳定。

方案一：只使用对称加密

服务端与客户端进行通信的时候，先将数据进行对称加密，再发送到网络中，这种方案行不行？？？

首先有一个问题：每个客户端与服务端是否采用相同的对称加密方案，即采用一个密钥？？？

• 当然是不行的，如果采用一个密钥，如果报文被黑客拿走了，他也能进行解密。

因此需要每个客户端之间使用不同的密钥进行对称加密与服务端进行通信。

那么又有一个问题：服务端怎么知道客户端是使用什么方式进行加密的？？？

因为每个客户端使用不同的密钥进行加密，当服务端收到一个请求的时候并不知道使用哪一个密钥进行解密，那这怎么办？？？

我们必须告诉服务端使用什么密钥进行加密，如何告诉，两种方案：

1. 直接告诉服务端使用那种密钥进行加密，对该信息不进行加密。毫无疑问，这种方案是不可行的，因为如果不对该信息进行加密，别人也能拿到；
2. 告诉服务端使用那种密钥进行加密，并对该信息进行加密。这种方案可不可行？也不行因为你对该信息进行加密后，服务端都还没拿到密钥，怎么对这段信息进行解密。

综上所述：方案一是不可行的。

方案二：只使用非对称加密

双方进行通信的时候采用非对称加密的方式进行通信

如果双方采用非对称加密的方式进行通信，用一个公钥P，所有客户端都有，还有一个私钥$P\prime$。当用户发送消息之前，先用公钥P进行加密，服务端用私钥$P\prime$进行解密，能不能行？？？

客户端发送的消息，如果被黑客拿到，黑客人没有私钥$P\prime$不能进行解密；但是当服务端返回对应的响应的时候，黑客有公钥P可以进行解密，因此此方案不行。

方案三：双方采用非对称加密

双方在进行通信是使用两次非对称加密。

意思就是：

1. 客户端自己创建一个公钥C和私钥$C\prime$ ；
2. 客户端将自己的请求用服务端的公钥P进行加密，并且我们在请求中将自己创建的一个公钥C传递给服务端；
3. 服务端在进行响应的时候，使用客户端的公钥C进行加密，客户端收到后用自己创建的私钥$C\prime$ 进行解密。

通过这种方式是不是黑客就算是拿到了报文，也没有私钥不能进行解密。

是的，确实这种方式好像可以，但是存在两个问题：

1. 使用私钥进行加密和解密效率太低；
2. 依旧存在安全问题，在方案四后统一解释。

方案四：对称加密 + 非对称加密

对方案三可以进行优化：让客户端直接创建一个对称解密就行了。

1. 客户端自己创建一个对称加密的密钥C；
2. 客户端将自己的请求用服务端的公钥P进行加密，并且我们在请求中将自己创建的一个密钥C传递给服务端；
3. 服务端在进行响应的时候，使用客户端的密钥C进行加密，客户端收到后用自己创建的密钥C 进行解密。

在此期间黑客并不能拿到密钥C，所以以上也是安全的。

但是，以上四种方法都存在一个同一个安全问题。

五. 中间人攻击

以上所有假设都是在用户拿到服务器提供的公钥的情况下进行推导的，那么如果用户本身拿到的就不是一个真实的公钥怎么办。下面以方案三为例：

上面是整个过程的流程图，下面进行意义介绍：

1. 客户端向服务端请求公钥，服务端也返回公钥，但是在这个过程中，中间人自己生成了一个公钥M和私钥M’，中间人将服务端的公钥S保留，把自己的公钥M给客户端；
2. 客户端拿到的是公钥M，此时客户端像往常一样，也生成一个公钥C，和私钥C’；然后发送信息给服务端，信息中包含自己的公钥C，并且整个信息使用公钥M进行加密；
3. 中间人将客户端的数据用自己的私钥M‘进行解密，再将内部的公钥C换成自己的公钥M，然后使用服务端的公钥S进行加密，发给服务端；
4. 服务端解密后，在进行响应的时候，数据使用的是公钥M进行加密，中间人将数据解密，再用公钥C进行加密，给客户端。

整个过程，客户端和服务端都拿到了数据，同时中间人也拿到了数据。

因此现在问题就转化为了，如何保证客户端拿到的公钥是服务端的？？？

六. CA证书

CA证书就是来保证客户端人验证拿到的是服务端的公钥。

以下是CA证书申请的整个流程：

下面我们对CA证书中的内容做详细介绍：

其中比较重要的就是包含服务端的公钥，以及一个签名。

6.1 签名是什么

数字签名（Digital Signature）是一种基于非对称加密技术的安全机制，用于验证电子文档、数据或消息的完整性（未被篡改）、真实性（确实来自声称的发送方）和不可否认性。

下面详细介绍一下他是如何实现的：

流程图如下：

CA机构有一对自己的公钥和私钥，并且浏览器中内置了公钥。

1. 首先CA机构会根据除签名外的所有信息进行散列函数，类似于数据指纹，形成一串散列值，之后用CA机构的私钥对该散列值进行加密。
2. 将加密后的签名填写到对应的证书上。

当客户端向服务端请求公钥的时候，服务端会将整个证书都给客户端。

此时客户端拿到证书之后，要进行检查，保证证书没有被中间人修改：

• 此时客户端将证书上的数据与签名进行分离，对数据进行散列函数，求出散列值；同时再使用CA的公钥对签名进行解密；比较散列值和解密后的前面是否正确，就可以判断证书是否被修改。

如果数据被修改：形成的散列值不能进行匹配，客户端不会使用上面的公钥；
如果签名被修改：中间人有CA的公钥可以对签名进行解码，但是中间人没有CA的私钥，所以也不能再形成证书的签名了。

通过CA证书，有效的保证了获取到的服务端公钥是没有被篡改的。

最终方案：证书 + 对称加密 + 非对称加密

• 通过证书来保证，客户端获取到的服务端公钥是没有被篡改的，再进行密钥的交换，后续流程如下：

1. 客户端自己创建一个对称加密的密钥C；
2. 客户端将自己的请求用服务端的公钥P进行加密，并且我们在请求中将自己创建的一个密钥C传递给服务端；
3. 服务端在进行响应的时候，使用客户端的密钥C进行加密，客户端收到后用自己创建的密钥C 进行解密。