一些强制 Wifi 门户需要能够将用户 301/302 重定向到身份验证/服务条款页面，然后才允许访问互联网。
这与 SSL 相矛盾，因为 SSL 无法被为顾客提供 wifi 服务的典型咖啡店干净利落地拦截。在这种情况下，用户在连接到https://Facebook.com并且证书是私人颁发的。这显然是安全方面的禁忌。
因此，现在使用 Wifi + HTTPS，连接将失败。聪明的用户可以导航到网站的“http://”版本来“触发”重定向，但对于 HSTS 和证书锁定来说，这不再可靠，因为无法发送门户重定向。
随着 HSTS 和固定的日益普及，许多用户“猜测”的网站都会导致浏览器错误，并且不会重定向到本地身份验证点。
问题
- 对此问题的理想缓解措施是什么？有哪些具体的最佳实践？
- 我是否应该考虑在 naked/root 和 www 域上不使用 SSL 来执行重定向？
- 我是否应该为 HSTS 设置一个完全不同的 TLD？
我这样问是为了能够逐案权衡可用性和安全性。
答案1
目前，还没有办法彻底重定向 HTTPS。IETF 已经在研究解决方案，第一个里程碑是2018年8月。
但是 Android 和 iOS 会检测到强制门户并要求用户登录，Windows/MacOS 用户也会收到通知。您可以在身份验证门户周围放置二维码，人们会环顾四周寻求帮助。如今，没有什么可以阻挡青少年和 WIFI……
答案2
我建议不要在服务器端明确处理强制门户问题。移动设备已经包含强制门户检测，铬合金我想我也在 Firefox 中看到过这种情况。这些现有机制将识别强制门户导致的问题，并让用户能够在单独的窗口甚至应用程序内接受必要的条件等。
答案3
这不管用。随着越来越多的网站迁移到 HTTPS 和 HSTS，解决这个问题变得越来越困难。
http://neverssl.com明确设立了一个可以解决这个问题的网站，但这取决于用户是否了解这个网站。
在您的网站上，如果不明确牺牲网站的安全性（例如关闭 HSTS 并希望用户不会将 HTTPS 网站加入书签），您就无法做任何事情。