キャプティブポータルとは

キャプティブポータル

サイゼとかのフリーWiFiに繋ぐと出てくるあの認証画面およびそれらの実装の仕組みのこと。
OSによって出し方は違うが、基本的には勝手にブラウザが立ち上がってきてログイン画面を出してくるようになってる。
代表的な例では、FREESPOTとか。技術基盤として使われやすいのは 教育機関向けのeduroam、一般市民向けのcityroam、OpenRoaming あたりかな？

こういう感じの奴。OS側が親切に教えてくれている例

これは何？

元々事業者 (カフェとか) が利用者に向けてインターネットサービスを提供する際、ちょいちょいパスワード未設定の暗号化なしWiFiをそのまま飛ばしていることがあった。
DSとかが主流だった年代だと割とありえた光景のように思う (記憶あやしいかも…)

ただ、それでは事業者・利用者ともにセキュリティがないも同然であり、悪意ある攻撃者からの攻撃にあまりにも脆弱すぎた。
利用者からすれば「なんか勝手に繋げられるけどこれは正しいものなのか分からない」し、「接続内容が盗まれてしまうかもしれない」といったリスクもある。
事業者にも「本当に利用者にのみ使われているのか分からない」という不安もある。

そこでキャプティブポータル、ならびにFREESPOT等フリーWiFiを提供するサービスを使用することで、端末のアクセスコントロールや利用規約の周知、データ収集などを行うことができるようになる。
特に「データ収集」と「利用規約などの周知」の力が強く、前者は事業者にとってかなり貴重なデータであるため、入手手段として有用である。

このように、過去セキュリティも何もなかった状態を一気に改善し、誰でも安心してフリーWiFiを利用できるようになる技術が「キャプティブポータル」である。

どういう感じに使われていたのか

上述したとおり、主に接続端末の認証を行い、アクセスコントロールやデータ収集のために使われがち。
飲食店であれば、利用規約の提示と共に現在使っている座席や人数を収集するなど、貴重なデータ収集に使える。
会社などのオフィスであれば、従業員の端末など認証済み端末はそのまま通し、ゲスト端末など非認証端末はキャプティブポータルを通すことによってアクセスコントロールができる。

また、暗号化なしのWiFiを使用して犯罪行為を行う悪い人を防ぐこともできる。
APや使用するサービスにもよるが、基本的にログを残す機能がついているため、いつ誰がどのデバイスを用いてAPに接続し、ある程度の利用ログを残すことも可能。
利用者が犯罪行為などわるいことを行った場合でもログを確認することで該当者の特定が可能となる。

大まかな仕組み

端末 (A) がアクセスポイント (AP) に接続したとき、APの先にあるルーター (RT) はAが認証済み端末であるかどうかのチェックを行う (行わないこともある) 。
RTがAを認証済み端末ではないと認識した場合、ほとんどのインターネット通信を妨害し、RTもしくは契約しているキャプティブポータル (CP) サービスの認証ページにリダイレクトする。
1. このとき、DHCP (IPアドレスを取得する奴) とかDNS (ドメイン←→IPの名前解決する奴) 通信は妨害しない。
  これらも妨害してしまうと端末の認識やCP認証ページへのリダイレクトに支障が出てしまう可能性がある。
2. ほとんどのサービスは外部CPサービスの認証ページに飛ばすが、YAMAHAなどのいいとこのルーターは内部に持っていることもある ^[1] 。
認証ページで認証を行ったら通信の妨害をやめ、通常通りインターネットを利用できるようにする。
認証のタイムアウト時間が経過したり、接続が切れたなどで再接続された場合は必要に応じて再度 1 から手順をやり直す。

図にするとこんな感じ。

わかりやすさ重視で正確さには欠ける

歴史

目立って出始めたのは2010年とかぐらいだったような気がする？
どこでもインターネット接続ができる携帯型ゲーム機^[2]が主流になってきたぐらいに使用するところが増えたような。

初期の実装

このとき、アクセスポイントの暗号化は設定されていないか、されていても非常に弱い設定であることが多い。

まだHTTP通信 (80, 8080番) でのブラウジングが主流だった時代では (単純に?) HTTP通信を乗っ取ってHTTP 302で強制的に認証ページにリダイレクトさせる方法が主流だった。
また、当時はOS側でいい感じにページを出してくれるとかもなく、適当なページを開いたら認証ページが飛ぶ、みたいな感じで認証をする (させられる) 事が多かった。

やっていることは端的にはTCP/80, 8080の通信をジャックして認証ページにねじまげたあと、認証が完了したらファイアウォールのルールを変えたりして外につなげられるようにしているだけ。これは現代でもあまりかわらんかも
接続のパクり方など、やっていることは中間者攻撃などとあまり変わらず、つまりセキュリティ的にはよろしくない。

