前言

网上关于 HTTPS 的资料很多。

但很多文章默认读者已经理解了：

  • 公钥与私钥

  • 数字证书

  • TLS 握手流程

  • 对称加密与非对称加密

结果往往是：

流程图上的每一步都能看懂，但连在一起却不知道为什么这样设计。

真正让人困惑的，通常是下面三个问题：

  1. TLS 握手阶段明明有部分数据是明文传输，为什么不会泄露通信内容？

  2. 为什么 TLS 里会出现多个随机数，它们分别负责什么？

  3. 服务端发来的数据到底是用什么加密的？如果私钥能加密、公钥能解密，那岂不是任何人都能看到？

理解这三个问题，基本就理解了 HTTPS 的核心设计思想。

HTTP 的三个根本问题

HTTP 最初的目标只是实现浏览器与服务器之间的数据传输。

它并没有重点考虑通信过程中存在恶意攻击者的情况。

因此存在三个天然缺陷：

明文传输

所有数据以明文形式在网络中传播。

如果有人能够监听网络流量，就可以直接读取：

  • 用户名

  • 密码

  • 手机号

  • 银行卡信息

  • Cookie

等敏感数据。

无法验证身份

浏览器无法确认正在访问的网站是否是真实目标。

例如访问银行网站时：

浏览器并不知道对面到底是真银行，还是攻击者伪造的网站。

无法验证数据是否被篡改

即使数据成功到达客户端，也无法确认中途是否被修改。

攻击者可能：

  • 修改网页内容

  • 注入恶意脚本

  • 替换下载文件

而用户难以察觉。

HTTPS 的本质，就是通过 TLS 在 HTTP 之下建立一个安全层，解决这三个问题：

  • 保证机密性（别人看不到）

  • 保证身份真实性（知道对方是谁）

  • 保证完整性（数据没被改）

公钥与私钥：最容易被误解的部分

理解 HTTPS 之前，必须先理解非对称加密。

公钥与私钥分别负责什么

一对非对称密钥由：

  • 公钥（Public Key）

  • 私钥（Private Key）

组成。

其中：

公钥

可以公开给任何人。

作用：

  • 加密数据

  • 验证签名

私钥

只能由持有者保存。

作用：

  • 解密数据

  • 生成签名

最重要的性质是：

使用公钥加密的数据，只能由对应私钥解密。

一个非常常见的误区

很多人在第一次学习 HTTPS 时都会产生这样的疑问：

如果服务器使用私钥加密数据，客户端使用公钥解密，那么公钥是公开的，任何人都能解密，HTTPS 还有什么意义？

这个推理本身没有问题。

问题在于：

HTTPS 根本不是这么工作的。

实际上：

服务端从来不会使用私钥加密网页内容。

私钥主要承担两项职责：

  • 证明自己的身份（数字签名）

  • 在某些旧版 TLS 中参与密钥交换

而真正的业务数据传输：

全部使用对称加密完成。

因此：

私钥并不是用来加密网页内容的，而是用来证明“我确实是我”。

TLS 握手到底在做什么

很多人第一次看到 TLS 握手流程图时都会觉得复杂。

实际上，TLS 握手只做一件事：

让客户端和服务端安全地得到同一个会话密钥。

后面的所有加密通信，都依赖这把会话密钥。

为什么不用公钥直接加密所有数据

理论上可以。

但效率极低。

非对称加密算法（RSA、ECC）运算成本远高于对称加密算法（AES、ChaCha20）。

因此 HTTPS 采用了混合加密方案：

非对称加密

负责：

  • 身份验证

  • 密钥交换

对称加密

负责：

  • 实际数据传输

这样既安全又高效。

三个随机数到底在干什么

这是 TLS 中最容易让人困惑的部分。

在经典 TLS（RSA Key Exchange）流程中，会出现三个重要值：

名称 产生方 是否保密 作用
Client Random 客户端 否 标识本次连接
Server Random 服务端 否 标识本次连接
Pre-Master Secret 客户端 是 密钥派生核心材料

