从明文裸奔到密钥长城：HTTPS加密全链路攻防与CA信任锚点构建

定义：明文通过加密算法处理后生成的"乱码"，无法直接理解。
特点：
- 不可读性：必须通过解密才能还原为明文。
- 安全性：即使被截获，攻击者也无法直接获取原始信息（除非破解加密）。
示例：
- 明文"123456"经 AES 加密后变为：U2FsdGVkX1+2Z1z7Vp6N8g==。
- HTTPS 协议传输的加密数据（如银行交易信息）。
- 经过加密的 Wi-Fi 通信内容。

3.密钥

什么是密钥？

通常是一串随机生成的二进制数据（如 256 位随机数），用于加密算法。
不直接由用户记忆，而是由系统自动生成和管理。

与密码的区别： 密码是用户自定义的字符串（如 P@ssw0rd123），用于身份验证。安全性较低（易被猜测或暴力破解），通常需通过算法（如 PBKDF2）转换为密钥。

密钥怎么使用？

加密：明文 + 加密算法 + 密钥 → 密文。
解密：密文 + 解密算法 + 密钥 → 明文。
没有密钥，加密数据无法被还原（除非暴力破解，但现代强加密算法几乎不可行）。

密钥类型：

公钥（Public Key）：公开，可在网络中传输，能被中间人获取。
私钥（Private Key）：严格保密，保存在本地，不能在网络中传输。

这部分涉及密码学和数学，我们不做更细节的探讨。像类似加密解密的操作并不是互联网特有的，而是生活中普遍存在的。

二、加密方式

1.对称加密

场景：你有一把钥匙，用它锁上房门（加密），再用同一把钥匙打开门锁（解密）。

cpp 复制代码

举一个不恰当的例子，如：a = 10，b=20，temp = a^b
其中
    a：数据
    b：密钥
    temp：密文
    ^：加密算法
加密与解密：
    加密：temp = a^b
    解密：a = temp^b

特点：密钥相同，速度快效率高，算法公开。

2.非对称加密

非对称加密：两个密钥公开和私有，即公钥和私钥，可以是公钥加密私钥解密，或反过来，私钥加密公钥解密。

场景：邮局提供两种钥匙：

公钥：任何人都可以将信件投进你的信箱（加密）。
私钥：只有你有信箱的钥匙，能取出信件（解密）。

特点：算法复杂，效率低。

三、数据摘要（数据指纹）

数据指纹，其基本原理是利用单向散列函数(Hash 函数)对信息进行运算，生成一串固定⻓度的数字摘要。数字指纹并不是一种加密机制，因为它是不可逆的，无法进行解密（也无需解密），它的意义在于可以用来判断数据有没有被篡改。如果数据被篡改过，尽管只是有一点点的改动，数据摘要都大有不同。

数据摘要具有唯一性，和人的指纹一样，所以也叫数据指纹。

数据通过哈希算法生成的散列值就是数据摘要，在将数据摘要进行加密就是数据签名，关于数据签名的使用在下文详细讲解。

应用场景1：百度秒传

应用场景2：数据库对私有信息的保护

四、加密方案

说明：

server：服务器
client：客户端

方案一：只使用对称秘钥

server通常就只有一个，而client可以有很多，各个客户端就需要有独立的密钥，也就是每连接一个客户端，就要新生成一个密钥。那么服务器怎么得知客户端生成的密钥呢？

通过网络传输吗？那么怎么保证密钥传输的安全呢？进行加密？

这已经变成一个鸡生蛋，蛋生鸡的问题了，没有可行性（首次无法同步密钥）。我们来看方案二。

方案二：只使用非对称秘钥

server把公钥给client，给黑客获取也没关系，因为它并不知道私钥，client用公钥生成密文，服务器用私钥解密。

貌似可以解决数据安全问题，但依旧有问题。

server用私钥加密数据给client，client用公钥解密。但在此之前需要进行秘钥同步，即server需要把公钥传给client，而公钥本身是明文传送，黑客可以获取到。只是单向数据安全。
运算速度慢，效率低。

如下图解：

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

双方都有各自的公钥和私钥，用对方的公钥加密，用自己的私钥解密。

首次交互，需要进行公钥交换。

貌似可行，同样的有两个问题：

不安全。具体什么问题这里先不管，看完下文就明白了。
算法复杂，通信很慢。

方案四：非对称+对称

通过非对称密钥进行密钥协商生成对称密钥，然后使用对称密钥进行加密和解密，主要解决通信效率问题。

