从技术上讲，强制门户始终是中间人攻击。因此，所有针对 MitM 的技术都会并且应该警告它们，让用户有权决定是否信任。一些浏览器确实有强制门户检测，通常暂时允许重定向而不显示任何具有原始域的页面。

现代安全需求使强制门户的透明实施具有挑战性。值得庆幸的是，Web 浏览器和操作系统开发人员意识到报告是否存在连接到 Internet 之间的这种中间状态的重要性，这样可以将故障案例减少到最低限度。

从这个角度来看，使用正确签名和匹配的证书重定向到单独的强制门户登录页面比直接使用任何域显示登录页面要少。

我们还有其他选择吗？

• 我们只能在纯 HTTP 上执行重定向以避免证书不匹配错误。它仍然是一个 MitM，但它的协议不是为了检测它而设计的。在针对我们的协议降级攻击的HTTP 严格传输安全(HSTS) 之前，这本来可以很好地工作，这种强制门户就是这样。

• 根本没有重定向。只需在用户手动打开登录页面 URL 并登录之前阻止所有流量。安全性最大化，但牺牲了便利性。现在，您必须将这种安排告知您的用户，这通常意味着需要额外的支持。即使你用图片告诉你的用户他们需要在地址栏中输入这个地址，他们中的一些人仍然会尝试从谷歌搜索地址。

• 放弃打开的 WiFi 并使用其他身份验证方法。无需强制门户或登录页面。强烈需要支持。WPA2 企业版在技术上是理想的，因为您不需要单个预共享密钥，但目标群体（使用开放访问 WiFi 的人）不太了解它。

同时，这些也是强制门户仍然存在的原因。我对强制门户的合适替代方案的想法是使用标准化的纯 HTTP URL，当检测到阻止连接时，浏览器会尝试访问该 URL。然后该页面将使用 HTTPS 和适当的证书执行重定向到登录页面，并且浏览器应该检测到其他任何攻击。但这只是我的梦想，与现实相去甚远。只要在实践中有效，强制门户就会存在。

不幸的是，这里没有完美的解决方案，因为 TLS 的目的就是防止这种攻击。但我认为最好的方法是：

• 对于 HTTPS 连接，只需阻止它们。不要尝试重定向。这将为用户提供一条错误消息，指示无法访问 Internet，而不是安全警告。那更好。
• 对于 HTTP 连接，您应该使用511 Network Authentication Required响应：

511 状态码表示客户端需要进行身份验证才能获得网络访问权限。

[...]

511 状态不应该由源服务器生成；它旨在通过拦截作为控制网络访问的手段插入的代理来使用。