【Linux网络加餐】深入拆解HTTPS：从密码学基础到协议工作原理全流程

🔥草莓熊Lotso：个人主页

❄️个人专栏: 《C++知识分享》 《Linux 入门到实践：零基础也能懂》

✨生活是默默的坚持，毅力是永久的享受！

🎬 博主简介：

文章目录

• 前言：
• 一. HTTPS 与密码学基础
• • 1.1 HTTPS 是什么
  • 1.2 为什么必须加密？—— 明文传输的痛点
  • 1.3 两种核心加密方式
  • 1.4 数据摘要（数字指纹）
  • 1.5 数字签名
• 二. HTTPS 加密方案的演进
• • 2.1 方案一：只使用对称加密
  • 2.2 方案二：只使用非对称加密
  • 2.3 方案三：双方都使用非对称加密
  • 2.4 方案四：非对称加密 + 对称加密
• 三. 中间人攻击（MITM）：方案四的致命漏洞
• • 3.1 中间人攻击的完整流程
  • 3.2 问题的本质
• 四. CA 证书与数字签名：身份信任的基石
• • 4.1 数字签名的原理与验证
  • 4.2 什么是 CA 证书
  • 4.3 证书的申请与签发流程
  • 4.4 客户端如何验证证书
  • 4.5 为什么证书无法被篡改或掉包？
  • 4.6 常见问题：为什么签名要先做 Hash，不直接加密原文？
• 五. HTTPS 完整工作流程（最终方案：非对称加密 + 对称加密 + CA 证书认证）
• • 5.1 完整通信流程
  • 5.2 三组密钥的分工
• 结尾：

前言：

在日常上网的过程中，我们早已习惯了浏览器地址栏前的小锁图标，它代表着当前网站使用了 HTTPS 协议，通信过程是安全的。但如果回到纯 HTTP 时代，所有数据都是明文在网络链路中 “裸奔”—— 你点击一个下载链接，数据经过运营商的路由器、交换机，运营商可以轻松解析出内容，甚至偷偷把你要下载的软件替换成另一个，这就是臭名昭著的 “运营商劫持”。本文顺着 “发现问题→提出方案→暴露缺陷→优化升级” 的思路，一步步拆解 HTTPS 的底层原理。从最基础的加密概念讲起，历经四种加密方案的演进，再到中间人攻击的漏洞分析，最终落到 CA 证书与完整握手流程，带你彻底搞懂 HTTPS 到底是如何保障数据安全的。

一. HTTPS 与密码学基础

1.1 HTTPS 是什么

很多人知道 HTTPS 是 HTTP 的安全版本，但它在网络分层中的位置很多人并不清楚。 HTTPS 本质上仍属于应用层协议，它是在 HTTP 协议和传输层 TCP 之间，增加了一层 TLS/SSL（套接字安全层），这一层专门负责加密、解密与身份认证工作。简单概括：HTTPS = HTTP + TLS/SSL 加密层。

HTTP 是明文传输，而 HTTPS 会把传输的内容先加密成密文再发出，接收方收到后解密还原成明文。全程即使数据被截获，劫持者也无法读取真实内容，更难以无痕篡改。

1.2 为什么必须加密？—— 明文传输的痛点

最典型的例子就是运营商劫持。比如用户想下载 “天天动听” APP，点击下载按钮后，浏览器向服务器发送 HTTP 请求，服务器返回包含下载链接的响应。这个响应会经过运营商的网络设备，运营商解析出内容是天天动听的下载链接，就可以偷偷把链接替换成 QQ 浏览器的下载地址，用户最终下载到的根本不是原本想要的软件。

不止运营商，局域网黑客、公共 WiFi 提供者，都可以作为中间人截获、篡改明文数据，甚至窃取账号密码，这就是中间人攻击（MITM）。HTTP 明文传输的特性，让数据在网络中毫无隐私可言，这也是 HTTPS 出现的根本原因。

1.3 两种核心加密方式

加密和解密的过程，离不开 “密钥” 的参与。根据密钥使用方式的不同，加密算法主要分为两大类：对称加密和非对称加密。

