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

 (saxrag.com)
1 ポイント 投稿者 GN⁺ 2025-10-25 | 1件のコメント | WhatsAppで共有
  • ブリティッシュ・エアウェイズの機内 無料メッセージングWiFiサービス は、実際には特定ドメインベースのフィルタリングによって制限付きのインターネット接続を許可していることが明らかになった
  • 筆者は TLS の SNI(Server Name Indication) フィールドを操作し、航空会社のシステムにメッセージング通信だと誤認させることで、一般的なWebサイトへのアクセスに成功した
  • そのために wa.me（WhatsApp のドメイン）を SNI に設定し、HTTPS プロキシと stunnel を使って通信を迂回した
  • 実験の結果、テキスト中心のサイト（Hacker News など）は正常に読み込まれた一方、画像や大容量コンテンツは 帯域制限 により低速で転送された
  • この事例は TLS SNI ベースのフィルタリングの脆弱性 と、それを補うための ECH(Encrypted Client Hello) 技術の必要性を示している

無料メッセージング WiFi の仕組み

  • ブリティッシュ・エアウェイズは「The British Airways Club」の会員に メッセージ専用の無料 WiFi を提供している
    • 登録は機内ポータルでメール認証なしに可能で、WhatsApp・Signal・WeChat は使えたが Discord はブロックされた
  • 筆者は、このサービスが どのような方法でメッセージングアプリだけを許可しているのか に疑問を持った
    • 単純な通信制限ではなく、TLS の SNI フィールドベースのドメインホワイトリスト だと判断された
  • Wireshark による分析では、example.com への接続時に Client Hello の後で TCP リセット が発生した
    • これは TLS ハンドシェイク中に露出する SNI 値 を使って、未許可ドメインを遮断する方式である

SNI ベースのフィルタリングの原理

  • TLS SNI は暗号化前の段階で 接続先ドメイン名を平文で送信 する
    • そのため ISP やネットワーク管理者は、ユーザーがどのサイトに接続しようとしているかを確認できる
  • ブリティッシュ・エアウェイズは メッセージングアプリ関連ドメインだけをホワイトリスト に登録し、それ以外は接続をリセットしていた
  • 筆者は、SNI なしの直接 IP 接続（openssl s_client -connect）もブロックされることを確認した
    • つまり SNI の欠落自体も異常な通信と見なされている

SNI 操作の実験

  • 筆者は wa.me（WhatsApp のドメイン）を SNI に設定して TLS 接続を試みた
    • サーバー証明書は wa.me 用ではなかったが、クライアント側で証明書不一致を無視すれば接続できた
  • 結果として BA のシステムはこれを メッセージング通信だと誤認 し、TLS トンネルを許可した
    • その後、HTTP リクエストを直接作成し、自身のサーバー（saxrag.com）のコンテンツ受信に成功した
  • この実験により SNI フィールドさえ偽装できれば任意の通信を流せる ことが実証された

HTTPS プロキシによる完全な回避

  • 筆者は tinyproxy と stunnel を使って HTTPS プロキシサーバー を構成した
    • stunnel は TLS レイヤーを追加し、クライアントが wa.me に接続しているように偽装する
  • curl コマンドで --resolve オプションを使い、wa.me を自身の VPS の IP にマッピングした
    • これにより SNI は wa.me に設定されたまま、実際の接続先は個人サーバーになる
  • TLS 証明書エラーは --proxy-insecure で無視し、プロキシ経由で外部リクエストに成功 した
    • ifconfig.co へのリクエストで VPS の IP が返され、プロキシが動作していることを確認した

実際のフライト中のテスト

  • 復路便で同じ設定を使って WiFi に接続したところ、curl で 正常な HTTP 200 レスポンス を受信した
    • その後、ブラウザ（Chromium）に HTTPS プロキシを設定し、wa.me を hosts ファイルに登録した
  • 結果として Hacker News のWebサイトへのアクセスに成功 し、テキスト中心のページは正常に表示された
    • Wireshark では SSLKEYLOGFILE を使って TLS 復号も確認した
  • 画像や大容量コンテンツは 行単位でゆっくり読み込まれ、帯域制限の存在が推測された
    • これは BA が SNI 以外にも通信速度制限を併用している ことを示唆している

