Captive Portal Detectionについて
今回はCaptive Portal Detection(キャプティブポータル検知)についてお話しします。
手っ取り早く言うと、コレ↓ですね。こんな画面見たことあるでしょうか？
公衆無線LANに接続すると、ブラウザが突然開かれるアレです。海外だと、「pop-up window」や「splash window」などと呼ばれています。
Captive Portal Detectionとは
ユーザー保護の目的でOSに実装されている仕組み。通常のブラウザとは別にその場限りのincognito modeなウィンドウで開かれる。incognito modeで開かれることによって、ユーザーが普段使っているブラウザのセッションやクッキーの情報が漏れる心配がない。
各OSのCaptive Portal Detection方法
では、実際にどのようにCaptive Portalを検知するのでしょうか？
基本的には、それぞれのOSには「Well-Known Web Page」と呼ばれる、インターネットアクセスの有無を検証するためのWeb Pageを用意しており、そこへのアクセスがあるかないかでCaptive Portalがあるかどうかを検知します。Captive Portalが検知され、レスポンスとして返ってきた302 redirection urlをfetchし、ユーザーを認証ページに誘導します。
各OSにはCaptive Portal Detection Strategyという検知のための手法があり、以下の表の通りです。
- iOS/macOS : メカニズムは非常に単純。「Success」というレスポンスが返ってくる、captive.apple.comなどのWell-Know Web Pageにアクセスし、「Success」が得られない場合はCaptive Portalと検知している(タイムアウトは除く)。
- Windows : Windowsには2段階の判断ある。まず、dns.msftncsi.comにDNS lookupし、IPアドレスをチェックする。これはCaptive Portalがあるのか、またはそもそもネットワークの接続性の問題のため、インターネットアクセスが得られないのかを判断するためである。そして、http://www.msftncsi.com/ncsi.txtにリクエストを送り、「Microsoft NCSI」というレスポンスが得られなかった場合、Captive Portalと見なされる。
- Android : AndroidはHTTP/HTTPS両方の接続を確かめるページを用意しているが、Captive Portalの特性上HTTPS Probeはほぼ失敗してしまう。HTTP Probeを確認する場合、http://google.com/gen_204にアクセスする。このWebページは、インターネットアクセスがある時に204 & No Contentを返す。Androidは公衆無線LANに接続すると、まずこのページへのアクセスをチェックし、「204 & No Content」以外のレスポンスを得た場合Captive Portalだと認識する。
＊Android7.0からの変更点
上記のAndroidの説明を見て、HTTP/HTTPS両方確認する必要はないと思った方もいると思いますが、Android7.0からは、
- HTTPS probeがSuccessしなかった場合、自動的にそのネットワークに接続しない。
- ユーザーが自分で使うかどうか「Manual」に選択する。
というように変更されたので、一応意味はあるっぽいです。従来はCaptive Portalを検知すると、自動的にincognito windowで開くというメカニズムでしたが。しかし、そもそもユーザーを安全ではないネットワークに自動的に接続させるのはいかがなものか、とGoogleは考え上記のようにポリシーの改定を行ったみたいです。
AndroidのCaptive Portal Detectionは他にもいろいろと細かく設定がされており、複雑ですが、興味のある方はここからソースを読んでみてもおもしろいかもしれません。「204」と「No Content」両方チェックしている理由なんかも記されています。700行目前後から読むのがオススメだとか(by Googler)。