对称加密

对称加密的核心特征是：加密和解密使用同一个密钥，因此也叫单密钥加密。 常见的对称加密算法有 DES、3DES、AES、Blowfish、RC2 等。它的优势是算法公开、计算量小、加解密速度快、加密效率高，非常适合大量数据的传输加密。

我们可以用最简单的按位异或运算来理解对称加密的原理： 假设明文 a = 1234，密钥 key = 8888，加密时明文异或密钥得到密文；解密时密文再次异或同一个密钥，就能还原出明文。

对应的 C 语言示例代码如下：

#include <stdio.h>

int main(void)
{
int plain_text = 1234; // 原始明文
int key = 8888; // 对称密钥

// 加密过程：明文异或密钥生成密文
int cipher_text = plain_text ^ key;
printf("加密后密文: %d\\n", cipher_text);

// 解密过程：密文再次异或密钥还原明文
int decrypted = cipher_text ^ key;
printf("解密后明文: %d\\n", decrypted);

return 0;
}

运行结果：

加密后密文: 9834
解密后明文: 1234

当然，按位异或只是最基础的演示，HTTPS 实际使用的是更复杂的对称加密算法，但核心逻辑一致：同一个密钥同时负责加密与解密。

非对称加密

和对称加密不同，非对称加密需要一对配对的密钥：公钥（public key）和私钥（private key）。 公钥可以公开给任何人，私钥必须由持有者严格保密。用公钥加密的数据，只有对应的私钥能解密；反过来，用私钥加密的数据，只有对应的公钥能解密。

常见的非对称加密算法有 RSA、DSA、ECDSA 等。它的特点是安全性高，但算法复杂度高，加解密速度远慢于对称加密。

打个生活化的比方：B 要和 A 传递机密文件，B 先给 A 一把锁（公钥），这把锁谁都可以拿到；A 把文件放进盒子里用锁锁上，只有 B 手里的钥匙（私钥）能打开盒子。公钥不怕泄露，只有持有私钥的人才能解密数据。

1.4 数据摘要（数字指纹）

除了加密，还有一个重要概念叫数据摘要，也叫数字指纹。 它的原理是利用单向散列函数（Hash 函数）对任意长度的数据做运算，生成一串固定长度的散列值。常见的摘要算法有 MD5、SHA1、SHA256、SHA512 等。

摘要有几个关键特征：

• 不可逆：只能从原文计算摘要，几乎无法从摘要反推原文，因此它严格来说不算加密。
• 高离散性：原文哪怕只修改一个字符，生成的摘要都会天差地别。
• 定长输出：无论原文多长，同一种算法生成的摘要长度固定。

正因为这些特性，摘要最核心的作用是验证数据是否被篡改。比如百度云的 “秒传” 功能，本质就是客户端先计算文件摘要发给服务器，服务器如果已有相同摘要的文件，就无需重复上传，直接关联一份给用户即可。我们日常数据库存储密码，也不会存明文，而是存储密码的摘要，验证时对比摘要即可，大幅降低数据库泄露后的风险。

1.5 数字签名

把数据摘要用私钥加密之后，得到的结果就是数字签名。 数字签名可以同时解决两个问题：一是数据有没有被篡改，二是数据是不是预期的发送方发出的。这个概念是理解 CA 证书的核心基础，我们后面讲证书机制时会详细展开。

二. HTTPS 加密方案的演进

了解了基础加密概念后，我们一步步推导：要让 HTTP 通信安全，到底该如何设计加密方案？

2.1 方案一：只使用对称加密

最容易想到的思路就是：客户端和服务器约定同一个对称密钥，所有数据都用这个密钥加密传输。 这样一来，即使数据被截获，黑客不知道密钥，也解不开密文，看起来好像解决了明文泄露的问题。

但这个方案有两个致命缺陷：

结论：仅靠对称加密，行不通。

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

