キャプティブポータルはどのようにリダイレクトする必要がありますか？
私は最近読んだ この質問 で、フォローアップの質問が不思議に思われます：このキャプティブポータルはどのようにユーザーをリダイレクトしようとしているのでしょうか？投票数の多いコメントは、結局それが間違っていると言っています。
それで、正当で意図的なキャプティブポータルがある場合、ユーザーのセキュリティと利便性を考慮しながら、ユーザーをポータルにリダイレクトするにはどうすればよいでしょうか。リンクされた質問のようにユーザーが証明書の不一致を取得している場合、セキュリティと利便性の両方に明らかに悪いです。
技術的には、キャプティブポータルは常に中間者攻撃です。したがって、MitMに対するすべての手法はそれらについて警告し、ユーザーに信頼するかどうかを決定する権限を与えます。一部のブラウザには キャプティブポータルの検出 があり、一般に一時的に元のドメインのページを表示せずにリダイレクトを許可します。
現在のセキュリティニーズにより、キャプティブポータルの透過的な実装は困難になっています。ありがたいことに、WebブラウザーとOSの開発者は、インターネットに接続しているかどうかの中間ステータスの存在を報告することの重要性を認識しており、これにより障害のケースを最小限に抑えることができます。
この観点から、適切に署名され、一致する証明書を使用して別のキャプティブポータルログインページにリダイレクトすることは、ログインページをドメインで直接表示するよりも危険が少ないでしょう。
他のオプションはありますか？
証明書の不一致エラーを回避するために、プレーンHTTPでのみリダイレクトを実行できました。それはMitMのままですが、それを検出するように設計されていないプロトコル上にあります。これはHTTP Strict Transport Security（HSTS）以前は完全に問題なく機能し、プロトコルダウングレード攻撃、この種類のキャプティブポータルになります。
リダイレクトはまったくありません。ユーザーがログインページのURLを手動で開いてログインする前に、すべてのトラフィックをブロックするだけです。利便性を犠牲にして、セキュリティを最大化します。ここで、この配置についてユーザーに通知する必要があります。これは通常、追加のサポートが必要であることを意味します。 アドレスバーにこのアドレスを入力する必要があることを画像でユーザーに伝えても、一部のユーザーはGoogleからアドレスを検索しようとします。
開いているWiFiを破棄し、別の認証方法を使用します。キャプティブポータルやログインページは必要ありません。サポートの深刻な必要性。 WPA2エンタープライズは、単一の事前共有キーを必要としないため、技術的に理想的ですが、ターゲットグループ（オープンアクセスWiFiを使用する人々）にはあまり知られていません。
同時に、これらはキャプティブポータルがまだ存在するまさにその理由です。キャプティブポータルの適切な代替案についての私の考えは、接続をブロックしているものが検出されたときにブラウザーがアクセスしようとする、標準化されたプレーンHTTP URLです。次に、そのページはHTTPSと適切な証明書を使用してログインページへのリダイレクトを実行し、ブラウザはその他のものを攻撃として検出します。しかし、これは私の夢であり、現実とはかけ離れています。キャプティブポータルは、実際に機能している限り存在します。
残念ながら、TLSの本来の目的はこの種の攻撃から保護することであるという事実を踏まえると、完璧な解決策はありません。しかし、私が行く最善の方法はこれだと思います：
- HTTPS接続の場合は、それらをブロックするだけです。リダイレクトしようとしないでください。これにより、セキュリティ警告ではなく、インターネットアクセスがないことを示すエラーメッセージがユーザーに表示されます。それのほうがいい。
HTTP接続の場合、 511ネットワーク認証が必要 で応答する必要があります。
511ステータスコードは、クライアントがネットワークアクセスを得るために認証する必要があることを示します。
[...]
511ステータスは、Originサーバーによって生成されるべきではありません（SHOULD NOT）。これは、ネットワークへのアクセスを制御する手段として挿入されるプロキシを代行受信することによる使用を目的としています。