キャプティブポータルでのSSL証明書エラー

状況：キャプティブポータルを介してインターネットにアクセスしようとしているホテルのゲスト。問題：すべてのホームページをHTTPSにリダイレクトするサイトがGoogle、Yahoo、そしてますます増えているため、ログオンページにリダイレクトするとゲストに証明書エラーが発生します。SSLの正しい目的はこれを正確に行うことですが、ファイアウォール経由のアクセスを有効にする前に、ゲストのログオン確認プロセスを管理してIDを確認する別の方法があるかどうか疑問に思います。理解できないゲストをおびえさせます。基本的に、キャプティブポータル/認証プロセスには別のアーキテクチャが必要であり、誰がどんな考えを持っているのか疑問に思います。ありがとう。

「キャプティブポータル」の定義全体は、「ユーザーの知らないうちにユーザーをリダイレクトする」ことを中心に展開しています。これは、SSLが回避するために作成したものの1つです。

ブラウザが開こうとする最初のURLがHTTPSである場合、証明書エラーを作成せずにトラフィックをリダイレクトする方法はありません。

Chromiumプロジェクトには、キャプティブポータルを検出するためのロジックの動作を説明する優れたページがあります。

1. よく知られているホスト+ URIに（プレーンHTTP）を接続しようとします
2. 期待する HTTP 204 No Content
3. 別の応答が受信された場合は、それがキャプティブポータルであると想定します。

よく知られているホストなどを解決しようとしたときにDNS障害を処理する方法については、提供されたリンクに他の詳細があります。これはほんの一例ですが、（私の個人的な経験では）最新のOS設計はこれと同様のプロセスを使用して検出しますユーザーがブラウザを開く前に、場合によってはユーザーにプロンプ​​トを表示します。（検討：IMAPクライアントまたはその他の非HTTPサービスのみを使用したい人。）その場合、検出はSSL / TLS ではなく発生するため、懸念は回避されます。

RFC 6585セクション6は、511 Network Authentication RequiredSSL / TLSのケースには役立たない新しいHTTPステータスコードを提案していますが、これをまだ使用していない場合に検討すべきもう1つの標準です。

いずれの場合でも、ユーザーが証明書エラーを受け取ったのは、証明書がサイトのホスト名と一致しないためです。

この場合、これは、URLを変更せずにユーザーをポータルにリダイレクトすることを意味します。ユーザーのアドレスバーには「http://www.google.com」が表示されますが、画面にはポータルが表示されます。これらは明らかに一致しませんし、証明書も一致しません。

それらをHTTPで（HTTPSジャンプの前に）ポータルアドレス（またはサーバー名）にリダイレクトし、そこにログインしてから、正しく一致する目的の宛先に再度リダイレクトする必要があります。

HTTP 3xxコード、特に303で実行する方法については、https：//en.wikipedia.org/wiki/URL_redirection#HTTP_status_codes_3xxを参照してください。

一時的な解決策は、接続されたwifi信号の後でのみ「http」で始まるURLをユーザーに案内することです。

しかし、残念ながら、ユーザーはそれを好まない。「いかに複雑なwifiサービスがありましたか」