14 KiB
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 同时使用两种加密：
- 用非对称加密安全交换一个临时会话密钥
- 用对称加密（会话密钥）高效传输实际数据
这是 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 开销而无实际安全收益。关键是正确配置和前向保密，而不是盲目追求密钥长度。
六、为什么钱还是丢了？
视频提出的核心问题：技术无懈可击，但钱仍然被盗。
根本原因不是加密被破解，而是身份验证链被人绕过：
-
钓鱼网站：你以为自己访问的是
bank.com，但域名是bark.com（视觉混淆：lvs1），TLS 证书是bark.com的合法 DV 证书，浏览器完全信任。攻击者在完全合法的 HTTPS 通道中完成钓鱼。 -
社工欺骗：攻击者获取了你足够多的个人信息（通过数据泄露库）后，直接在正规网站上以你的身份操作，HTTPS 毫无作用。
-
SIM 卡克隆/呼叫转移：攻击者通过运营商内部关系补办你的 SIM 卡，接收银行短信验证码。
-
恶意 App：你在手机上安装了来路不明的应用，申请了辅助功能权限，直接读取屏幕内容和键盘输入，绕过所有加密。
-
网络层劫持：路由器被恶意固件感染，或处于中间人网络环境中，配合根证书安装（或其他手段），直接截取明文。
总结：HTTPS 是安全架构中极其重要的一环，但它只解决传输通道的机密性和完整性问题。安全木桶的短板永远是人在最薄弱的地方——保持警惕、使用官方渠道、安装可信证书，才是真正的防线。
附录：常用工具与检测方法
# 查看网站证书链
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