既然对称加密的密钥传输是痛点，那用非对称加密呢？ 服务器把自己的公钥明文发给客户端，客户端发数据前先用公钥加密，服务器收到后用私钥解密。因为私钥只有服务器持有，所以从客户端到服务器的链路，看起来是安全的。

但问题同样明显：

结论：只用非对称加密，也不行。

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

单向不安全，那双方都生成公私钥对、互相交换公钥呢？ 客户端持有公钥 C 和私钥 C’，服务器持有公钥 S 和私钥 S’。客户端发数据用服务器公钥 S 加密，只有服务器能解；服务器发数据用客户端公钥 C 加密，只有客户端能解。

看起来双向都安全了，但本质问题依旧存在：

• 仍然没有解决 “公钥身份认证” 的问题，中间人依然可以在公钥传输阶段替换公钥，实施攻击。
• 效率问题更加严重，双向都使用非对称加密，通信速度只会更慢。

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

既然非对称加密安全但慢，对称加密快但密钥传输难，那把两者结合起来行不行？ 核心思路：用非对称加密来协商对称密钥，后续真正的业务数据传输全程使用对称加密。

具体流程：

这个方案完美解决了效率问题：只有初始密钥协商阶段使用非对称加密，后续大量数据传输都使用速度更快的对称加密。

但是 —— 这个方案就真的绝对安全了吗？如果中间人在最开始公钥传输的阶段就已经介入了呢？

三. 中间人攻击（MITM）：方案四的致命漏洞

方案四看起来很完善，但它有一个最核心的前提假设：客户端拿到的公钥，确实是目标服务器的公钥。 如果有一个中间人，在客户端和服务器之间偷偷替换了公钥，整个加密体系就会彻底失效。

3.1 中间人攻击的完整流程

假设中间人拥有自己的公钥 M 和私钥 M’，完整攻击步骤如下：

到这一步，客户端和服务器都以为密钥协商成功，开始用 X 加密传输数据。但实际上中间人也持有完整的对称密钥 X，所有通信内容中间人都能解密窃听，甚至随意篡改，而通信双方完全无法察觉。

这就是经典的中间人攻击，方案二、三、四都逃不开这个问题。

3.2 问题的本质

根源非常直白：客户端没有任何手段验证，自己收到的公钥到底是不是目标服务器发出的。 公钥本质只是一串数据，任何人都可以生成。中间人把自己的公钥塞给客户端，客户端根本分辨不出真伪。要解决这个问题，就需要一个全网都信任的第三方机构，来给服务器的公钥做 “身份担保”—— 这就是 CA 证书。

四. CA 证书与数字签名：身份信任的基石

在讲证书机制之前，我们先把 “数字签名” 的原理讲透，它是证书能够防伪的核心。

4.1 数字签名的原理与验证

数字签名的生成和验证，基于非对称加密和摘要算法，完整流程如下：

签名生成（发送方）：

签名验证（接收方）：

为什么签名能防伪？因为私钥只有签名者自己持有，其他人既无法伪造签名，也无法篡改数据后重新生成匹配的签名 —— 只要修改一个字节，摘要就会完全对不上。

4.2 什么是 CA 证书

CA（Certificate Authority，证书颁发机构）是全网公认信任的第三方权威机构。 服务器要启用 HTTPS，需要先向 CA 机构申领一份数字证书。这份证书里包含了服务器域名、申请者信息、服务器公钥、有效期、签发机构，以及 CA 机构用自身私钥生成的数字签名。

你可以把证书理解成服务器的 “身份证”：身份证由公安局（CA 机构）签发，上面有你的身份信息和照片（服务器公钥、域名），还有公安局的公章（CA 的数字签名）。因为大家都信任公安局的权威性，所以就认可这张身份证的有效性。

4.3 证书的申请与签发流程

4.4 客户端如何验证证书

我们的操作系统和浏览器中，会内置所有权威 CA 机构的公钥。当客户端收到服务器发来的证书时，会执行以下几步验证：

只有所有验证全部通过，浏览器才会认为证书合法，服务器的公钥是可信的。

4.5 为什么证书无法被篡改或掉包？

