SSLStrip攻击
HTTP或者HTTPS？¶
当用户在浏览器中输入一个域名时，使用 HTTP 还是 HTTPS 协议访问是由多种因素决定的。浏览器会根据用户输入的内容、网站的配置以及浏览器自身的安全策略来决定使用哪种协议。以下是详细解释：
决定使用 HTTP 还是 HTTPS 的因素¶
用户输入的内容¶
- 完整 URL：如果用户输入了完整的 URL（如
https://example.com），浏览器会直接使用用户指定的协议（HTTP 或 HTTPS）。 - 仅输入域名：如果用户仅输入域名（如
example.com），浏览器会根据以下规则决定使用哪种协议： - 默认协议：大多数现代浏览器的默认行为是尝试使用 HTTPS 协议访问网站。
- HSTS（HTTP Strict Transport Security）：如果浏览器之前访问过该网站，并且该网站启用了 HSTS，浏览器会强制使用 HTTPS 协议。
- 无 HSTS：如果浏览器之前未访问过该网站，或者该网站未启用 HSTS，浏览器可能会尝试使用 HTTP 协议访问，但会根据其他因素（如浏览器的安全策略）决定是否升级到 HTTPS。
网站的配置¶
-
HSTS（HTTP Strict Transport Security）：如果网站启用了 HSTS，浏览器会强制使用 HTTPS 协议。HSTS 是一种安全策略，通过在 HTTP 响应头中设置
Strict-Transport-Security指令，告诉浏览器在后续访问中始终使用 HTTPS。 -
示例：
max-age：指定 HSTS 策略的有效期（单位为秒）。includeSubDomains：强制所有子域名也使用 HTTPS。
-
HSTS Preloading：一些网站会将自己添加到浏览器的 HSTS Preload 列表中。浏览器在首次访问这些网站时，会直接使用 HTTPS 协议，即使用户输入的是 HTTP 地址。
-
示例：Google 的 HSTS Preload 列表是一个广泛使用的列表，许多浏览器会内置该列表。
-
301 永久重定向：如果网站配置了从 HTTP 到 HTTPS 的 301 永久重定向，浏览器在访问 HTTP 地址时会被自动重定向到 HTTPS 地址。
-
示例：
浏览器的安全策略¶
- 默认行为：现代浏览器（如 Chrome、Firefox、Safari）的默认行为是优先尝试 HTTPS 协议。如果 HTTPS 请求失败（如证书错误、连接超时），浏览器可能会回退到 HTTP。
- 安全警告：如果 HTTPS 连接的证书无效（如证书过期、证书颁发机构不可信），浏览器会显示安全警告，阻止用户继续访问。用户可以选择忽略警告，但这是不推荐的。
浏览器如何实现 HTTP 到 HTTPS 的升级¶
默认尝试 HTTPS¶
- 现代浏览器：当用户仅输入域名时，浏览器会默认尝试使用 HTTPS 协议访问网站。
- 示例：用户输入
example.com，浏览器会尝试访问https://example.com。
HSTS 和 HSTS Preloading¶
- HSTS：如果浏览器之前访问过该网站，并且该网站启用了 HSTS，浏览器会强制使用 HTTPS 协议。
- 示例：用户输入
http://example.com，浏览器会直接将其重定向为https://example.com。 - HSTS Preloading：如果网站在浏览器的 HSTS Preload 列表中，浏览器在首次访问时也会直接使用 HTTPS 协议。
- 示例：用户输入
http://example.com，浏览器会直接访问https://example.com。
301 永久重定向¶
-
服务器配置：如果网站配置了从 HTTP 到 HTTPS 的 301 永久重定向，浏览器在访问 HTTP 地址时会被自动重定向到 HTTPS 地址。
-
示例：
-
浏览器收到 301 响应后，会自动跳转到 HTTPS 地址。
浏览器回退机制¶
- HTTPS 请求失败：如果 HTTPS 请求失败（如证书错误、连接超时），浏览器可能会回退到 HTTP 协议。
- 示例：用户输入
https://example.com，但服务器的 SSL 证书无效，浏览器会显示安全警告。用户可以选择忽略警告并继续访问，或者回退到 HTTP 协议。
总结¶
当用户在浏览器中输入域名时，使用 HTTP 还是 HTTPS 协议的决定因素包括：
- 用户输入的内容（是否包含协议）。
- 网站的配置（如 HSTS、301 重定向）。
- 浏览器的安全策略（如默认行为、HSTS Preloading）。
浏览器通常会优先尝试 HTTPS 协议，以确保用户的安全。如果 HTTPS 请求失败，浏览器可能会回退到 HTTP 协议，但会根据网站的配置和浏览器的安全策略决定是否允许回退。
SSLStrip攻击¶
攻击原理¶
SSLStrip 是一种中间人攻击工具，由 Moxie Marlinspike 在 2009 年提出，用于将 HTTPS 连接降级为 HTTP，从而窃取用户敏感信息。其工作原理如下：
- 中间人攻击：攻击者通过 ARP 欺骗等手段，将自己置于用户和目标服务器之间，拦截所有经过的 HTTP 流量。
- 重定向 HTTPS 到 HTTP：攻击者将用户浏览器中的 HTTPS 请求替换为 HTTP 请求，同时记录下所有被修改的链接。
- 代理转发：攻击者与目标服务器保持正常的 HTTPS 连接，而与用户之间则通过 HTTP 连接进行通信。用户提交的敏感信息（如用户名、密码）将以明文形式传输给攻击者。
- 伪装安全连接：攻击者可能会将浏览器中的安全图标（如“小黄锁”）替换为用户熟悉的图标，以欺骗用户。
SSLStrip攻击需要配合ARP欺骗、DNS欺骗等使用
- 开启流量转发
- ARP欺骗
- 端口流量转发
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 1000
# 将80端口流量转发到1000(sslstrip监听的默认端口)
- SSLStrip攻击
配置端口转发（IP Forwarding & iptables 重定向）的意义¶
在中间人攻击中，这一步分为两个关键动作，缺一不可：
- 开启内核 IP 转发 (
sysctl net.ipv4.ip_forward=1) - 意义：让攻击者的机器具备“路由器”的功能。当攻击者通过 ARP 欺骗截获了受害者的数据包后，如果不开启 IP 转发，Linux 内核会发现这些数据包的目的 IP 不是本机，从而直接**丢弃**它们。这会导致受害者立刻断网，攻击行为瞬间暴露。开启转发后，攻击者机器会将数据包继续发送给真实网关，保持受害者网络的“正常”连通性，实现隐蔽监听。
- 配置
iptables端口重定向 (NAT PREROUTING) - 意义：仅仅转发是不够的，因为受害者发起的是发往目标服务器 80 端口的流量。我们需要在流量刚进入攻击者机器网卡时（
PREROUTING链），强行修改其目标端口，将其“引流”到sslstrip工具正在监听的本地端口。 - 典型命令：
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080 - 底层逻辑：这利用了 Netfilter 框架，在数据包进入路由决策之前，修改了 TCP 头部的目的端口字段，并相应地调整了校验和（Checksum）。
为什么要监听 80 或 8080 端口？¶
这与 HTTP 协议的默认行为和系统资源分配有关：
1. 协议默认行为：当用户在浏览器中输入 http://example.com，或者点击网页中一个没有明确指定协议的相对链接（如 <a href="/login">）时，浏览器默认会向目标服务器的 80 端口 发起 TCP 连接。攻击者必须拦截这个默认端口的流量，才能捕获未加密的初始请求。
2. 避免端口冲突：攻击者的机器（如 Kali Linux）可能自身已经运行了 Apache 或 Nginx 等 Web 服务，占用了 80 端口。因此，sslstrip 通常被配置为监听 8080 或其他高位端口。通过上述的 iptables 规则，外部看起来流量依然发往 80 端口，但在内部已被无缝重定向到 8080 端口交由 sslstrip 处理。
sslstrip 工具在该过程中的核心作用¶
sslstrip 本质上是一个**恶意的 HTTP/HTTPS 降级代理服务器**（基于 Python 的 Twisted 异步网络框架编写）。它**不破解任何密码学算法**，而是利用了协议设计的缝隙。其工作流程如下：
- 接收明文请求：从受害者（经
iptables重定向）接收原本发往 80 端口的 HTTP 请求。 - 发起加密请求：
sslstrip作为客户端，使用底层的加密库（如 OpenSSL）与真实的目标服务器建立 HTTPS 连接，并将受害者的请求转发过去。此时，服务器认为是一个正常的加密客户端在访问。 - 拦截并篡改响应（核心动作）：当服务器返回 HTTPS 响应时，
sslstrip会在内存中解析该 HTTP 报文，并执行以下关键篡改： - 链接替换：使用正则表达式将 HTML 内容中的所有
https://替换为http://。 - 剥离安全头：移除或修改
Strict-Transport-Security(HSTS) 响应头，防止浏览器记住该站点需要 HTTPS。 - 降级 Cookie：移除
Set-Cookie头中的Secure标志，诱骗浏览器在后续的 HTTP 请求中明文发送 Session Cookie。 - 篡改重定向：将服务器返回的 301/302 重定向的
Location头从 HTTPS 改为 HTTP。 - 返回明文响应：将篡改后的 HTTP 响应发送给受害者。受害者浏览器成功渲染页面，用户毫无察觉地以明文输入账号密码，这些凭据随后被攻击者通过嗅探工具（如
tcpdump）轻松捕获。
防御手段¶
- 全面启用 HSTS (HTTP Strict Transport Security)
- 原理：服务器在 HTTPS 响应头中加入
Strict-Transport-Security: max-age=31536000; includeSubDomains。浏览器收到后，会在本地缓存该规则。在max-age有效期内，浏览器**在底层网络栈发起请求前**，就会自动将所有对该域名的 HTTP 请求重写为 HTTPS。 - 效果：流量根本不会以明文形式离开客户端，SSLstrip 的
iptables重定向规则捕获不到初始请求。 - 加入 HSTS 预加载列表 (Preload List)
- 原理：HSTS 的首次访问仍可能是 HTTP（存在“首次访问漏洞”）。通过将域名提交至浏览器维护的 HSTS 预加载列表（如 hstspreload.org），主流浏览器会将该域名硬编码在二进制文件中。
- 效果：彻底消除首次访问的降级风险，实现真正的“零明文”。
- 物理/防火墙层面禁用 80 端口
- 原理：如果业务完全不需要 HTTP 服务，直接在云安全组或本地防火墙（如
iptables/ufw）丢弃目标端口为 80 的入站 TCP 流量。 - 效果：攻击者即使拦截了请求，也无法将其转发到服务器的 80 端口，连接会直接超时或重置，从而暴露攻击行为。
SSLStrip+¶
SSLStrip++ (also called SSLstrip+) is implemented in the sslstrip2 tool. It extends the original SSLStrip technique to work against sites that have HSTS configured, by exploiting the first-visit gap in combination with DNS manipulation.
Technique: Instead of simply rewriting https:// to http://, sslstrip2 rewrites links to look-alike domains (e.g., www.bank.com → wwww.bank.com) that do not have HSTS rules. A companion DNS spoofer resolves these look-alike hostnames to the attacker's IP.
Diagram: sslstrip2 vs sslstrip — Technique Comparison
参考：
How to Install SSLStrip2 in Kali Linux
SSLStrip, SSLStrip+, and HSTS | frostbits-security/MITM-cheatsheet | DeepWiki