ECH(Encrypted Client Hello) の実験

  • 筆者は TLS SNI 露出の問題を解決する ECH 技術 も実際に試した
    • wa.me を public_name に設定した ECHConfig を作成し、Firefox に適用した
  • その結果、外側の SNI は wa.me のまま維持される一方、内部の ClientHello には実際のドメイン（rfc5746.mywaifu.best）が含まれた
    • Let’s Encrypt の証明書で正常な TLS 接続が成立した
  • 興味深いことに 非標準ポート（7443） でも動作し、ブリティッシュ・エアウェイズのフィルタリングを回避した
  • 筆者は ECHConfig が DNS-over-HTTPS(DoH) で送信された可能性を指摘している

SNI の限界とセキュリティ上の示唆

  • SNI は本来、サーバー証明書選択のための 「ヒント」レベルの情報 にすぎない
    • クライアント・サーバーの双方を制御できる環境では 任意の SNI 値を挿入できる
  • これは検閲システムや脅威検知ソリューションが SNI ベースのフィルタリングに過度に依存した場合、誤検知が起こりうる ことを意味する
    • マルウェア作成者は C&C サーバー接続時に 無害なドメインを装った SNI を使える可能性がある
  • したがってネットワークセキュリティポリシーには、SNI 以外の追加的なトラフィック分析や暗号化レイヤーの検証 が必要である

結論

  • ブリティッシュ・エアウェイズの無料 WiFi は SNI ベースのドメインフィルタリングと帯域制限 によって、メッセージング通信だけを許可していた
  • しかし SNI を操作することで、任意の HTTPS 通信をメッセージングに偽装できる ことが実験で実証された
  • この事例は TLS 設計の構造的な限界を示し、ECH 導入の必要性 を強調している
  • ネットワーク事業者やセキュリティ担当者は、SNI 依存型フィルタリングの脆弱性 を認識する必要がある
  • 技術的には興味深い回避事例だが、セキュリティ・倫理面の考慮 も伴う研究事例である

関連記事

