如果您访问 HTTPS 站点并在没有任何警告的情况下被重定向，那么问题是您的浏览器没有正确验证证书 - 一个好的浏览器会显示警告，因为强制门户的证书不包含您想要以其通用名称访问的域场地。

如果您通过 HTTP 访问该站点，则可能存在漏洞，但有一些解决方案可以缓解这种情况，例如 cookie 上的安全标志，告诉浏览器不要通过 HTTP 发送此 cookie - 和HSTS，它使浏览器自动转换您的 HTTP 请求将站点发送到 HTTPS 请求中，此外还可以防止您在无法建立 HTTPS 连接时绕过证书错误。

该行为取决于浏览器。如果浏览器实际上会将针对 Facebook 的 HTTPS 请求发送到强制门户，那么这显然是一个浏览器漏洞。但是还有其他方法可以处理这种情况。

我最近几次不得不使用带有强制门户的网络。在这些情况下，我启动了 Chromium，它恰好在上一次会话中打开了几个 Facebook 选项卡。

发生的事情是显示了正确的错误消息。但与此同时，Chromium 打开了一个新选项卡，该选项卡访问了特定的 HTTP URL，其实际意图是被强制门户劫持。一旦我通过强制门户，Facebook 选项卡就会自动重新加载，这一次不会出错。

因此，Chromium 似乎检测到了强制门户的存在，安全地打开它，并最终在您经过强制门户时检测到。

类似的强制门户检测存在于 Android 和 iOS 中，尽管它不绑定到浏览器，而是作为与接入点关联的一部分发生。

我看到您对强制门户如何运作的理解存在一些误解。我遇到的强制门户网站肯定以不同的方式工作。

没有对 DNS 流量进行拦截。只要您使用通过 DHCP 提供的 DNS 服务器，您的计算机就可以不受限制地进行 DNS 查找，而无需访问强制门户。

也没有使用 ICMP 技巧。而是在您的计算机和服务器之间的合法路径上的路由器之一将劫持 TCP 连接到端口 80。一旦 TCP 连接被劫持，重定向到强制门户将被发送到浏览器。在正确的实现中，这会重定向到 HTTPS URL，并以某种方式包含有关原始 URL 的信息，以便您稍后可以被发送回那里。与强制门户的整个通信是使用实际属于强制门户的域名的合法证书执行的。

这种方法适用于 HTTP - 但不适用于 HTTPS。执行劫持的路由器将没有您正在访问的站点的有效证书，因此在任何安全浏览器中，如果对 HTTPS 进行了相同的劫持，您都会收到证书警告。

有三种方法可以解决这个不适用于 HTTPS 的问题：

• 依靠用户忽略安全警告并接受他们的私人信息将被截获，即使在提出关于风险的非常详细的警告之后也是如此。
• 依靠用户了解这一切是如何工作的，并自己打开一个 HTTP URL 以便被劫持，然后知道在通过强制门户后转到原始 HTTPS URL。
• 让客户端软件检测强制门户的存在并进行适当处理。这仍然依赖于用户能够发现强制门户是否正在尝试执行网络钓鱼攻击，但至少不会泄漏任何 cookie。