使用 sslstrip+ 和 dns2proxy 绕过 HSTS
HSTS bypass with sslstrip+ & dns2proxy
我正在尝试了解如何绕过 HSTS 保护。我读过 LeonardoNve ( https://github.com/LeonardoNve/sslstrip2 and https://github.com/LeonardoNve/dns2proxy ) 的工具。但是我不太明白。
如果客户端是第一次请求服务器，它会随时工作，因为 sslstrip 将简单地剥离 Strict-Transport-Security: 头字段。所以我们回到原来的 sslstrip 的旧情况。
如果不是...？发生什么了 ？客户端知道它应该只使用 HTTPS 与服务器交互，所以它会自动尝试使用 HTTPS 连接到服务器，不是吗？那样的话，MitM 就没用了……><
查看代码，我有点明白 sslstrip2 会更改客户端所需资源的域名，因此客户端不必使用 HSTS，因为这些资源不在同一域中（是吗？ ？）。客户端将发送一个 DNS 请求，dns2proxy 工具将拦截并发回真实域的 IP 地址 name.At 最后，客户端将以 HTTPS 方式对它应该完成的资源进行 HTTP。
示例：根据服务器响应，客户端必须下载 mail.google.com。攻击者将其更改为 gmail.google.com，因此它不是同一个（子）域。然后客户端将DNS 请求这个域，dns2proxy 将回答mail.google.com 的真实IP。然后，客户端将简单地通过 HTTP 请求此资源。
在那之前我没有得到的是...攻击者如何 html-strip 而从客户端到服务器的连接应该是 HTTPS ...？
少了一块...:s
谢谢
好的，看完视频后，我对 dns2proxy 工具可能的操作范围有了更好的了解。
据我了解：
- 大多数用户将通过单击 link 或重定向进入 HTTPS 页面。如果用户直接获取 HTTPS 版本，则攻击失败，因为没有服务器证书我们无法解密流量。
- 在重定向或 link 启用 sslstrip+ + dns2proxy 的情况下，我们处于连接中间 .. mitm！ ==>
- 用户继续google.com
- 攻击者拦截从服务器到客户端的流量，并将link更改为从“https://account.google.com" to "http://compte.google.com”登录。
- 用户浏览器将向 "compte.google.com" 发出 DNS 请求。
- 攻击者拦截请求，向真实姓名"account.google.com"发出真实DNS请求，并将响应"fake domain name + real IP"发回给用户。
- 当浏览器收到 DNS 应答时，它会搜索该域是否应该通过 HTTPS 访问。通过检查预加载的 HSTS 域列表，或者通过查看缓存中或会话中已访问的域，不知道。由于域不是真实的，浏览器将简单地建立一个 HTTP 连接到真实地址 ip。
==> 末尾的 HTTP 流量 ;)
所以真正的限制仍然是需要间接 HTTPS links 才能工作。有时候浏览器直接"re-type"url进入一个HTTPSlink.
干杯！
我正在尝试了解如何绕过 HSTS 保护。我读过 LeonardoNve ( https://github.com/LeonardoNve/sslstrip2 and https://github.com/LeonardoNve/dns2proxy ) 的工具。但是我不太明白。
如果客户端是第一次请求服务器，它会随时工作，因为 sslstrip 将简单地剥离 Strict-Transport-Security: 头字段。所以我们回到原来的 sslstrip 的旧情况。
如果不是...？发生什么了 ？客户端知道它应该只使用 HTTPS 与服务器交互，所以它会自动尝试使用 HTTPS 连接到服务器，不是吗？那样的话，MitM 就没用了……><
查看代码，我有点明白 sslstrip2 会更改客户端所需资源的域名，因此客户端不必使用 HSTS，因为这些资源不在同一域中（是吗？ ？）。客户端将发送一个 DNS 请求，dns2proxy 工具将拦截并发回真实域的 IP 地址 name.At 最后，客户端将以 HTTPS 方式对它应该完成的资源进行 HTTP。
示例：根据服务器响应，客户端必须下载 mail.google.com。攻击者将其更改为 gmail.google.com，因此它不是同一个（子）域。然后客户端将DNS 请求这个域，dns2proxy 将回答mail.google.com 的真实IP。然后，客户端将简单地通过 HTTP 请求此资源。
在那之前我没有得到的是...攻击者如何 html-strip 而从客户端到服务器的连接应该是 HTTPS ...？
少了一块...:s
谢谢
好的，看完视频后，我对 dns2proxy 工具可能的操作范围有了更好的了解。 据我了解：
- 大多数用户将通过单击 link 或重定向进入 HTTPS 页面。如果用户直接获取 HTTPS 版本，则攻击失败，因为没有服务器证书我们无法解密流量。
- 在重定向或 link 启用 sslstrip+ + dns2proxy 的情况下，我们处于连接中间 .. mitm！ ==>
- 用户继续google.com
- 攻击者拦截从服务器到客户端的流量，并将link更改为从“https://account.google.com" to "http://compte.google.com”登录。
- 用户浏览器将向 "compte.google.com" 发出 DNS 请求。
- 攻击者拦截请求，向真实姓名"account.google.com"发出真实DNS请求，并将响应"fake domain name + real IP"发回给用户。
- 当浏览器收到 DNS 应答时，它会搜索该域是否应该通过 HTTPS 访问。通过检查预加载的 HSTS 域列表，或者通过查看缓存中或会话中已访问的域，不知道。由于域不是真实的，浏览器将简单地建立一个 HTTP 连接到真实地址 ip。 ==> 末尾的 HTTP 流量 ;)
所以真正的限制仍然是需要间接 HTTPS links 才能工作。有时候浏览器直接"re-type"url进入一个HTTPSlink.
干杯！