ハクソク

世界を動かす技術を、日本語で。

ブリティッシュ・エアウェイズの無料WiFiを解放する

213日前原文(saxrag.com)

概要

  • British Airwaysの無料「Messaging」WiFiを利用した体験談
  • SNI（Server Name Indication）による接続制御の仕組みを解析
  • SNIを偽装しプロキシ経由で任意サイト閲覧に成功
  • 技術的検証と実際のフライトでのテスト結果
  • SNIとTLS通信の現実的なセキュリティ課題

British Airwaysの無料「Messaging」WiFiの仕組みと突破法

  • 2025年6月、 HKG-LHR 間のBritish Airways便で 無料「Messaging」WiFi を体験
  • 「The British Airways Club」会員のみ利用可だが、 機内WiFiポータルから即時登録可能
  • Eメール認証不要、 即座に「Messaging」プラン利用開始可能
  • WhatsApp・Signal・Wechatは利用可（ 画像送信不可）、Discordは不可
  • 一般Webサイト（例: example.com）へのアクセスはTCPリセットで遮断
  • TLS通信のSNI（Server Name Indication） を利用し、許可されたドメイン（例: wa.me等）以外は接続遮断
  • SNIはTLSハンドシェイク時にドメイン名を平文で送信 するため、ネットワーク側で判別可能
  • 許可ドメインリスト外は 即座に接続リセット、SNI未設定（IP直指定）も同様に遮断

SNIホワイトリスト突破の技術的検証

  • 自分のVPSのIPに対してSNI未設定でTLS接続 → 即リセット
  • VPSへのTLS接続時にSNIをwa.meに偽装 → 接続成功
  • サーバー側（NGINX）はSNIと証明書不一致でもTLS接続自体は成立
  • SNI偽装によりBA側の「Messaging」通信として認識され、TLSトンネル確立
  • HTTPリクエストをソケット経由で直送信し、 任意Webサイトのデータ取得に成功

HTTPSプロキシを利用したWebアクセス拡張

  • VPS上にtinyproxyでHTTPプロキシ設置、stunnelでTLSラップ
  • stunnelの証明書は自己署名、 CNにwa.meを指定
  • クライアント（curl等）からは SNIをwa.meに設定しつつVPSのIPへ接続
    • hostsファイル編集またはcurlの--resolveオプションでSNI指定
  • TLS証明書エラーは--proxy-insecureで無視
  • curl経由でifconfig.co等の外部サイトアクセス成功

実際のフライトでのテストと結果

  • 帰国便で実験を実施、curlでVPS経由の通信が成功
  • ブラウザでもHTTPSプロキシ設定＋SNI偽装でHacker News等の閲覧に成功
  • 帯域は限定的だが、テキスト主体のサイト閲覧は問題なし
  • Chromiumの証明書警告無効化フラグで自己署名証明書も回避

SNIとTLS通信の現実的なセキュリティ課題

  • TLS通信は暗号化されているが、SNIでドメイン名は平文漏洩
  • ネットワーク管理者やISPはSNIでアクセス先ドメインを判別・制御可能
  • ECH（Encrypted Client Hello）等の新技術でSNI隠蔽が進行中
  • 一般ユーザーのTLS理解度のギャップ（全て暗号化されていると誤解しがち）

まとめ・考察

  • 機内WiFi等の「無料メッセージング」プランはSNIベースで通信制御
  • SNI偽装＋HTTPSプロキシで 任意通信を「メッセージ通信」として突破可能
  • SNIの構造的課題により、現状では 完全な通信秘匿は困難
  • ECH等の普及が進めば、今後この手法も対策される可能性
  • 現場での検証・実践により、ネットワーク制御の現実とTLSの限界を体感

この内容は技術的な検証・知見の共有を目的とし、ネットワークの利用規約や法令に反しない範囲でご活用ください。

Hackerたちの意見

リクエストペイロードを表す任意のサブドメインと、TXTレコード経由でレスポンスを返すカスタムネームサーバーみたいな感じかな。とにかく…。これがiodineだよ。 https://github.com/yarrick/iodine

└