その他、HTTP通信のリダイレクトによる誘導以外にも、ICMPリダイレクトを使用したり、DNSサーバーの応答結果を変更したりして誘導することもある。

なお、このHTTP通信のリダイレクトによる方法は現代でもある程度残っている。
結局やっていることは「HTTP通信の向き先をねじまげて認証ページに持っていく」ことにさほど変わりはないため、適当な http:// のサイトにアクセスするだけでも認証ページに飛ぶことができる。
何らかの原因で認証ページにアクセスできなかったとしても、適当なサイトを見ることで認証ページに飛べるため、最終手段として覚えておくと便利。
また、サービスによっては認証ページに誘導するためにhttpサイトのURLを案内することもある (FREESPOTとかまさにそう) 。

一部、ゲーム機であれば認証不要のフリーWiFiサービスもある。

中期～現在の実装

時代は進み、誰もHTTP通信でネットを見なくなった頃になると当然先述の方法は機能しなくなる。
仕組み上HTTP通信をジャックして認証ページに飛ばすものであるため、HTTPS通信ではこのジャックが不可能となり、根本的に認証ができなくなる。

それではキャプティブWiFiの意味が薄れてしまうため、各OS側が歩み寄る形で実装が進んだ。
具体的には、 Captive Portal Detection (CPD) という方法でキャプティブポータルの存在を検出し、存在する場合は認証ページに誘導するという形で実装がされている。

具体的には・・・

各OSはネットワーク接続時、以下のURLにアクセスし、所定のリクエストが返ってくるか検証する。
返ってきたリクエストが正しいものであればキャプティブポータル等が存在せずそのまま外と接続ができ、逆に違うものが返ってきた場合 (HTTP 302とか) 、キャプティブポータルが存在すると判断して専用ブラウザを開き、ユーザーに認証させる。

プラットフォーム	接続先	正しいリクエスト
Apple系 (iOS/iPadOS/macOS)	`http://captive.apple.com/hotspot-detect.html`	HTTP 304 (Not Modified), `<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>`
Android系 (Android Based OS, ChromeOS)	`http://connectivitycheck.gstatic.com/generate_204` `http://clients3.google.com/generate_204` `http://google.com/gen_204`	HTTP 204 (No Content)
Windows	Win10 1607以降: `http://www.msftconnecttest.com/connecttest.txt` Win10 1607以前: `http://www.msftncsi.com/ncsi.txt`	DNS Lookup結果が `131.107.255.255` かつ HTTP 200 (Success), `Microsoft Connect Test` または `Microsoft NCSI` と書かれたRaw テキスト

Windows こばなし

Windows NCSI (Network Connectivity Status Indicator) には過去「DNSプローブ」とよばれる「特定のDNSサーバーに対してIPアドレスの名前解決をすることでインターネットアクセスを確認する」機能があったが、現在のWindows 11では廃止されているらしい。
現在名前解決に使うDNSサーバーはWindowsに設定されているDNSサーバーを使うようになっており、結果テキストデータを正しく受け取れていればDNSには問題がないこととなる。
そのため現在はDNSプローブは行われず、HTTPプローブとよばれるテキストデータの受信処理だけ行うようになっている。
正しくテキストデータを受け取ることができればステータスは「Internet」となり、通常通りインターネット通信が可能となる。

その他、NCSIにはLAN内でのみ通信可能であることを通知する「LocalNetwork」や完全にインターネットアクセスがない「NoTraffic」のステータスもある。

OSによって細かな違いはあれど、基本的には「ネットワーク接続時 (および一定時間おき?) に特定URLにリクエストを送り、レスポンスによって疎通確認を行う」、「レスポンスが正しければ通常通りインターネット接続可能、正しくなければキャプティブポータルがあると判断する」の2点は変わらない。

現代では基本的にこの方法でフリーWiFi (や認証が必要なネットワーク) に接続している。
ただしこれらの方法ではまだいくつか問題点があり、また今後普及していく (している?) 技術と一部相性が悪いこともある。

そもそもの問題点は「ソフトウェアベンダー各社で実装が違う」ことなどが挙げられる。上のレスポンス一覧を見ればいかに統一されていないかがわかる
これらの問題を解消するため、RFC (Request for Comments) に共通化されたキャプティブポータルの仕組みである「Captive Portal API」が策定された。

使われて欲しいイイ実装

(もしかしたらもう使われてるかも? OSによって対応状況が違う…)

安全で、イイ感じの実装を実現するため、2020年9月頃からRFCにキャプティブポータルAPIが策定。

