我一直在阅读有关 SSLstrip 的信息，但我不能 100% 确定我对它的工作原理的理解。
许多文档似乎表明它只是将其可以访问的流量中出现的“https”替换为“http”。因此，通过诸如“ https://twitter.com ”之类的 URL 将作为“ http://twitter.com ”传递给受害者。
此时 SSLstrip 是否继续代表我们通过 HTTPS 与 Twitter 通信？像这样的东西：
Victim <== HTTP ==> Attacker <== HTTPS ==> Twitter
或者仅仅是客户端现在通过 HTTP 与 Twitter 通信的事实使我们能够访问流量？
Victim <== HTTP ==> Attacker <== HTTP ==> Twitter
我猜这将是攻击者继续通过 HTTPS 与 Twitter 通信的第一个选项，因为它是由 Twitter 强制执行的，但我想澄清一下，谢谢。
您应该观看 Moxie Marlinspike 的演讲Defeating SSL using SSLStrip。简而言之，SSLStrip 是一种 MITM 攻击，它迫使受害者的浏览器通过 HTTP 以纯文本形式与攻击者通信，攻击者代理来自 HTTPS 服务器的修改后的内容。为此，SSLStrip 正在“剥离” https://URL 并将它们转换为http://URL。
HSTS是针对这个问题提出的解决方案。
谈论可能的解决方案：防止/检测 SSL 剥离的唯一真正可靠的方法是使用始终加密的通信和 TLS 的侧通道身份验证（基本上使用 TLS 密钥交换，但将基于 PKI/证书的身份验证替换为基于用户或设备的身份验证）验证）。这意味着在实践中，在密钥交换之后，服务器和用户最终会得到某些共享的秘密或密钥。客户端和服务器然后使用离散的身份验证通道（例如，使用 SSH 或其他强非对称身份验证方法）并验证他们的身份和 TLS 密钥。如果密钥相同，则可以确定 100% 的端到端加密通道。
如果有中间人，他可以做 2 个攻击向量：
MITM 可以在他的位置终止与服务器的 TLS 通信，并让用户通过 HTTP 进行通信。这会导致传统 TLS/HSTS 中没有警报。但是，这将通过侧通道身份验证发现，因为服务器和客户端具有不同的 TLS 密钥（密钥 1 和无密钥）。
MITM 可以使用伪造或被盗的证书。这可能会触发警报，也可能不会触发警报，具体取决于使用的证书（由于 Let's Encrypt 倡议，这可能会变得越来越容易）。这种攻击将再次被侧通道身份验证的 TLS 发现，因为服务器将具有与客户端不同的密钥（服务器有 key1，MITM 有 key1 到服务器，MITM 有 key2 到客户端，客户端有 key2）。
作为奖励，这会杀死 SSL 证书，并且它也可以与 CDN 一起使用。请注意，此解决方案不能免受加密后门的影响。
HSTS 是一个简单的“http header”，可以被 MITM 篡改和更改
更喜欢 HTTPnowhere 或 HTTPS Everywhere 之类的插件，成功率高达 90%……另一种类型的插件是https://addons.mozilla.org/en-US/firefox/addon/enable-disable-weak-ssl-cip/ SSL 握手协商后加密数据。
很明显，作为客户，您处于劣势地位，您和互联网之间的路由器很容易控制。因此，了解客户端控制流量的资源不足..为此，只有最好的解决方案是 VPN /Stunnel.. 但永远不知道 NSA/ISP 的/有资格的人是否拥有拦截和解密该通信的神奇秘密..
我认为重要的是要注意剥离是在客户端到服务器有效负载上完成的，并且需要客户端首先请求 HTTP 内容。
使用 Twitter 示例，客户端首先需要请求http://www.twitter.com - 当站点将客户端重定向到 HTTPS 时，SSL Strip 将删除响应中的“s”，以便客户端将继续请求 HTTP内容，而不是 HTTPS。
如果客户端请求https://www.twitter.com（或 HSTS 正在使用），则需要 SSL MiTM 攻击来拦截响应，这违背了此攻击的目的。