12年くらい前に似たようなことをやったことがあるけど、あれはUDPトンネリングでHTTP(a)だったから、DNS専用じゃなかったんだ。スタンステッド空港で8時間過ごさなきゃいけなかったんだけど、その無料Wi-Fiの時間制限内にトンネルを設定できたんだ（たしか30分だったかな）。いい気分だったよ、ハハ。

どれくらいで削除されるか気になるな。以前のクルーズに関する投稿は法的措置を脅かされたって。

似たようなトンネリングをやってた友達がいるんだけど、クルーズ船でも使えるんだよね。彼は、ある航空会社（アメリカンだったかな？）が、SNIだけじゃなくて、サーバーが提示する証明書のホスト名が正しいか、正規の認証機関から発行されているかもチェックしてる高度なフォーティネットファイアウォールを使ってることを発見したんだ。友達は、その制限を回避するために、トンネルでaa.comのSNIを出して、実際のサーバーからのハローと証明書をaa.comから転送させたんだ（実際、TLS 1.2のハンドシェイク全体をaa.comに転送してると思う）。でも、プロトコルが通常は暗号化されたアプリケーションデータに変わるとき、彼はハンドシェイクで送ったものを無視して、ただ暗号化されたトンネルとして使ってるんだ。（現代の解決策はTLS 1.3を使うことで、サーバー証明書を暗号化してファイアウォールが証明書を検査できないようにするから、問題はSNIの偽装だけに戻るんだよね。）

└

これは基本的にXrayがやってることだよ。[1] 特定のSNIに一致する接続リクエストがあって、秘密鍵を提示しない場合、SSLハンドシェイクとデータをカモフラージュウェブサイトにプロキシするんだ。そうじゃなければ、そのウェブサイトへのSSLトラフィックを装った通常のプロキシとして使える（カモフラージュウェブサイトがSNIホストとして設定されているから、外部の観察者にはそのホストへの正当なトラフィックに見える）。これは中国のグレートファイアウォールを回避するために作られてるから、GFWのアクティブなプローバーを避ける必要があるんだ。でも、友達はプロキシのSNIをGoogle Analyticsに設定すれば、アメリカの機内ファイアウォールでも動作させることができたよ。[1] https://github.com/XTLS/Xray-core

└

友達が少し前に似たようなトンネリングをやってたんだ。それはクルーズ船でも使えるよ。ああ、私も同じこと言おうとしてた！約3週間のクルーズから帰ってきたばかりなんだ。船のインターネットは信じられないくらい高かった（$50/日）。変なのは、Wi-Fiがあって、支払いをしなくてもインターネット経由で動くアプリがあること。Googleマップは普通に使えたし、Appleからの通知も問題なく受け取れた。でもそれだけだった。Wiresharkのトレースをじっと見てた時間もあったよ。TCP接続は通常、いくつかのパケットを送受信することが許可されてるみたい。その後、接続が許可されるべきかブロックされるべきかを判断するためにパケットを詳しく見るんだ。他のプロトコルについては分からないけど、TLSの場合はClientHelloを探してるみたい。もしあれば、ドメインがホワイトリストに載ってるか確認するんだ。ホワイトリストに載ってるものは、たとえインターネットにお金を払ってなくても許可される。ホワイトリストに載ってるドメインには、クルーズ会社のウェブサイトやいくつかの国のビザオフィスが含まれてる。それがアプリの仕組みなんだ。（でも、どうやって私の電話が通知を受け取ってたのかはまだ分からない。）彼らはこの問題を明らかに知ってる。こういうブロックを回避するためのツールもあるけど、そのツールのウェブサイト自体もブロックされてるんだ、たとえインターネットにお金を払ってもね。:) もしこの抜け道を利用する方法が分かったら、あまり乱用したり、対策を宣伝したりしないでね。もし広まったり、悪用されすぎたりしたら、この小さな穴を塞がなきゃいけなくなるから。それは本当に残念なことになるよ。