RFC 8908 Captive Portal API (日本語訳)
- キャプティブポータルAPIに関する文書。デバイスがキャプティブポータルの存在を検知し、認証や規約に同意するなどのアクションに対するインターフェースを提供。
  - 関連にRFC 7710が存在するが、現在廃止。修正版は以下のRFC 8910。
    書いてあることも同じだったような。
RFC 8910 Captive-Portal Identification in DHCP and Router Advertisements (RAs) (日本語訳)
- DHCPとルーター広告によるキャプティブポータルの識別方法に関する文書。デバイスがインターネットアクセスを得る前に認証等が必要な場合に自動的にキャプティブポータルの存在を検知し、ユーザーに知らせるために使用。
RFC 8952 Captive Portal Architecture (日本語訳)
- インターネットアクセスを得る前の認証や情報提供を行うシステムの標準化に関する文書。

この方式の場合、APIサーバーはデバイスに対してDHCP Option 114やルーター広告などを用いてJSON形式でAPIへのURLを送信する。
この時送られるJSONは以下の形式。

{
  "captive": true, // 認証が必要な状態かどうか trueなので認証が必要
  "user-portal-url": "https://example.org/portal.html", // 認証用URL
}
// RFC 8910より引用

captive は認証が必要な状態かどうかによって変わる。認証が必要な状態であればtrue
user-portal-url は実際に認証に使うページ。 captive が true の場合に接続。
この時使用するURLは全てHTTPS。当然APIとの通信もHTTPS通信を使用する ^[4] 。

認証が完了したら、クライアントはサーバーに再度リクエストを送り、サーバーはデバイスに対して以下のJSONを返し、認証状態を抜ける。

{
   "captive": false, // 認証が必要な状態かどうか falseなので認証は不要
   "user-portal-url": "https://example.org/portal.html", // 認証用URL
   "venue-info-url": "https://flight.example.com/entertainment", // 認証完了後に見せたいページのURL
   "seconds-remaining": 326, // 再度認証が必要になるまでの時間 (秒)
   "can-extend-session": true // 延長可能か
}
// RFC 8910より引用

captive, user-portal-url は同じ。
venue-info-url は情報を提供したい際に使うページ。サービスエリアとか飛行機のポータルサイトとか・・・
seconds-remaining は認証が切れるまでの秒数。これを過ぎると再度認証が必要になる。
can-extend-session は再度延長できるかどうか。true ならば認証が切れたあと user-portal-url に再度誘導する。

ここにはないが bytes-remaining というオプションもある。
これは seconds-remaining と近い。こちらは認証が必要な状態になるまでのトラフィックのバイト数を示す。
あまり使われることはないかも…

これらの実装は安全で、便利で、共通化されているためOS依存の処理がないなどいい事ずくめだが、悲しいことに対応したOSが少ない。

実用的なのはAndroid^[5]で、次点でiOS / macOS^[6]。Windowsは対応すらしていない。
このため、スマホは楽に繋げられるのにWindowsではなかなか繋げられないといったことがよく起きる。^[7]

以上がキャプティブポータル、並びに関連RFCのおおまかな歴史と概要。
現代でHTTP通信をひったくる方法を使っていることはあまりない (CDPやらRFC 8908あたりがえらい) が、結局HTTP通信をもぎとる仕組みはあまり変わっていないので、どうしても繋がらない時に適当な http 通信のサイトを見る方法はしばらくは変わらないだろうか。

現在ではeduroamやcityroam, OpenRoamingを使用したサービスが普及しているっぽい。
これらのサービスも良いところだけではなくしんどいところも多くあるよう ^[8] で、今後の更新に期待するしかないのかなあと。

普段何気なく使うフリーWiFiの裏でどのような技術が使われていて何が起こっているのか、調べてみると結構面白かった。
もっといろんな技術のうらっかわを調べてみたいと思うとともに、しらべもの活動を布教していきたい。。。！

参考文献

この記事を書くにあたって参考にさせていただいた記事など。

https://network.yamaha.com/setting/wireless_lan/airlink/captive_portal ↩
ニンテンドーDSとか・・・ ↩
Apple公式のドキュメントが存在せず、詳細は未知。 ↩
APIサーバーエンドポイントは、HTTPS URI [RFC2818]を使用してHTTPを介してアクセスする必要があり、デフォルトのHTTPSポートを使用する必要があります。 - RFC8908日本語訳より。 ↩
Android 11以降。 ↩
iOS/iPadOS 15以降、macOS Ventura以降。 ↩
よく起きた。うぜえ ↩
OS側でCaptive Portal APIに対応していなかったりなど。 ↩

雑記

#ネットワーク

キャプティブポータルとは

https://assault1892.github.io/what-is-captive-portal/

著者

Assault1892

作成日

2025年4月9日

著作権

Vagrant おぼえがき次の記事