先说明一个背景

为了帮助理解 TLS 的设计思想，下文采用经典 RSA 密钥交换流程进行说明。

现代 TLS 1.3 已广泛采用 ECDHE 密钥交换，不再直接传输 Pre-Master Secret。

但：

协商共享秘密 → 生成会话密钥 → 使用对称加密通信

这一核心思想并没有改变。

三者如何配合

握手过程中：

第一步

客户端生成：

Client Random

发送给服务器。

第二步

服务器生成：

Server Random

发送给客户端。

第三步

客户端生成：

Pre-Master Secret

并使用服务器公钥加密后发送。

只有服务器私钥能够解密。

第四步

双方共同计算：

Master Secret

进一步派生：

Session Key

也就是后续通信真正使用的会话密钥。

为什么需要三个值

很多人会问：

有 Pre-Master Secret 不就够了吗？

实际上并不够。

Client Random 与 Server Random 的意义不仅仅是增加随机性。

更重要的是：

将当前会话与本次连接绑定。

即使未来出现：

  • 密钥材料重复

  • 会话恢复

  • 随机数质量下降

等情况。

不同连接中的 Random 值仍会参与密钥派生。

从而保证最终生成的会话密钥不同。

因此：

Client Random 与 Server Random 并不是秘密。

它们是用于区分每次连接上下文的重要参数。

一个简化理解

假设存在这样一个极度简化的公式：

会话密钥 =
(Client Random +
Server Random +
Pre-Master Secret)
mod 256

第一次连接：

CR = 7
SR = 3
PMS = 5

得到：

15

第二次连接：

CR = 9
SR = 4
PMS = 5

得到：

18

即使 Pre-Master Secret 相同。

由于 Random 值不同。

最终生成的会话密钥也不同。

真实 TLS 使用的密钥派生函数远比这个复杂。

但设计思想是一致的。

一张图看懂 HTTPS

浏览器发起连接
        │
        ▼
服务器返回证书
        │
        ▼
浏览器验证证书
        │
        ▼
获得服务器公钥
        │
        ▼
协商共享秘密
        │
        ▼
生成会话密钥
        │
        ▼
后续全部使用对称加密通信

如果记不住 TLS 握手细节。

记住这张图即可。

如果攻击者主动搞破坏怎么办

即使无法解密数据。

攻击者仍可能：

  • 篡改消息

  • 重放消息

  • 阻断消息

TLS 对此都有对应设计。

防篡改

现代 TLS（例如 TLS 1.3）普遍采用 AEAD 算法。

例如：

  • AES-GCM

  • ChaCha20-Poly1305

AEAD 会在加密的同时生成认证标签（Authentication Tag）。

如果攻击者修改了任何内容：

认证标签验证将失败。

接收方会立即丢弃该消息。

防重放

TLS 会维护消息序列信息。

消息认证过程会结合这些序列信息共同验证。

历史消息即使被原样复制并重新发送。

也无法通过验证。

无法彻底防御阻断攻击

如果攻击者直接丢弃数据包。

通信会超时失败。

这是典型的：

DoS（拒绝服务攻击）

它属于网络可用性问题。

而不是密码学问题。

HTTPS 无法保证通信一定成功。

只能保证：

  • 内容不会被偷看

  • 身份不会被伪造

  • 数据不会被偷偷修改

数字证书：怎么证明公钥属于目标网站

即使加密过程完全正确。

还有一个问题：

浏览器拿到的公钥，真的属于目标网站吗？

如果攻击者把自己的公钥冒充成银行公钥。

那么后续所有加密操作都会落入攻击者手中。

这就是：

中间人攻击（MITM）

CA 与数字证书

HTTPS 的解决方案是：

  • CA（Certificate Authority）

  • 数字证书

网站向 CA 申请证书。

CA 验证网站身份后：

使用自己的私钥对网站公钥进行签名。

于是得到数字证书。

浏览器会验证什么