UDPポート53でVPNサーバーを立てて、バイパスした公共のWi-Fi（機内Wi-Fiも含む）の数は、正直すごいよ。残念ながら、最近はキャプティブポータルが増えて、キャプティブポータルのIP以外は全く出られないところも多いけど、それでも脆弱なところがたくさんあるのはすごいよね。ほとんどの公共ネットワークでトラフィックシェーピング（速度制限）をバイパスできるし、外部アクセスを有効にするために何らかの認証が必要でも、やっぱりすごいよ。SoftEtherを強くおすすめするよ。Azureリレー機能が無料で使えるから、ホワイトリストのみのネットワークでも使えるし、自分のVPSサーバーよりも便利だよ。実際に第三者のDNSリゾルバーを通じて双方向のDNS通信のためにiodineを有効にするところまでは行ってないけど、それももっと多くのケースで機能すると思う、ただし遅くなるだろうけど。

└

最近の航空会社のWi-Fiには「無料メッセージング」っていうのがあって、WhatsAppやFacebook Messengerのトラフィックだけが許可されてるんだよね。もしTCP-over-WhatsAppのVPNが作れたら、最高だよね。

└

うん、ワイヤーガードとOpenVPNをポート53で動かしてるよ（別のVPSで）。もし使えるかもしれないからね。残念ながら、今までの「有料Wi-Fi」の経験では、ポート53が有効なDNSトラフィックとして認識されていて、任意のリゾルバーは許可されないことが多いんだ（例えば、dig example.com @1.1.1.1は通らない）。

参考までに、これは「ドメインフロンティング」って呼ばれてるよ。 https://en.wikipedia.org/wiki/Domain_fronting

飛行中にオフラインにされるのが大好きな私としては、数時間だけでも世界から逃げられるのがいいんだけど、あなたの努力が全員に無料Wi-Fiをもたらすことにならないことを願ってるよ！

└

だから、無料Wi-Fiを手に入れるためにそんなに頑張らないでね、笑

数週間前に国際線に乗ったんだけど、みんなが寝てる間に妻がインスタグラムを開いてフィードをスクロールしてたんだ。他のウェブサイトにはアクセスできなかったけどね。PCは持ってなかったけど、彼らがSNIに基づいてフィルタリングしてるってすぐに気づいたよ。AllotやSandvineみたいな機器は、もう10年以上この市場にいるからね。

日付はどうなってるの？スクリーンショットに表示されてるHNページは2025年5月18日の午後1時GMTのもので、curlコマンドは2025年5月9日の日時を示してる。話の内容は、EDIからLHR経由でHKGへの単一の旅のように聞こえたけど。

└

ちょっと分かりにくかったらごめん；最初の部分はHKG -> LHRのときに気づいた（5月9日）で、その後のHTTPSプロキシテストはLHR -> HKGの帰りのフライト（5月18日）だったんだ。

最近BAで飛んで、VPNを使って無料Wi-Fiの制限を回避できたよ。なんでそれがうまくいったのか分からないけど、Mullvadを使ってるときは空中でHacker Newsを見れた。もっと高度なことは必要なかったよ！

記事を読んで、「SNIはクライアントのプライバシーを侵害するために存在するように思えるな」と思ったんだ。だから、ChatGPTにその理由を聞いてみた。返ってきた答えはこうだったよ。SNI（サーバー名インディケーション）は、サーバーが同じIPアドレスで複数のHTTPSサイトをホストできるように導入されたんだ。これは暗号化の普及にとって大きなプラスなんだけど、プライバシーに関しては大きな欠陥がある。TLSハンドシェイク中に接続しているドメイン名が平文で露出しちゃうんだ。つまり、ISPやWiFiプロバイダー、政府は、コンテンツが暗号化されていても、どのサイトを訪れているかを見たり、ブロックしたりできるってこと。SNIは監視のために設計されたわけじゃないけど、今では検閲やトラフィックシェーピングに広く利用されている。イギリス航空のWiFiの例がその一例だね。本当の解決策はECH（Encrypted ClientHello）で、これが情報を隠してエンドツーエンドのプライバシーを回復するんだ。ECHはすでにFirefoxやChromeでフラグの背後でサポートされていて、CloudflareやGoogleのような主要なCDNがより広く展開するにつれて、次の数年内にデフォルトになる可能性が高いよ。