HTTPS比安全剧院更糟糕

你用我家的WiFi，否则我们正好在咖啡店用同一个WiFi。你没有使用VPN，因为就像汤姆·斯科特告诉你的那样，在我们这个后LetsEncrypt时代，这是不必要的。您决定访问(或您的浏览器代表您进行轮询)符合以下任一条件的任何网站：

主要通过HTTPS提供，但页面中还包括其他活跃的混合内容。

是通过HTTPS提供的，但不使用HTTP严格传输安全“扩展”。

使用HSTS“扩展”，但是自从上次清除浏览器历史记录后，您就再也没有访问过这个特定的域，或者刚刚打开了私人浏览，并且域所有者还没有设置HSTS“预加载”。

在此场景中，我可能可以访问您登录的六个不同帐户，这些帐户与您实际访问的帐户完全无关，甚至有些帐户是为安全关键型应用程序构建的。如果我幸运的话，我可以在您检测到漏洞、注销并更改密码和双因素身份验证之后很长一段时间内继续保持该访问。这不需要您执行任何操作，也不需要输入任何凭据。几乎页面一加载，我就透明地获得这些帐户。

如果你在刚刚泄露了你账户的六个网站中的一个做安全工作，你会觉得这是一个值得赏金的漏洞吗？我希望如此。不幸的是，对于大多数公司的信息披露程序(不管怎么说，那些已经存在的程序)来说，像这样的漏洞要么模棱两可，要么明显超出了范围，可能是因为网络开发人员倾向于将HTTPS视为一维的东西。对于系统管理员来说，HTTPS只是您已经设置或没有设置的东西，而实际上，HTTPS就像一个食人魔一样，是一个有着深刻内在动机和思想的复杂协议。有好的-HTTPS，有伪HTTPS，有可能-HTTPS，在雨天有HTTPS，在阳光明媚的下午有HTTPS，希望在这篇文章之后，我能让一些读者了解HTTPS有时会对用户造成多大的影响。

现在我已经稍微放弃了这个游戏，让我们回到那个假设的场景。因为要么我控制着你连接的路由器，要么我们都在同一个WiFi上，我会假设我可以控制你的互联网连接，这可能是真的。因为我可以管理您的连接，所以我可以通过端口80拦截您的请求，然后与实际网站协商出站HTTPS。对于我刚才列出的所有场景，除了在搜索栏中温顺地告诉您您连接的站点不是HTTPS之外，浏览器不会抱怨，这在此场景中无关紧要。

现在假设你是一名Synack承包商。Synack是一家很棒的公司，它众包电脑黑客，为他们的客户做自由渗透测试。我爱斯奈克。Synack是由前美国国家安全局特工杰伊·卡普兰和马克·库尔创立的，我相信他们的员工都非常聪明。如果有人知道如何认证他们的用户，你会认为是电脑黑客为其他电脑黑客搭建了他们的平台。不幸的是，Synack‘platform.synack.com’用户域不使用HSTS，更糟糕的是，它们附带的HTTP端口响应的是“临时”重定向，而不是“永久”重定向。他们的身份验证cookie也没有设置‘SECURE’和‘HttpOnly’标志，而且他们的浏览器不会区分http://platform.synack.com和https://platform.synack.com.

你大概可以看到这是怎么回事。因为我已经是MITM了，我把你直接转到http://platform.synack.com.。我在我的主机上拦截该连接，并使用https://platform.synack.com，通过HTTPS继续它，并将Javascript注入到我给您的响应中。我附加到页面的javascript可以访问您的整个Synack帐户、您的在线Synack帐户可以访问的客户VPN等。

我记得有一次读到臭名昭著的“我追捕Sysadmins”文件时，我对NSA似乎如此严重地依赖黑客攻击这个“量子”感到疑惑。让我有点困惑的是，作者似乎更难确定要攻击哪个IP地址，而不是真正拥有大规模的笔记本电脑。即使他们可以通过这个工具修改一些通常超出范围的响应数据，比如连接和HTTP头的建立，在现代Web浏览器上获得远程代码执行真的那么容易吗？从美国国家安全局的角度来看，一个有效的答案很可能是“是的”，但我现在知道了：

大多数情况下，在查看站点或桌面应用程序的漏洞时，他们只会确保HTTPS已启用，而不会进一步考虑。也许他们会要求启用HSTS，如果他们能够经受住他们因为听起来像个自行车司机而翻了几个眼的话。具有讽刺意味的是，我见过的在信息安全领域得到广泛关注的最复杂的中间人攻击是最天真的攻击，在这种攻击中，你切断某人的TLS连接，然后等待他们输入密码。但我们比这更聪明；除了以上这些，你还可以做一些其他的事情：

让用户请求非HSTS网站的IFRAME。请记住，站点正在使用的X-Frame-Options标头并不重要，因为您只需在响应用户时将其删除即可。将您自己的javascript附加到IFRAME响应中。尽管方案不正常，但一些天真的自动键入实现会自动填充用户的凭据，因此您现在拥有了用户的明文密码，而不需要他们进行任何交互。

