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

前言：本文将从HTTP的隐患出发，深入剖析HTTPS如何通过加密算法、数字证书与信任链机制重塑网络通信的安全边界。我们将探讨协议的证书颁发机构（CA）的信任逻辑，以及HTTPS在性能与安全之间的平衡艺术。将帮助您更从容地应对网络威胁，在数字化浪潮中守护每一份数据的价值。

http安全问题

HTTP的三大安全隐患

① 明文传输（无加密）

• 问题：HTTP传输的所有数据（如登录密码、信用卡号、聊天记录）均以明文形式在网络中传输，攻击者可轻易窃听（如通过抓包工具Wireshark）。
• 示例：登录信息泄露

在网页中使用GET请求方法上传登录信息时账号和密码是显露在外面的，如下：

或者抓包后使用Fiddler获取协议报文同样能获取到登录信息，如下抓取到的GET请求方法的报文：

抓取到的POST请求报文：

② 无身份验证

• 问题：HTTP无法验证通信双方的真实身份。攻击者可伪装成服务器（钓鱼网站）或客户端（伪造请求）。
• 示例：公共WiFi中，攻击者伪造一个与目标网站相同的HTTP页面，诱导用户输入敏感信息。

③ 数据易篡改

• 问题：HTTP数据在传输过程中可被中间人修改（如插入广告、劫持内容），且接收方无法察觉。
• 示例：
  • 运营商在HTTP页面中注入弹窗广告。
  • 攻击者篡改软件下载链接，替换为恶意程序。

https协议在应用层和传输层之间加一个对数据加密，解密的功能，实际上属于应用层。即TLS，SSL。TLS（传输层安全协议）和 SSL（安全套接层）是用于保护网络通信安全的加密协议。它们通过在客户端（如浏览器）和服务器之间建立加密连接，确保传输的数据不被窃听或篡改。

为什么能对数据窃取或篡改：

在客户端与服务器进行通信时要先经过运营商（中间人），所以数据是暴露在外面的。除此之外还会被黑客恶意攻击。

一、密码学基本要素

1.明文

• 定义：未经加密的原始信息，可以直接被人类或机器理解。
• 特点：
  • 可读性：内容清晰明了，无需解密即可阅读（如文字、数字、文件）。
  • 风险：如果明文在传输或存储中被截获，信息会完全暴露。
• 示例：
  • 你发送的短信：“明天下午3点见面。”
  • 保存在电脑中的密码文件：“password123”。
  • HTTP 协议传输的网页内容（未加密的网站）。

2.密文

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

3.密钥

什么是密钥？

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

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

密钥怎么使用？

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

密钥类型：

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

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

二、加密方式

1.对称加密

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

举一个不恰当的例子，如：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用公钥生成密文，服务器用私钥解密。

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

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

如下图解：

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

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

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

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

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

方案四：非对称+对称

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

原理：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'。这里暂且不考虑签名者是谁，要注意的是这里的公钥和私钥是单独新引入的，不要与客户端和服务器的密钥混淆。

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

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

公钥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 证书中的公钥(是可被信任的)给随机生成的对称加密的密钥加密，传输给服务器，服务器通过私钥解密获取到对称加密密钥。
• 第三组(对称加密)：客户端和服务器后续传输的数据都通过这个对称密钥加密解密。

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