浏览器收到证书后会检查：

1. 是否由可信 CA 签发

确认签名有效。

2. 域名是否匹配

访问：

example.com

证书里也必须是：

example.com

3. 是否过期

证书必须处于有效期内。

4. 是否已被吊销

防止被盗用证书继续使用。

全部通过后。

浏览器才会信任：

这把公钥确实属于当前网站。

证书不是用来加密数据的

很多人误以为：

HTTPS 是证书在加密网页。

实际上并不是。

证书真正负责的是：

将网站身份与公钥进行可信绑定。

真正负责加密数据的：

  • 非对称加密

  • 对称加密

而不是证书本身。

常见问题

握手阶段的明文数据被截获怎么办

风险极低。

因为这些明文信息本来就不属于秘密：

  • Client Random

  • Server Random

  • 证书

  • 公钥

真正敏感的数据不会明文发送。

为什么客户端不默认使用自己的证书

普通 HTTPS 场景下没有必要。

会话密钥已经能够实现安全双向通信。

只有需要强身份认证的场景：

例如：

  • 银行内部系统

  • 企业内网

  • 服务间调用

才会采用：

mTLS（双向 TLS）

如果 CA 被攻破怎么办

这是 HTTPS 信任体系最脆弱的环节之一。

历史上确实发生过：

  • 证书误签发

  • CA 被入侵

  • 伪造证书

现代浏览器通过：

  • Certificate Transparency

  • CA 审计制度

  • 证书吊销机制

降低风险。

虽然体系并不完美。

但攻破 CA 的难度远高于攻破普通网站。

总结

HTTPS 的核心逻辑其实只有四步：

  1. 通过数字证书确认服务器身份。

  2. 使用非对称加密安全协商共享秘密。

  3. 基于共享秘密生成会话密钥。

  4. 使用对称加密保护后续所有通信。

最终获得三种安全能力：

  • 机密性（Confidentiality）

  • 完整性（Integrity）

  • 身份真实性（Authentication）

理解了这四步，再看 TLS 握手流程图时，看到的就不再是一堆协议字段，而是一套在开放互联网中逐步建立信任的工程方案。

# https # 安全 # 网络协议
Logo
openEuler 社区

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐

二次打包的幽灵：应用签名校验薄弱，你的 APK 正在被肆意篡改

摘要：Android应用二次打包问题日益严重，攻击者通过反编译、篡改APK并重新签名，植入恶意代码或窃取用户数据。核心问题在于应用自身缺乏有效的签名校验机制，导致冒牌应用可正常运行。解决方案需构建"Java+Native+服务器"三重防线：Java层强化校验逻辑，Native层增加逆向难度，服务器端验证请求签名合法性。同时建议采用代码混淆、分散校验点、结合加固服务等手段，并持续监控非官方渠道。只有

avatar openEuler 社区

Linux下的进程管理

1.线程是进程内部的执行单元，也是操作系统CPU 调度的最小单位。一个进程里可以包含多个线程，所有线程共享当前进程的资源。2.核心特点-轻型实体：自身资源极少，主要靠进程提供资源。-并发执行：同一进程内多个线程可以交替使用 CPU，实现并行工作。-共享资源：全局变量、堆内存、打开的文件全部共享。-调度基本单位：CPU 真正调度、切换的是线程。进程优先级是操作系统调度器用来决定CPU资源分配顺序的核

avatar openEuler 社区

Ollama下载很慢很慢、下载不了怎么解决？

最近想本地化部署deepseek，通过ollama进行部署，但是在下载ollama的过程中，下载速度很慢很慢，要好几天才下载好。在网上找了一圈，发现Ollama下载慢主要是因国内访问其默认的境外服务器（如GitHub、Hugging Face）不稳定，看了一下它的下载链接，确实是通过GitHub进行下载。网上找了一圈，有很多方法，又怕折腾，最终还是通过网盘进行下载了，这是最省事的解决办法了。下载好

avatar openEuler 社区