357 lines
14 KiB
Markdown
357 lines
14 KiB
Markdown
# HTTPS/TLS 通信原理详解
|
||
|
||
> 本文基于视频内容深度扩展，补充技术细节与常见误区
|
||
|
||
---
|
||
|
||
## 一、加密基础
|
||
|
||
### 1.1 对称加密（Symmetric Encryption）
|
||
|
||
加密和解密使用**同一把密钥**。
|
||
|
||
```
|
||
明文 + 密钥 → 密文
|
||
密文 + 密钥 → 明文
|
||
```
|
||
|
||
特点：
|
||
- 速度快，适合加密大量数据
|
||
- 核心问题：**密钥如何安全传递给对方？**（密钥分发问题）
|
||
|
||
常见算法：AES-256-GCM、ChaCha20、3DES
|
||
|
||
### 1.2 非对称加密（Asymmetric Encryption）
|
||
|
||
每人持有一对密钥：
|
||
- **公钥（Public Key）**：可公开分发，用于加密
|
||
- **私钥（Private Key）**：严格保密，用于解密
|
||
|
||
```
|
||
明文 + 公钥 → 密文
|
||
密文 + 私钥 → 明文
|
||
```
|
||
|
||
也可以反向用——私钥签名，公钥验签：
|
||
```
|
||
明文 + 私钥 → 签名
|
||
签名 + 公钥 → 验证通过/失败
|
||
```
|
||
|
||
特点：
|
||
- 解决了密钥分发问题
|
||
- 速度慢，CPU 开销约是对称加密的 100-1000 倍
|
||
- 不适合加密大数据
|
||
|
||
常见算法：RSA（2048/4096 位）、ECC（Elliptic Curve Cryptography，ECDSA、ECDH）
|
||
|
||
**ECC 相比 RSA 的优势**：用更短的密钥达到同等安全强度（RSA-2048 ≈ ECC-256），握手更快、证书更小。
|
||
|
||
### 1.3 混合加密（Hybrid Encryption）
|
||
|
||
实际应用中，HTTPS 同时使用两种加密：
|
||
|
||
1. 用非对称加密**安全交换**一个临时会话密钥
|
||
2. 用对称加密（会话密钥）**高效传输**实际数据
|
||
|
||
这是 TLS 的核心设计思想。
|
||
|
||
---
|
||
|
||
## 二、TLS 握手详解
|
||
|
||
TLS 握手是建立安全连接的核心过程。以下以 **TLS 1.2** 和 **TLS 1.3** 分别说明。
|
||
|
||
### 2.1 TLS 1.2 握手流程
|
||
|
||
以 RSA 密钥交换为例（最常见）：
|
||
|
||
```
|
||
客户端 服务端
|
||
| |
|
||
|---- ClientHello (支持的密码套件, 客户端随机数) ---->|
|
||
| |
|
||
|<--- ServerHello (选定的密码套件, 服务端随机数) -----|
|
||
|<--- 服务器证书 (含公钥) ---------------------------|
|
||
|<--- ServerKeyExchange (DH参数，可选) ---------------|
|
||
| |
|
||
| 客户端验证证书链，提取公钥 |
|
||
| |
|
||
|---- ClientKeyExchange (用公钥加密的预备主密钥) --->|
|
||
| |
|
||
| 双方用 客户端随机数 + 服务端随机数 + 预备主密钥 |
|
||
| 计算出相同的"会话密钥"(对称密钥) |
|
||
| |
|
||
|---- ChangeCipherSpec (切换到加密模式) ------------->|
|
||
|---- Finished (加密的握手消息摘要) ---------------->|
|
||
| |
|
||
|<--- ChangeCipherSpec -------------------------------|
|
||
|<--- Finished --------------------------------------|
|
||
| |
|
||
|======= 之后所有 HTTP 数据用会话密钥加密传输 =======|
|
||
```
|
||
|
||
关键点：
|
||
- 客户端和服务端各有一个**随机数**（防重放）
|
||
- 预备主密钥（Pre-Master Secret）由客户端生成，用服务端公钥加密后发送
|
||
- 最终会话密钥 = PRF(客户端随机数 || 服务端随机数 || 预备主密钥)
|
||
|
||
**ECDHE 握手**（TLS 1.2 更常见的方式）：
|
||
- 服务端和客户端各自生成临时 EC 密钥对
|
||
- 通过 ECDH 算法各自推导出相同的预备主密钥
|
||
- 特点：**前向保密（Forward Secrecy）**——即使未来私钥泄露，历史会话仍安全（因为每次会话的密钥都是临时的）
|
||
|
||
### 2.2 TLS 1.3 握手流程（2018 年标准化）
|
||
|
||
TLS 1.3 大幅简化了握手：
|
||
|
||
```
|
||
客户端 服务端
|
||
| |
|
||
|---- ClientHello (支持的密码套件, 客户端随机数) --->|
|
||
| + (可选) 客户端 DH/ECDH 公钥 |
|
||
| |
|
||
|<--- ServerHello (选定的密码套件, 服务端随机数) -----|
|
||
|<--- 服务器证书 + 证书验证 + 服务端 DH 公钥 --------|
|
||
|<--- Finished --------------------------------------|
|
||
| |
|
||
| 客户端用服务端 DH 公钥 + 客户端 DH 私钥 |
|
||
| 计算出会话密钥 |
|
||
| |
|
||
|---- 证书验证 + Finished -------------------------->|
|
||
| |
|
||
|========= 1-RTT 后开始加密传输 ====================|
|
||
```
|
||
|
||
改进：
|
||
- **1-RTT**（TLS 1.2 RSA 握手是 2-RTT）
|
||
- 废弃了 RSA 密钥交换（不支持不支持前向保密的 RSA），**强制前向保密**
|
||
- 废弃了 CBC 模式（易遭 BEAST 等攻击），只用 GCM/Chacha20-Poly1305
|
||
- 握手消息在加密通道中传输（TLS 1.2 的前半部分在明文）
|
||
|
||
---
|
||
|
||
## 三、证书与 CA 信任链
|
||
|
||
### 3.1 证书内容
|
||
|
||
X.509 证书包含：
|
||
|
||
```
|
||
证书版本 / 序列号
|
||
持有者信息 (Subject)
|
||
颁发者信息 (Issuer)
|
||
公钥 + 算法
|
||
证书有效期 (Not Before / Not After)
|
||
扩展字段 (SAN, 密钥用途, CA 路径长度等)
|
||
CA 的数字签名
|
||
```
|
||
|
||
关键扩展：
|
||
- **Subject Alternative Name (SAN)**：证书允许的域名列表（支持通配符如 `*.example.com`）
|
||
- **Basic Constraints**：是否 CA 证书
|
||
- **Key Usage**：证书用途（服务器认证、代码签名等）
|
||
|
||
### 3.2 证书信任链
|
||
|
||
操作系统和浏览器预置了约 100+ 个**根 CA 证书**（如 DigiCert、Let's Encrypt、GlobalSign 等）。
|
||
|
||
一条典型的信任链：
|
||
|
||
```
|
||
根 CA 证书 (Root CA)
|
||
└── 由根 CA 签名
|
||
中间 CA 证书 (Intermediate CA 1)
|
||
└── 由中间 CA 签名
|
||
中间 CA 证书 (Intermediate CA 2)
|
||
└── 由中间 CA 2 签名
|
||
网站证书 (End-entity / Leaf Certificate)
|
||
└── 你的域名（如 vpn.example.com）
|
||
```
|
||
|
||
验证过程（链式验证）：
|
||
```
|
||
浏览器持有根 CA 公钥
|
||
用根 CA 公钥验证 "根 → 中间 CA 1" 的签名 → 得到中间 CA 1 公钥
|
||
用中间 CA 1 公钥验证 "中间 CA 1 → 中间 CA 2" 的签名 → 得到中间 CA 2 公钥
|
||
用中间 CA 2 公钥验证 "中间 CA 2 → 网站证书" 的签名 → 得到网站公钥
|
||
验证网站证书的域名与访问域名是否一致
|
||
验证证书是否在有效期内、是否被吊销
|
||
```
|
||
|
||
### 3.3 证书类型
|
||
|
||
| 类型 | 验证级别 | 浏览器地址栏 |
|
||
|------|---------|------------|
|
||
| DV（Domain Validation）| 仅验证域名控制权 | 锁 + 安全 |
|
||
| OV（Organization Validation）| 验证域名 + 企业身份 | 锁 + 企业名 |
|
||
| EV（Extended Validation）| 严格企业审核（已逐步淘汰）| 绿条（Safari 已移除） |
|
||
|
||
Let's Encrypt 是免费 DV 证书的代表，三个月有效期，自动化续期。
|
||
|
||
### 3.4 证书吊销与 OCSP
|
||
|
||
证书泄露或私钥丢失时，需要吊销。
|
||
|
||
**CRL（Certificate Revocation List）**：CA 维护被吊销证书的序列号列表。缺点：列表可能很大，浏览器每次都要下载。
|
||
|
||
**OCSP（Online Certificate Status Protocol）**：浏览器直接查询 CA 的 OCSP 服务器验证证书状态。缺点：隐私泄露（CA 知道你访问了哪个网站），CA 不在线则验签失败。
|
||
|
||
**OCSP Stapling**：服务端主动向 CA 查询自己证书的状态，将 OCSP 响应附在 TLS 握手时一起发给浏览器，浏览器无需额外请求。
|
||
|
||
**CRLSette 和 OCSP Must-Staple**：现代浏览器综合使用多种策略判断证书是否可信。
|
||
|
||
---
|
||
|
||
## 四、机场老板和 GFW 到底能看到什么？
|
||
|
||
### 4.1 网络分层与可见信息
|
||
|
||
| 协议层 | 可见信息 | 加密情况 |
|
||
|--------|---------|---------|
|
||
| HTTP 应用层 | 请求路径、Headers、Body | 端到端加密 |
|
||
| TLS 加密层 | 加密的内容、加密的域名（SNI 部分情况） | 端到端加密 |
|
||
| TCP 层 | 端口号、序列号、连接状态 | 部分可见 |
|
||
| IP 层 | 源/目的 IP 地址 | 明文 |
|
||
| 数据链路层 | MAC 地址、局域网拓扑 | 明文 |
|
||
|
||
### 4.2 TLS 握手中的明文部分（重要！）
|
||
|
||
**SNI（Server Name Indication）**：
|
||
|
||
TLS 1.2 及之前的握手，ClientHello 中有一个字段叫 SNI，写明要访问的域名：
|
||
|
||
```
|
||
SNI: vpn.example.com ← 明文，不加密
|
||
```
|
||
|
||
这是因为 TLS 在 TCP 握手**之后**才建立，而服务端可能同一 IP 托管多个域名，需要靠 SNI 决定返回哪个证书。所以**在 TLS 握手阶段，服务商/ISP/GFW 就能看到你要访问的域名**。
|
||
|
||
**ESNI（Encrypted SNI）** 是针对此问题的解决方案，已演变为 **ECH（Encrypted Client Hello）**，将 SNI 加密。但目前普及率很低。
|
||
|
||
**DNS 查询**：
|
||
|
||
如果你用的 DNS 服务器在境内（如 114.114.114.114 或 223.6.6.6），GFW 能在 DNS 层面知道你查询了哪些域名。
|
||
|
||
解决方法：
|
||
- DoH（DNS over HTTPS）：DNS 查询通过 HTTPS 加密传输，ISP 看不到具体查询内容
|
||
- DoT（DNS over TLS）：DNS 查询通过 TLS 加密传输
|
||
- 直接使用境外 DNS（如 8.8.8.8）配合代理
|
||
|
||
但 DoH/DoT 本身也有 SNI 问题——你要访问哪个 DoH 服务商（如 `dns.google`）在 TLS 握手中依然是明文。
|
||
|
||
### 4.3 机场老板能看到的
|
||
|
||
| 信息 | 能否看到 | 原因 |
|
||
|------|---------|------|
|
||
| 访问的域名（SNI） | ✅ 能看到 | TLS ClientHello 明文 |
|
||
| 具体 URL 路径 | ❌ 看不到 | HTTPS 加密 |
|
||
| 账号、密码 | ❌ 看不到 | HTTPS 加密 |
|
||
| 访问的内容 | ❌ 看不到 | HTTPS 加密 |
|
||
| 流量大小 | ✅ 能看到 | 加密了内容，但流量字节数裸奔 |
|
||
| 连接时长 | ✅ 能看到 | 流量元数据 |
|
||
| 访问时间 | ✅ 能看到 | 日志记录 |
|
||
|
||
**结论**：机场老板知道你在用他的线路访问 `*.google.com`，但不知道你在 Google 上搜了什么、登录了什么账号。
|
||
|
||
### 4.4 GFW 能看到的
|
||
|
||
GFW 是部署在骨干网入口/出口的流量审查设备，能力比普通 ISP 更强：
|
||
|
||
| 信息 | 能否看到 |
|
||
|------|---------|
|
||
| 你的公网 IP | ✅ 明文 |
|
||
| 目的地 IP | ✅ 明文 |
|
||
| SNI 域名 | ✅ 明文（TLS 握手） |
|
||
| DNS 查询记录（若用境内 DNS） | ✅ 明文 |
|
||
| HTTPS 加密内容 | ❌ 看不到 |
|
||
| HTTP/2 或 HTTP/3 的头部 | ✅ 部分明文（HPACK 压缩可部分隐藏） |
|
||
|
||
GFW 的主要手段：
|
||
- **DNS 污染**：对特定域名返回虚假 IP（配合 DNS 缓存投毒）
|
||
- **SNI 阻断**：检测 ClientHello 中的特定域名，直接 TCP RST 或丢包
|
||
- **关键词过滤**：对 HTTP 明文流量（未加密的 HTTP 1.1）做 DPI 内容匹配
|
||
- **流量指纹**：识别特定协议的流量特征（如 WireGuard、Trojan 的独特握手模式）
|
||
- **机器学习**：识别代理流量的统计特征
|
||
|
||
**GFW 不能直接破解 HTTPS 内容**，但可以通过 SNI 和域名黑名单做主动探测，或通过 DNS 污染让用户连到伪基站。
|
||
|
||
---
|
||
|
||
## 五、安全误区详解
|
||
|
||
### 误区 1：装了抓包工具的根证书后，所有 HTTPS 都安全了
|
||
|
||
实际上：
|
||
|
||
```
|
||
你装了小证书的根证书 → 抓包工具拦截了 TLS 握手
|
||
→ 抓包工具用自己的证书伪装成目标服务器
|
||
→ 你和抓包工具之间用合法（小证书的）证书加密
|
||
→ 抓包工具和真实服务器之间用真实证书加密
|
||
→ 抓包工具完整解密了你的流量
|
||
```
|
||
|
||
这就是**中间人攻击（MITM）**。在企业网络安全审计场景下是合法行为，但被恶意利用时，你的所有 HTTPS 流量都会被第三方解密。
|
||
|
||
### 误区 2：HTTPS 加密了就是绝对安全
|
||
|
||
HTTPS 只保护**传输层安全**，不保护：
|
||
- **服务端被入侵**：攻击者拿到服务器私钥后可解密历史会话（除非有前向保密）
|
||
- **客户端被入侵**：键盘记录器、恶意浏览器插件可以截取解密后的内容
|
||
- **社会工程学**：钓鱼网站本身也可能有 HTTPS（DV 证书只需验证域名）
|
||
|
||
### 误区 3：VPN 能完全隐藏我的流量
|
||
|
||
VPN 隐藏了你到 VPN 服务商之间的流量：
|
||
- ISP 只能看到你连到了 VPN 服务器的 IP，看不到具体访问内容
|
||
- 但 VPN 服务商能看到你的 SNI、流量大小和访问时间
|
||
- 如果 VPN 服务器日志保存完整，配合 IP 地址分配记录可追溯用户
|
||
|
||
这就是"机场老板能看到 SNI 但看不到内容"的实际含义。
|
||
|
||
### 误区 4：加密强度越高越好
|
||
|
||
AES-256 在目前和未来几十年内都是安全的（量子计算除外）。过度使用 AES-512 等超长密钥反而增加 CPU 开销而无实际安全收益。关键是**正确配置和前向保密**，而不是盲目追求密钥长度。
|
||
|
||
---
|
||
|
||
## 六、为什么钱还是丢了？
|
||
|
||
视频提出的核心问题：技术无懈可击，但钱仍然被盗。
|
||
|
||
**根本原因不是加密被破解，而是身份验证链被人绕过：**
|
||
|
||
1. **钓鱼网站**：你以为自己访问的是 `bank.com`，但域名是 `bark.com`（视觉混淆：`l` vs `1`），TLS 证书是 `bark.com` 的合法 DV 证书，浏览器完全信任。攻击者在完全合法的 HTTPS 通道中完成钓鱼。
|
||
|
||
2. **社工欺骗**：攻击者获取了你足够多的个人信息（通过数据泄露库）后，直接在正规网站上以你的身份操作，HTTPS 毫无作用。
|
||
|
||
3. **SIM 卡克隆/呼叫转移**：攻击者通过运营商内部关系补办你的 SIM 卡，接收银行短信验证码。
|
||
|
||
4. **恶意 App**：你在手机上安装了来路不明的应用，申请了辅助功能权限，直接读取屏幕内容和键盘输入，绕过所有加密。
|
||
|
||
5. **网络层劫持**：路由器被恶意固件感染，或处于中间人网络环境中，配合根证书安装（或其他手段），直接截取明文。
|
||
|
||
**总结**：HTTPS 是安全架构中极其重要的一环，但它只解决传输通道的机密性和完整性问题。安全木桶的短板永远是人在最薄弱的地方——保持警惕、使用官方渠道、安装可信证书，才是真正的防线。
|
||
|
||
---
|
||
|
||
## 附录：常用工具与检测方法
|
||
|
||
```bash
|
||
# 查看网站证书链
|
||
openssl s_client -connect google.com:443 -showcerts </dev/null
|
||
|
||
# 查看证书详细信息
|
||
openssl x509 -in cert.pem -text -noout
|
||
|
||
# 检查 TLS 版本和密码套件
|
||
curl -v https://example.com
|
||
|
||
# 检查域名证书是否有效
|
||
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509
|
||
|
||
# 检测 SNI（抓包可见性）
|
||
# Wireshark 过滤: tls.handshake.extensions_server_name
|
||
```
|