我正在研究绕过 HSTS。我看了这个就绕过使用SSLSTRIP + HSTS引导，但也有几件事情，我不明白。
首先要做的是在 SSLstrip+ 模式下启动 MITMf，我还将使用经典的 ARP 欺骗来成为中间人：
所以现在当 192.168.10.23 浏览到 www.google.com 时，他将被重定向到 wwww.google.com！
受害者究竟是如何被重定向的。DNS 数据包是否包含某种重定向？还是将用户重定向到 wwww.google.com 的其他东西？
还有一件事。这个数字是否仍然适用于 SSLSTRIP+？
LeonardoNve 的DNS2Proxy工具的文档说明如下：
dns 服务器会自动检测并纠正我的 sslstrip+ 对主机名所做的更改以避免 HSTS，因此会正确响应。
这里究竟要纠正什么？
这是根据您链接到的可用信息来回答的。
受害者究竟是如何被重定向的。DNS 数据包是否包含某种重定向？还是将用户重定向到 wwww.google.com 的其他东西？
当用户导航到 时www.google.com，充当 MITM 的 sslstrip 会将用户重定向到wwww.google.com使用 HTTP。例如，通过LocationHTTP 响应标头：
Location: http://wwww.google.com/
还有一件事。这个图是否仍然适用于 SSLSTRIP+
该图像似乎不适用于 sslstrip 或 SSLstrip +。由于它无法拦截实际的 HTTPS 请求，因此来自客户端的请求不应使用 HTTPS 协议进行请求。它更像
GET http://facebook.com ----> sslstrip ---> https://facebook.com
它最初通过将链接和重定向从 HTTPS 更改为在任何 HTTP 响应中返回的 HTTP 来阻止来自客户端的 HTTPS。
这里究竟要纠正什么？
看来，通过 DNS2Proxy 的配置，您可以设置子域的解析方式。因此，何时www.google.com重定向到wwww.google.com您的*.google.com规则会设置返回的解析 IP 地址。因此，在您的配置中，您*.google.com将www.google.com.
我的结论：它不起作用。
如果浏览器上已经有 HSTS 规则，那么初始请求www.google.com将通过 HTTPS 无论如何这意味着它不能被 sslstrip 拦截。
此外，如果站点在 HSTS 预加载列表中（例如 Google 的域将在 Chrome 中），则需要includeSubdomains指定。因此wwww.google.com也只能通过 HTTPS 获取。