重定向用户，然后(作为您自己保证的Cache-Control头的作者)在支持HTTP的外国网站上缓存非HSTS JavaScript文件，以便您在离开咖啡馆后在那里保留很长时间的jsshell。每六个月左右重复拥有用户的账户。这么说你改了密码？是否已启用YubiKey 2FA？是否已联系客户支持？不要紧，只要您重新连接，我就马上回来，因为浏览器可能被告知要无限期地缓存这些页面，而且每次您从那个小小的javascript URL重新加载时，您都是在提供一个牛肉有效负载。

假设我已经MITM了实际的页面，但是一个远程来源的javascript文件-例如，Strip的-正被用来“安全地”将付款表单嵌入到我正在查看的HTTP站点中。条带恰好不仅启用了HST，而且还在其根域上预加载了HST。通常情况下，网站所有者会保护条纹支付不被窥探，这样你的信用卡就可以通过IFRAME，只有条纹才会担心如何安全地存储或使用它。这是一个很好的法律漏洞，这样斯利普的客户就不必符合PCI标准。然而，尽管有这些法律的雄心壮志，用户通常不会检查每个JavaScript代码传出请求的根域名。因此，如果我控制iframe的“src”属性(在本例中是这样做的)，我只需将其指向我的EC2实例，然后在记录CVV、到期日期和信用卡号码后将您的信用卡详细信息传递给Strike。

如果你想知道，我一直在说“非HSTS”而不是“非HTTPS”，因为去往常规HTTPS站点的流量，无论端口80上有什么(或没有什么)，几乎总是可以被拦截的。这是因为浏览器总是首先检查http连接，而碰巧的是，“永久的”“HTTPS重定向”是…提供的。通过HTTP。另一方面，HSTS至少在第一次连接之后强制浏览器通过HTTPS连接，直到用户打开私人窗口。

想想看，HSTS是在2012年标准化的，也就是HTTPS发明近20年后。我想Netscape相信终端用户对哪些站点重定向到HTTPS，哪些站点同时在HTTP和HTTPS上提供相同的站点有着清晰的记忆，因为我无法想象一个如此愚蠢的协议会以其他任何方式保持20年来保护银行和医院的安全。

所有这些古怪之处都是RFC级别的设计问题，而不是bug。如果你改变了这些行为中的大部分，你就破坏了现有网站的很大一部分。所以，浏览器正在紧跟着改变它们，而我甚至还没有考虑到边缘情况，比如：

其中根域使用常规HTTP/HTTPS，但“真正的”WWW域使用HSTS，反之亦然。

子域或父域使用HTTP/HTTPS，但“常规”或“登录”域使用HSTS。

任何针对TLS的实际密码攻击，其中创造性的攻击与普遍认为的相反，取得了一定程度的成功。

这就是为什么我说“HTTPS比安全剧场还差”的原因。它应该被授予安全托尼奖。人们知道运输安全管理局并不能阻止恐怖主义。这并不是军方实际首选的防线。然而，大多数安全社区都被蒙蔽了，认为它目前拥有的折中措施是他们互联网心理模型中最难以理解的部分之一。我们开发的应用程序可以转移资金，在这样的平台上，用户每次想使用时都会从服务器下载代码，但是如果没有扩展和设置，95%的Web开发人员都不知道，我们不知道用户得到的应用程序代码是否是我们发回的代码。

我认为部分原因是老实说，在这个领域缺乏来自红色团队的创新工具。有一些半工作的ARP欺骗实用程序和10年前的sslstrain，仅此而已。人们似乎异常地不感兴趣，原因我只能部分理解。因此，在接下来的一周里，我将在“evilginx”之后初步发布一个我称之为“kill ginx”的工具。到目前为止，我将尝试将我提到的所有这些攻击自动化，从ARP欺骗到数据过滤和缓存shell。就目前而言，它实现的是相当聪明的MITM行为。例如：

响应所有HTTP请求(即使它必须通过后端的HTTPS反向代理)，并将这些响应内容中发回的所有HTTPS链接替换为相同域上的HTTP，或者如果站点使用HSTS，则替换为不使用HSTS的www子域或超域。

使用从永久重定向到该域的透明代理替换到启用HSTS的域的永久重定向。

从入站请求中删除所有安全头并添加一些新头(因为为什么不呢？)。

我提到的其他东西很快就会来。但同时，如果您操作一个网站，在通过https://hstspreload.org/，启用预加载的HST(根域中的“include subDomain头”作为响应)，并在所有域的端口80上为无法预加载的客户端或库进行永久HTTPS重定向后，应该会感到有点舒服。

对于用户来说，安装HTTPS Everywhere插件是强制性的第一步。我还建议，一般来说，直接拒绝使用没有VPN的共享WiFi。那些告诉你不是这样的人，说“不要连接到Defcon的WiFi”这句谚语已经走到尽头了，那他们就错了。我们将处于一个不好玩的过渡期，在这个历史时刻，我们真的没有其他方法来保证安全。