キャプティブポータル(Captive Portal)という名前を聞いたことはありますか?
フリーWi-Fiに接続する時、ユーザー登録や利用規約を確認する画面が出てきますよね。例えばこんな感じです。
このような特定の画面を参照させ「ユーザーが認証を完了するまで外部との通信を制限する仕組み」をキャプティブポータルと呼びます。この画面のことをキャプティブポータルと呼んでいるケースもあるようです。
Wi-Fiにつながった時、例えばAndroidの場合「ログインが必要」と表示され、押すと簡易ブラウザが開きますね。iOSの場合は設定画面上で自動的に簡易ブラウザが起動します。
見たことはあっても、よくは分からない、という方が多いのではないでしょうか?
そこで今回は、この謎多き「キャプティブポータル」について、ネットワークの知識がなくてもイメージできるよう、なるべくわかりやすく紹介していきたいと思います。
- 利用条件の提示や認証に便利な「キャプティブポータル」
- キャプティブポータルのおおまかな仕組みと進化
- キャプティブポータルで開く簡易ブラウザは通常のブラウザとは別物
- キャプティブポータルは一長一短の便利機能
利用条件の提示や認証に便利な「キャプティブポータル」
フリーWi-Fiにキャプティブポータルが必要なのはなぜでしょうか。「邪魔だなぁ」と思うことはあっても、なぜ要るかを考える機会はあまりなかったと思います。
例えば、外出先で誰が設置したかもわからないWi-Fiで、いつのまにかインターネットにつながっていたとしたらどうでしょうか? たとえ悪意のない善良なWi-Fiだったとしても確かめる方法もなく、不安が募りますよね。
フリーWi-Fiを提供する事業者の立場でも考えてみましょう。フリーWi-Fiを利用してもらう際に「無条件で何をしてもOK」というわけにはいきませんよね。知らない間につながっていたら、お客さまに「このお店はWi-Fiを設置してくれてうれしいな」と思ってもらうタイミングもありません。
キャプティブポータルによる認証のステップを踏めば、双方にとって大きなメリットがあると言えます。
- 利用者が、利用条件や提供者の情報をしっかり知ることができる。
- 利用者に、利用条件や提供者の情報をしっかり伝えることができる。
- 合意のもと利用することができる。
これらの利用条件はサービスを便利に使い続けるために必要なものです。面倒と思わずぜひ目を通しておきましょう。
キャプティブポータルのおおまかな仕組みと進化
初期のキャプティブポータル
仕組みを理解しやすくするために、まずは初期のキャプティブポータルがどのような仕組みだったかをご紹介しますね。おおまかに図解したものがこちらです。
左下がスマホ、左上がアクセスポイントです。
「キャプティブポータル」は認証などの条件を達成するまで、インターネット接続を制限する仕組みです。右側は「インターネット接続後の世界」ですが、ただWi-Fiに接続しただけではこちらにはまだ行けません。
まずはスマホが「このネットワークでインターネット接続したい!」とリクエストを出します(HTTPリクエスト)。
キャプティブポータルを設定していない、家庭のWi-Fiなどでは、下図のようにアクセスポイントは「わかった~」と言って「インターネットの世界」に繋げてくれます。
ところが、「キャプティブポータル」があるとどうなるでしょう。
「まあ待って、先にこれを見てくれ」
なんとアクセスポイントは、「インターネットの世界」のページとは関係ない、自分が持っているページを見せてきました。スマホのリクエストを上書きする形ですり替えてしまったのです。スマホはまだ外の世界と通信していませんが、アクセスポイントが割り込んで受け渡したこのページは見ることができます。
このすり替えられたページこそが普段よくみる「利用規約」や「ログイン」のページですね。ここで必要情報を入力したり、規約に同意することで初めて「インターネットに接続」できるようになります。
これが初期のキャプティブポータルです。
「いやいや、勝手に画面が開かれるなんて、セキュリティ大丈夫なの?」
そう思われる方もいますよね。実際、上記のような初期のキャプティブポータルの仕組みはルータ側が強制的に宛先を書き換えており、今で言えば「中間者攻撃」と呼ばれるものにも似ています。
この方法は「https」の普及とともに、古い方法になってしまいました。「https」のような保護されたページの通信の場合、リクエストを強制的に書き換えようとするならば、ブラウザによってはそもそも受け付けなかったり、表示前に証明書の警告を出したりしてしまいます。
そこでキャプティブポータルは「勝手に画面が開かれる」仕様はそのままに、安全性を確保すべく進化していきます。
現在よく採用されているキャプティブポータルの仕組み
次に、現在、多くのフリーWi-Fiスポットで採用されている方式をご紹介します。
実は、OS側が歩み寄るように、それぞれ次のような機能を実装しています。
これは近年もっとも一般的なキャプティブポータルの動作です。
スマホが「このネットワークでインターネット接続したい!」というリクエストを出す際に「じゃあその前に一端ここアクセスしてみよう」と全く別のページにアクセスをします。
例えばAndroidなら
http://connectivitycheck.gstatic.com/generate_204
例えばiOSなら
http://captive.apple.com
こんな空っぽのページのURLが、当初のリクエストとは別に、OS内部から呼び出されます。
このページはhttpで始まっていますが、cookieのないリクエストを簡易的に受けるだけの、各OSが定めて使っている特別なページなので、リスクは少ないと考えて良いでしょう。ここでは仮に「テストページ」と呼んでみましょう。
このページにアクセスしてみると何がわかるのでしょうか。
テストページが普通に表示できた(レスポンスが返って来た)ぞ!
→ページを閉じて接続を継続します。
キャプティブポータルがあれば制限や割り込みが検知され、レスポンスが通常と異なるはずですね。それが無いということは、キャプティブポータルではない無線LAN接続が開始したのだと判断したのです。
OS側がキャプティブポータルという仕組みがあることを認知した上で、その有無を確認する動作を能動的に行っていることがわかります。
なんらかの「リダイレクト」をしようとする反応を検知したぞ!
→キャプティブポータルのログインページを、臨時の簡易ブラウザで開きます。
「テストページ」を表示しようとしたのに「リダイレクト」を検知した場合、各OSなどが「これはきっとキャプティブポータルだろう」「リダイレクト先がきっとログインページだろう」と判断します。
そして最低限の機能を有した簡易ブラウザで、リダイレクト先のページを開くのです。この状態をキャプティブステートと呼びます。
OSはこの「テストページ」に設定された回数と間隔でアクセスをリトライします。そして正常なレスポンスが返って来たことを契機に「キャプティブポータルの認証がおわった」と判断します。
割り込みを行う性質上、従来の方法では「ユーザーが最初にhttpsのページを見ていた場合、阻害される」「証明書の警告がでる」などの問題点がありました。
この新しい方法では、OS側がそれぞれ個別に「http」の接続テスト用ページのようなものを自発的に開くことで、この問題を回避しようとしています。
キャプティブポータルが開かない理由
「フリーWi-Fiのログイン画面が開かない」というのは、よくあるお悩みの一つです。
このように仕組みを見ていくとその要因が見えてきます。例えば、こんなことが考えられるでしょう。
- アクセスポイントが遠すぎたり、電波状況がわるく、キャプティブポータルの動作まで辿り着いていない
- 既に手元のブラウザでhttpsのページを開いていたせいで、アクセスポイントがログインページを新たに割り込ませることができない
- 利用者が多く、アクセスポイントが受けられるリクエスト数を超えている
- ネットワークのどこか(OSによるテストページへの問い合わせやログイン画面のあるクラウドサーバなど)にトラブルが起こっている
以前、別の記事で利用規約画面がでないときの対策として、「http」のウェブサイトを開いてみる、という対策をお伝えしました。これは「https」のウェブサイトを開いたことで発生してしまう「割り込みの阻害」を回避するためだったんですね。
対応方法については以下の記事で詳しくご紹介していますので、ぜひ参考にしてくださいね。
関連リンク:フリーWi-Fiのログイン画面が出てこない!? 繋がらない時に試して欲しい5つのこと
https://www.ntt-bp.net/column/blog/2022/07/post-90.html
「キャプティブポータル」は仕組みがまだ一本化されていない
ここまでご紹介してきましたが、現状、その名前が示す「ただひとつの絶対的な仕組み」や「統一された規格」があるわけではありません。OSのバージョンや端末によって動作に違いもあり、それも理解を阻んでいる一因でもあります。
インターネット技術の標準化や運用に関する情報共有のための「RFC」という文書シリーズがありますが、キャプティブポータルの共通化が試みられた「Captive Portal API」が文書に登場したのは「RFC 8908」、まだ2020年9月のことです。この動きに即したOSへの実装度合いで言えば、標準化は「まだまだ途中」と言えます。
キャプティブポータルは便利な仕組みで、必要なものとされていながら、通信への「割り込み」を行うなど一定のセキュリティを求める通信規格のあり方に反する性質も持っています。それゆえに、安全と利便性の両立を求め、独特な実装がされてきました。
現在では、主要OSが(似てはいるものの)異なる方法でキャプティブポータルを受け入れています。
さらに、RDC8952 Captive Portal Architectureでは、現状よく使われているタイプより、より安全性の高い方法でキャプティポータルを実装できる方法が示されました。キャプティブポータルは今も進化の途中なのです。
この新しい規格は対応するOSやデバイスに限りがあるため、誰にでも使えるよう設計されたフリーWi-Fiではまだ採用されていないところが多いのですが、今後主流になるかもしれません。
RFC 8952 Captive Portal Architecture
https://www.rfc-editor.org/rfc/rfc8952.html
キャプティブポータルで開く簡易ブラウザは通常のブラウザとは別物
ところで、「Wi-Fi接続時に開くログイン画面だと、メールアドレスやパスワードが記憶されてなくて不思議!」と思ったことはありませんか?
それもそのはず、キャプティブポータルで開かれる簡易ブラウザは、通常使っているブラウザとcookieなどの情報を共有していないのです。少し不便を感じるかもしれませんが、余分な情報を共有しないことで、よりセキュリティを強化しているんですね。
他にも、この簡易ブラウザには通常と異なる点がいくつかあります。
ブックマークができない
キャプティブブラウザで開いたページはブックマークをして後から同じページを開くことはできません。
インターネットに接続できたら自動的に閉じる(Androidの一部端末)
Android版の一部端末では、認証が終わってインターネットに接続したら自動的に閉じるものが多いです。
iOS版の場合はインターネットに接続した後も、自身で閉じなければブラウザ自体は起動しています。認証完了後は提供者事業者のサイトなどに遷移するものが一般的です。
画面を閉じるとWi-Fiが切断される
Androidの一部端末では、簡易ブラウザを閉じると利用の意思がないとみなされるのか、Wi-Fi自体を切断します。Androidの場合は、開く際も簡易ブラウザは「勝手に開く」というよりは通知や接続画面に表示される「ログインする」というアクションで開きますので、閉じたからには使わないよね? ということなのでしょう。
OSによって異なりますが、Androidであれば閉域網からインターネットにつながるとブラウザが自動で閉じる端末もあります。
また、iOSは簡易ブラウザの閉じ方によっては、その後のWi-Fi接続設定が変わってしまうケースもあるので注意が必要です。
アプリなど簡易ブラウザ以外で認証してインターネットに接続する場合は「インターネットに接続せずに使用」を選択します。この方法で画面を閉じると、次回からそのWi-Fiの「自動ログイン」がオフになり、簡易ブラウザが起動しない場合があります。
そのWi-Fiを使うつもりがない場合や、単に画面を閉じたい場合は「ほかのネットワークを使用」を選択しましょう。
キャプティブポータルは一長一短の便利機能
私たちが普段フリーWi-Fi接続の前に見ているあの画面は、キャプティブポータルの仕組みがあってこそだとわかりました。それはとても便利な機能ですが、インターセプト(通信の割り込み)といった、取り扱いに注意の必要な技術で成り立っている一面があるのも事実です。
その便利さを保持したままキャプティブポータルを活かすため「テストページ」による確認のような動作を行っていますが、私たちの目からは理解しにくく、ややこしいままです。
お伝えした通り、近年ではキャプティブポータルの共通化が試みられた文書も登場し、その不自由で独特な実装を改善しようとする動きは見られます。今後は「https」アクセスで安全にログインページを通知できる方法が、主流になっていくかもしれません。
また、近年ではOpenRoamingのような、ログイン画面を表示することなく各地のWi-Fiスポットに安全に、横断的に接続できる仕組みも注目を集めています。一方、利用前に認証や条件の確認を行うことはフリーWi-Fi利用者、提供者の双方にとって重要なステップであり、キャプティブポータルの必要性は失われないだろうという見方もあります。
これからキャプティブポータルがどのような進化を遂げるかはわかりませんが、たくさんの人々の知恵の上に、今日も安全に使えるフリーWi-Fiが成り立っています。
その仕組みを少しでも知り、伝えることが、その恩恵を絶やさず、発展させていくことの一助となるはずです。
参考にさせていただいたページ
Android Developers
hhttps://developer.android.com/reference/android/net/CaptivePortal
Captive portal - Wikipedia
https://en.wikipedia.org/wiki/Captive_portal
IETF Datatracker RFC8910
https://datatracker.ietf.org/doc/html/rfc8910
IETF Datatracker RFC7710
https://datatracker.ietf.org/doc/html/rfc7710
Captive WiFi: Guest WiFi Data Capture & Customer Feedback for Hospitality
https://www.captivewifi.io/
captive.apple.comって何やねん?
https://hikaku-server.net/smartphone/entry669.html
Captive Portal機能
https://www.rtpro.yamaha.co.jp/AP/docs/wlx322/captive_portal.html
Captive Portal Detectionについて - にたまご。
https://ao780.hateblo.jp/entry/2017/02/21/112233
キャプティブポータルの仕組みと変遷 - hgot07 Hotspot Blog
https://
https://hgot07.hatenablog.com/entry/2023/11/26/082509