1件のコメント

 
GN⁺ 2025-10-25
Hacker Newsの意見
  • 友人が以前似たようなトンネリングをやっていて、クルーズ船でも動作していた
    一部の航空会社（たしか American Airlines）は Fortinet ファイアウォールを使っていて、単に SNI だけを見るのではなく、サーバー証明書のホスト名と認証局まで検証する
    その友人は aa.com の SNI を使い、実際の aa.com の TLS 1.2 ハンドシェイクをそのまま転送する方法でこれを回避した
    その後の暗号化データ段階ではそのハンドシェイクを無視し、単なる暗号化トンネルとして使っていた
    最近はTLS 1.3を使えば証明書が暗号化されてファイアウォールが内容を見られないので、こうした問題を避けられる
    • これは実際のところ Xray がやっている方式とほぼ同じ
      特定の SNI に合うリクエストが秘密鍵なしで入ってきた場合、SSL ハンドシェイク全体を偽装用ウェブサイトへプロキシする
      そうでなければ、SSL トラフィックに偽装した通常のプロキシとして動作する
      もともとは中国の**GFW（グレート・ファイアウォール）**を回避するために作られたが、友人が Google Analytics を SNI に設定したところ American の機内ファイアウォールでも動いたらしい
    • 自分も最近3週間のクルーズ旅行に行ったが、インターネットが1日50ドルと法外に高かった
      Wi‑Fi とアプリは無料で動くが、ほとんどのトラフィックは遮断される
      Wireshark で見ると、TCP 接続の初期に数個のパケットだけを許可し、その後 ClientHello を検査してホワイトリスト済みドメインだけを通していた
      クルーズアプリは会社ドメインがホワイトリストに入っているので動作する
      こういう抜け穴は悪用せず、静かに使うべきだ。広まりすぎると塞がれてしまうので残念だ
    • 最近のクルーズ船での本当の解決策は Starlink Mini を持っていくことだ
      アンテナ代も料金も高いが、クルーズ会社に対する一種の「自由宣言」として十分に価値がある
  • 自分は公共 Wi‑Fi（機内を含む）を UDP 53 番ポートの VPN サーバーで回避したことが何度もある
    最近はキャプティブポータルが外向きトラフィックをほぼ遮断するが、それでもまだ脆弱な場所は多い
    SoftEther を勧める。Azure Relay 機能のおかげでホワイトリスト方式のネットワークでもうまく動く
    まだ iodine を使って DNS 双方向通信までは試していないが、遅くてもたいていの場合は通りそうだ
    • 決済ウィジェットを表示するために一時的に全トラフィックを許可するポータルがある
      決済プロセスを繰り返し開始すれば、それで回避できる
    • 以前 Hetzner のサーバーに 8 個の IP を持たせ、そのうち 1 つは全ポートで OpenVPN を許可するように設定していた
      複数のポートを試すので開始は遅かったが、成功率は驚くほど高かった
    • 自分も WireGuard と OpenVPN をそれぞれ別の VPS で 53 番ポートで動かしている
      ただ最近は DNS トラフィックだけを許可し、任意のリゾルバは遮断することが多い
    • 一部の航空会社 Wi‑Fi は**無料メッセージング（WhatsApp、Messenger）**だけを許可している
      もし TCP-over-WhatsApp VPN を作れたら本当に面白そうだ
  • 誰かが言っていた「リクエストのペイロードをサブドメインとして送り、TXT レコードで応答を受け取る」方式は、まさに iodine のことだ
    • 自分も12年ほど前に似たことをやった
      DNS ではなく HTTP(S) を UDP トンネリングで流したのだが、Stansted 空港で無料 Wi‑Fi の30分制限内にセットアップ成功できたときはかなり誇らしかった
  • 以前 British Airways のサイバーセキュリティ面接を受けたが、かなり妙な体験だった
    ウェブサイトの深刻な脆弱性に触れたら、「重要なら pentest で見つかるはずだ」と言って軽く流された
    お互いあまり良い印象を持たないまま終わった
    • BA は実際、決済ページにカードスキマーのスクリプトを埋め込まれて侵害されたことがある
      機内 Wi‑Fi のセキュリティは実質的に収益化のための仕組みにすぎず、会社のセキュリティとは別物だ
    • ひょっとすると、彼らの面接自体が pentest だったのかもしれない
    • pentest は英国式の住宅調査のように役に立たないと感じる
      多くの会社は年1回の pentest さえやればセキュリティは終わりだと思っているが、実際に製品を知っているエンジニアは投資承認を得られない
  • 自分は海賊行為は窃盗とは違うと思っているが、これは本当に窃盗に近い
    技術業界は高収入の職種なのだから、Wi‑Fi 料金くらい払うべきだと思う
  • 自分は tuningfork というプロジェクトを作った
    トラフィックを別ノード経由でプロキシするツールで、ネットワークを理解するために自分で実装した
    イギリスの年齢確認法を回避する目的もあった
    GitHub リンク
  • ちなみにこういう方式は Domain Fronting と呼ばれる
  • 以前クルーズ関連の投稿が法的脅しを受けたことがあったので、今回のものもどれくらい持つのか気になる
    • その話のリンクを知っているなら聞きたい
  • 自分は飛行中にオフラインの状態でいるのを楽しむタイプだ
    しばらく世界と切り離されるあの時間が好きだ。だから皆が無料 Wi‑Fi を使えるようになるのはあまりうれしくない
    • でも結局は自由意志の問題だ
      君が望まないなら接続しなければいい。ほかの人が使っていても君には影響しない
    • 単にこんな手間をかけて無料 Wi‑Fi を手に入れなければいい
  • 今まさに British Airways の機内でこれを書いている
    無料メッセージングプランを有効にして WireGuard トンネルを使っているが、ファイアウォールが完全に遮断するようには設計されていないようだ
    • もしかして単に 51820 番ポートで WireGuard を動かしたのだろうか
      以前試したときはうまくいかなかった記憶がある