很多人会有疑问：中间人就不能修改证书内容，或者直接换成自己的证书吗？我们分两种情况分析：

情况 1：篡改证书明文内容 中间人可以修改证书里的公钥或域名，但他没有 CA 机构的私钥，无法为修改后的内容重新生成正确的数字签名。客户端一验证，摘要就会对不上，立刻就能发现证书被篡改，终止连接并提示安全风险。

情况 2：整体掉包成自己的证书 中间人确实可以自己向 CA 申请一张合法证书，但申请证书必须绑定独立域名。他把自己的证书发给客户端，客户端一对比，证书中的域名和当前访问的网站域名不匹配，立刻就能识别异常。且正规 CA 机构审核严格，中间人不可能申请到他人域名的证书。

因此，只要 CA 机构的私钥不泄露，证书就是安全的，中间人既改不了内容，也无法整体掉包。

4.6 常见问题：为什么签名要先做 Hash，不直接加密原文？

核心原因是提升效率，缩小签名长度。 非对称加密本身速度较慢，如果直接加密整篇证书原文，计算量会非常大。而 Hash 摘要长度很短（比如 SHA256 仅 32 字节），加密摘要的速度快得多，同时又能完整保证原文不可篡改，兼顾了安全与性能。

五. HTTPS 完整工作流程（最终方案：非对称加密 + 对称加密 + CA 证书认证）

有了 CA 证书机制之后，我们就得到了 HTTPS 的最终方案：非对称加密 + 对称加密 + CA 证书认证。

5.1 完整通信流程

我们把整个 HTTPS 握手 + 通信的过程从头到尾梳理一遍：

5.2 三组密钥的分工

整个 HTTPS 流程中，一共涉及三组不同的密钥，各司其职：

• 第一组（CA 的公私钥）：用于验证证书合法性。CA 持有私钥，用于给证书签名；客户端内置 CA 公钥，用于验证签名。这一组的核心作用是：保证服务器公钥是可信的。
• 第二组（服务器的公私钥）：用于协商对称密钥。服务器持有私钥，客户端用证书里的公钥加密对称密钥后传输。这一组的作用是：安全地将对称密钥从客户端传递到服务器。
• 第三组（协商生成的对称密钥）：用于后续所有业务数据的加解密。这一组是真正负责 HTTP 数据加密的核心，前两组密钥机制都是为了安全交付这组密钥服务的。

简单总结：HTTPS 的一切机制，都围绕 “安全地让双方拿到同一个对称密钥” 展开，这是整个协议的核心逻辑。

总结与核心考点梳理

结尾：

🍓 我是草莓熊 Lotso！若这篇技术干货帮你打通了学习中的卡点：
👀 【关注】跟我一起深耕技术领域，从基础到进阶，见证每一次成长
❤️ 【点赞】让优质内容被更多人看见，让知识传递更有力量
⭐ 【收藏】把核心知识点、实战技巧存好，需要时直接查、随时用
💬 【评论】分享你的经验或疑问（比如曾踩过的技术坑？），一起交流避坑
🗳️ 【投票】用你的选择助力社区内容方向，告诉大家哪个技术点最该重点拆解
技术之路难免有困惑，但同行的人会让前进更有方向～愿我们都能在自己专注的领域里，一步步靠近心中的技术目标！

结语：从明文 HTTP 到加密 HTTPS，本质是互联网发展到一定阶段后，对数据安全和身份可信的必然要求。它没有使用什么颠覆性的 “黑科技”，而是把对称加密、非对称加密、摘要算法、数字签名、第三方信任机构这些技术巧妙组合，逐层解决了 “数据泄露”、“数据篡改”、“身份伪造” 三大核心问题。理解 HTTPS，不止是记住一个流程，更要理解每一层设计背后的权衡与考量。安全和效率永远是架构设计的两大主题，HTTPS 正是在两者之间找到极佳平衡的经典范例。

✨把这些内容吃透超牛的！放松下吧✨

ʕ˘ᴥ˘ʔ

づきらど