# 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 # 检测 SNI（抓包可见性） # Wireshark 过滤: tls.handshake.extensions_server_name ```