许多文档似乎表明，它可以将访问的流量简单地用“ http”代替出现的“ https”。因此，通过诸如“ https://twitter.com”之类的URL将作为“ http://twitter.com”传递给受害者。
此时，SSLstrip是否继续代表我们通过HTTPS与Twitter通信？这样的事情：
Victim <== HTTP ==> Attacker <== HTTPS ==> Twitter
还是客户端现在通过HTTP与Twitter通信使我们能够访问流量的事实？ br />
Victim <== HTTP ==> Attacker <== HTTP ==> Twitter
我想这将是攻击者继续通过HTTPS与Twitter通信的第一个选择，因为它由Twitter强制执行，但我想澄清一下，谢谢。 >
#1 楼
您应该观看Moxie Marlinspike的演讲“使用SSLStrip击败SSL”。简而言之，SSLStrip是一种MITM攻击，它迫使受害者的浏览器通过HTTP与纯文本形式的对手进行通信，并且对手代理来自HTTPS服务器的修改后的内容。为此，SSLStrip将“剥离”https:// URL并将其转换为http:// URL。HSTS是针对此问题的建议解决方案。
评论
太棒了，这回答了我的问题。实际上，这是我在Chrome中使用HSTS遇到的问题，它是预先加载的网站列表，让我怀疑它的工作方式。谢谢！
–斯科特·赫尔姆（Scott Helme）
2013年9月7日在22:44
另一个解决方案是HTTPS-Everywhere。
–起搏器
15年3月29日在7:32
HTTPS-Everywhere并不是解决此问题的真正方法。对于定义了明确规则的网站，它可以缓解这种情况，但这并不是真正的可扩展解决方案。
–布兰登围场
16年6月7日在1:59
当提供商仅提供TLS服务时，HTTPS-Everywhere是一种解决方案！这样就无需升级连接，也无需以这种方式降级连接。并且有一些页面证明仅TLS是完全可行的。
–弗洛里安湖
17-2-24在21:04
@FlorianLoch站点是否接受HTTP连接（是否使用HSTS）与此问题无关。仅仅因为您无法使用HTTP连接到站点并不意味着您无法使用HTTP连接到攻击者。
–user253751
17年11月8日在2:29
#2 楼
谈论可能的解决方案：防止/检测SSL剥夺的唯一真正可靠的方法是使用TLS的始终加密的通信和边信道身份验证（基本上使用TLS密钥交换，但是将PKI /基于证书的身份验证替换为基于用户或设备的身份验证）身份验证）。实际上，这意味着在密钥交换之后，服务器和用户最终会获得某些共享的秘密或密钥。然后，客户端和服务器使用离散身份验证通道（例如，使用SSH或其他强非对称身份验证方法），并对它们的身份和TLS密钥进行身份验证。如果密钥相同，则可以确定100％的端到端加密通道。如果有中间人，他可以做2个攻击媒介：
MITM可以终止与服务器的TLS通信并允许用户通过HTTP进行通信。这不会在传统的TLS / HSTS中引起警报。但是，这将通过边信道身份验证发现，因为服务器和客户端具有不同的TLS密钥（密钥1和非密钥）。
MITM可以使用伪造或被盗的证书。这可能会触发警报，也可能不会触发警报，具体取决于所使用的证书（由于“让我们加密”的主动性，它可能会变得越来越容易）。此攻击将再次通过边信道身份验证的TLS发现，因为服务器将具有与客户端不同的密钥（服务器具有key1，MITM具有指向服务器的key1，MITM具有指向客户端的key2，客户端具有key2）。
这会杀死SSL证书作为奖励，它也可以与CDN一起使用。
请注意，此解决方案不能免除后门加密的麻烦。
评论
证书固定不会达到相同的目的吗？ （欢迎来到安全SE！）
–尼尔·史密斯汀（Neil Smithline）
2015年10月9日在2:31
证书固定在可管理性方面是一项很丑陋的工作，但确实确实解决了欺诈性证书的一些问题。但是，如果您在DNS服务器上有一个MITM，他可以很轻松地解决它，而且我不认为证书固定解决了SSL剥离（除非您将其与所有域和子域的HSTS结合使用）。
–伊沃
2015年10月10日在4:08
#3 楼
HSTS是一个简单的“ http标头”，可以被MITM篡改和更改首选HTTPnowhere或HTTPS Everywhere之类的插件，成功率高达90％...另一种插件是https：// addons .mozilla.org / zh-CN / firefox / addon / enable-disable-weak-ssl-cip /在SSL握手协商后对数据进行加密。
作为客户端，您的位置很明显。您与互联网之间的路由器易于控制。因此，请理解客户端资源不足，无法控制流量。为此，最好的解决方案是VPN / Stunnel ..，但永远不知道NSA / ISP的/特权用户是否具有截获和解密该通信的神奇秘密。 br />
评论
我认为您误解了HSTS的工作原理。在常见情况下，是否存在HSTS标头或被篡改都没有关系，因为假设用户至少已连接到真实站点一次（或该站点位于内置的白名单浏览器中）。从那时起，报头不再重要，客户端将拒绝启动非HTTPS连接。
–布兰登围场
16年6月7日在2:02
根据规范，您只能在加密连接上提供HSTS标头。 MITM在这里不适用。
– Nemo
17年2月7日在4:27
@Nemo：更准确地说，符合条件的用户代理（即浏览器）将忽略在不安全的响应中看到的任何Strict-Transport-Security标头。您（或MitM）可以全天提供标头；浏览器会假装它不存在，直到它通过HTTPS连接接收为止。
– CBHacking
18年6月3日在5:52
#4 楼
我认为必须注意，剥离是在客户端到服务器的负载上完成的，并且要求客户端首先请求HTTP内容。使用Twitter示例，客户端首先需要请求http：/ /www.twitter.com-当网站将客户端重定向到HTTPS时，SSL Strip会删除响应中的“ s”，以便客户端将继续请求HTTP内容，而不是HTTPS。
客户端请求https://www.twitter.com（或正在使用HSTS），则需要SSL MiTM攻击来拦截响应，这违背了此攻击的目的。
评论
您的第一个图是正确的。