MITM — 中间人攻击
一句话概括
中间人攻击（Man-in-the-Middle, MITM）是攻击者 secretly 拦截、窃听甚至篡改通信双方之间数据的攻击方式，而通信双方误以为自己在直接对话。
攻击模型
正常通信：
客户端 ──────────────────────→ 服务器
MITM 攻击：
客户端 ──→ 攻击者（拦截） ──→ 服务器
↕ 窃听／篡改
攻击者处于通信路径上，可以：
- 窃听（Eavesdropping） — 读取通信内容
- 篡改（Tampering） — 修改传输中的消息
- 劫持（Hijacking） — 冒充其中一方继续通信
常见 MITM 攻击场景
1. 公共 WiFi 嗅探
攻击者在公共 WiFi 热点上监听所有未加密流量，读取 HTTP 请求中的 Cookie、密码等敏感信息。
2. ARP 欺骗（局域网）
攻击者伪造 ARP 应答，将网关的 MAC 地址指向自己
→ 受害者的所有流量先经过攻击者的机器
3. DNS 欺骗 / DNS 劫持
用户访问 bank.com
DNS 返回攻击者控制的 IP（而非真正银行的 IP）
→ 用户连接到假冒的银行网站
4. 恶意代理 / SSL 剥离
| 类型 | 说明 |
|---|---|
| SSL Stripping | 攻击者将 HTTPS 链接降级为 HTTP，读取明文数据 |
| 恶意代理 | 受害者配置了攻击者的代理服务器，所有流量经过代理 |
5. 伪造证书（当 TLS 验证被跳过时）
客户端（带 --insecure）
│ ← [攻击者证书，非服务器证书]
│ ✓ 跳过验证，接受连接
│
攻击者（代理转发）
│ ← [服务器正常证书]
│
服务器
这就是 --insecure 的核心风险所在。 详见 insecure-到底做了什么？
TLS 如何防御 MITM
TLS 通过 三层防御 阻止 MITM：
| 防御层 | 机制 | 防什么 |
|---|---|---|
| 身份认证 | 数字证书 + CA 信任链验证 | 防止冒充服务器 |
| 加密 | 对称加密（握手时协商密钥） | 防止窃听数据 |
| 完整性 | MAC（消息认证码） | 防止篡改数据 |
关键： 只要 TLS 证书验证未被跳过，MITM 攻击者就无法插入自己，因为：
- 攻击者没有服务器的私钥 → 无法冒充服务器完成 TLS 握手
- 攻击者自己的证书不会被客户端信任 → 客户端拒绝连接
但是： 如果客户端通过 --insecure 跳过了证书验证（如 curl -k、helm login --insecure），上述三层防御全部瓦解 — 攻击者只需提供任意自签名证书即可成功冒充。
真实案例
案例 1：私有仓库自签名证书 + --insecure
开发者在 CI/CD 中配置：
helm registry login myharbor.com --insecure
helm push mychart.tgz oci://myharbor.com/project
如果网络路径被劫持：
攻击者插入自己的证书 → 客户端不验证 → 成功冒充 myharbor.com
→ 攻击者获取推送的 Chart → 注入恶意代码 → 转发到真正仓库
案例 2：公共 WiFi + HTTP 登录页
用户在咖啡馆连接 WiFi，访问 HTTP 页面 → 攻击者直接读取所有明文数据（密码、Token、Cookie）。
案例 3：恶意软件安装伪造根证书
恶意软件将自签名根证书安装到系统信任库 → 对该 CA 签发的所有域名发起 MITM 攻击 → 浏览器不再显示告警。
防御最佳实践
| 措施 | 说明 |
|---|---|
| 始终验证证书 | 永远不要在生产环境使用 --insecure |
| 证书固定（Certificate Pinning） | 客户端硬编码预期的证书或公钥 |
| HSTS（HTTP Strict Transport Security） | 强制浏览器始终使用 HTTPS |
| 公钥基础设施（PKI） | 使用正规 CA 签发的证书 |
| 证书透明度（Certificate Transparency） | 监控是否有证书被误签发 |
| 自签名证书的正确方式 | 将 CA 证书添加到系统信任库，而非跳过验证 |
关联笔记
- TLS-传输层安全协议 — TLS 是防御 MITM 的核心技术
- 数据加密-AES-GCM — TLS 使用的加密算法
- curl-命令详解 — curl 的
-k选项与 TLS 调试 - SSH-sshd_config认证安全配置 — SSH 防 MITM 的安全配置