原理：client请求到server的公钥s，client生成自己的对称密钥x，再用公钥s对密钥x加密，传输给server，server用私钥s'解密得到密钥x，此后双方使用对称密钥x进行通信。

该方案比前三者好多了，看似无懈可击，其实还有问题，要知道道高一尺魔高一丈，我们继续往下看。

五、证书机制

1.模拟黑客攻击

对于方案四，客户端与服务器首次通信时要完成公钥协商，生成对称密钥，此后都使用对称密钥，对称密钥不会在网络中传输。所以黑客只有这一次机会。

如何攻破？其实很简单，黑客只需要在传输公钥时进行调包即可，如下：

黑客为了不被发现，并且为了让客户端与服务器能正常通信，窃取到密钥x后他会再使用密钥s进行加密发送给服务器。黑客悄无声息的拿到了密钥，没人能察觉。

既然方案4能被攻破，那么方案1,2,3就更不用说了，不攻自破。

主要问题：client无法辨别公钥是否合法，它只管一个劲的接收。

接下来对方案四进行改进，主要解决如何让client得知自己收到的"公钥"是否合法的问题。

2.数据签名

client判断"公钥"是否合法实际上就是判断数据是否被篡改过，不知道大家是否熟悉数据篡改这个词。上文所讲的数据指纹就是来验证数据是否被篡改的，已经做好了铺垫。

数据指纹：散列函数对数据进行处理生成的散列值。
签名：对数据指纹进行加密。

假设签名者：公钥Q，私钥Q'。这里暂且不考虑签名者是谁，要注意的是这里的公钥和私钥是单独新引入的，不要与客户端和服务器的密钥混淆。

最后把原始数据和签名拼在一起。发给客户端。

客户端拿到数据和签名。
用公钥Q对签名解密拿到数据指纹。
把数据用相同的散列函数生成数据指纹。
把两个数据指纹进行对比，判断数据是否被修改。

公钥Q所以人都知道，是彻底公开的，内置在客户端中。而公钥Q'是受严格保护的签名者持有。这是一种权利，其他人只认Q，对签名者绝对的信任。

现在模拟一下黑客攻击：

数据签名是传输在网络中的，黑客获取到数据签名后如果对数据篡改，客户端能校验出来。那么黑客把整个签名改了呢？即把篡改的数据重新生成签名。

不好意思客户端只认Q，用自己内置的公钥Q去解密。而黑客并不知道Q'，无法生成对应的签名。

签名者称为CA机构，CA机构是互联网信任体系的基石，通过签发和管理数字证书，确保网络实体（如网站、设备）的身份可信和通信安全。

3.CA机构

此后在密钥协商时client得到的不仅仅是一个签名，而是一个server的证书。而证书是由开发者向CA机构申请得到的。

除了签名，证书内还包含了公钥，域名等明文信息。如下：

签名：如上图第一行，对明文数据做哈希散列，然后进行加密。
明文信息：数据。
证书本质：明文数据+签名

证书就如身份证，证明服务端公钥的权威性。

数字证书保证了公钥合法性，浏览器（客户端），一般都要内置可信的CA机构或着授权的子机构的公钥。

六、最优加密方案

方案五：非对称+对称+证书验证

建立https服务器，先向CA机构申请证书。CA机构签发证书。
服务上线。
client发起请求，server返回证书，client验证公钥合法性。
公钥可信任，形成对称密钥。
双方使用对称密钥通信。

CSR在线生成工具

实际上签名时不进行数据摘要，直接对数据加密也是可行的。为什么不直接加密，而是要先 hash 形成摘要?

缩⼩签名密文的⻓度,加快数字签名的验证签名的运算速度。

总结：

HTTPS 工作过程中涉及密钥有三组：

第一组(非对称加密)：用于校验证书是否被篡改。服务器持有私钥(私钥在形成 CSR 文件与申请证书时获得)，客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些，同时持有对应的公钥)。服务器在客户端请求时，返回携带签名的证书，客户端通过这个公钥进行证书验证，保证证书的合法性，进一步保证证书中携带的服务端公钥权威性。
第⼆组(非对称加密)：用于协商生成对称加密的密钥。客户端用收到的 CA 证书中的公钥(是可被信任的)给随机生成的对称加密的密钥加密，传输给服务器，服务器通过私钥解密获取到对称加密密钥。
第三组(对称加密)：客户端和服务器后续传输的数据都通过这个对称密钥加密解密。

非常感谢您能耐心读完这篇文章。倘若您从中有所收获，还望多多支持呀！