Free Wi-Fiの危険性を正しく恐れて、安全に使う方法

VPNは、信頼できないFree Wi-Fi上で通信経路を保護するための対策の一つです。ただし、接続前の認証、VPNの通信方式、切断時のKill Switchと再接続、接続先までのHTTPSを確認する必要があります。自宅Wi-Fiの認証や、社内システムの不要な公開入口も含め、実際の仕組みを確かめて対策を選びましょう。

ホテルやカフェ、空港などで利用できるFree Wi-Fi。

通信量を気にせず動画を見たり、仕事をしたり、海外から日本のサービスへアクセスしたりできる便利なサービスです。

一方で、「Free Wi-Fiは危険だから使わない方がいい」という話を聞いたこともあるでしょう。

最近ではHTTPSが普及し、Wi-FiにもWPA2やWPA3などの暗号化技術があります。それなら、以前ほど心配する必要はないのでしょうか。

実は最近、別件の技術調査をしていた際に、偶然ある研究論文を見つけました。

2025年のセキュリティ国際会議NDSSで発表された、

「Off-Path TCP Hijacking in Wi-Fi Networks: A Packet-Size Side Channel Attack」

という論文です。

NDSS 2025：原論文

この研究では、WPA2/WPA3で暗号化されたWi-Fiでも、通信内容を復号することなくTCP接続を攻撃できることが示されています。

しかも、単に接続を切断するだけではありません。

条件によっては、通信相手になりすまして不正なデータを注入することも可能になるという研究です。

もちろん、これだけでHTTPSの暗号化が破られるわけではありません。

しかし、こうした攻撃をきっかけに、利用するサービスの別の脆弱性が悪用されれば、情報漏洩や不正アクセスにつながる可能性もあります。

この記事では、この研究を入り口として、Free Wi-Fiに残るリスクと、私たちが身近なところから実践できるセキュリティ対策を考えてみます。

なお、ここでいうFree Wi-Fiには、暗号化されていないOpen Wi-Fiだけでなく、ホテルやカフェなどで共通パスワードを使って接続するWi-Fiも含めます。

WPA3でもTCP接続を攻撃できる？

従来の暗号化されていないWi-Fiでは、通信を観測することでTCPのシーケンス番号などを取得できる場合がありました。

その情報を利用して、有効なTCP RSTパケットを偽装し、通信を強制的に切断する攻撃は以前から知られています。

一方、WPA2やWPA3ではWi-Fiの通信が暗号化されるため、第三者がTCPヘッダーを直接読み取ることは困難です。

今回の研究が興味深いのは、ここです。

研究者らは、暗号化されたWi-Fiフレームのサイズの違いを手掛かりに、TCP接続の状態を推測する手法を示しました。

Wi-Fiの暗号鍵を解読することなく、すでに確立しているTCP接続を攻撃できるというのです。

研究では、実験条件下で次の結果が報告されています。

• SSHセッションを19秒で切断
• 暗号化されていないHTTP通信に28秒で不正データを注入
• 評価した80か所のWi-Fi環境のうち、75か所でTCP接続のハイジャックに成功

ただし、これは任意のWi-Fiで93.75%の確率で攻撃が成功するという意味ではありません。攻撃者の位置やパケットの観測・送信条件などが関係します。

また、この研究がHTTPSの暗号化を破ったわけでもありません。

HTTPSではTLSによってアプリケーションデータが保護されますが、HTTP/1.1やHTTP/2で使用されるTCPのヘッダーはTLSによる暗号化の対象外です。

そのため、通信内容を読めなくても、TCP接続そのものを妨害される可能性があります。

なお、HTTP/3はTCPではなくQUIC / UDPを使用するため、今回のTCP固有の攻撃は直接適用できません。ただし、HTTP/1.1やHTTP/2も広く利用されており、HTTP/3対応サービスでも接続環境によってTCPへ切り替わる場合があります。

通信が暗号化されていることと、通信を妨害されないことは別の問題なのです。

通信の切断だけでは終わらない

今回の研究で示されたのは、TCP RSTによる強制切断だけではありません。

条件によっては、平文HTTP通信へ不正なデータを注入することも可能です。

これは単なる通信障害ではなく、通信内容の改ざんにつながる攻撃です。

さらに注意したいのは、こうした攻撃が別の脆弱性を悪用するきっかけになる可能性があることです。

例えば、通信を強制的に切断されたことで再接続や再認証が発生したとします。

Webサービスの実装に問題があり、その際に暗号化されていないHTTPページへ誘導される場合、攻撃者が通信を改ざんしたり、偽のログイン画面を表示させたりする可能性があります。

また、保護されていない認証情報やセッショントークンがHTTP通信で送信されれば、それらを取得されるおそれもあります。

攻撃者が有効なセッショントークンを入手して再利用できれば、パスワードを知らなくても利用者になりすまし、その権限を悪用して不正アクセスする可能性があります。

もちろん、TCP接続を切断できるだけでHTTPSのセッションを乗っ取れるわけではありません。

適切にTLSで保護されたHTTPS通信へ、任意のデータを正規の通信として注入できるわけでもありません。

今回の研究で実証された攻撃と、別の実装不備が存在する場合に起こり得る二次的な攻撃は、区別する必要があります。

しかし、私たちが普段利用しているすべてのサービスについて、そうした弱点が存在しないことを確認するのは現実的ではありません。

だからこそ、信頼できないネットワークでは、サービス側のセキュリティ対策だけに頼らないことが重要です。

以前、OpenVPNで経験した原因不明の切断

以前、外出先のWi-FiでOpenVPNをTCPモードで利用していた際、ログインや認証操作のタイミングでVPNが突然切断されることが何度もありました。

当時はUDPよりTCPの方が信頼性が高いと考え、あえてTCPモードを使用していました。

特に問題だったのは、VPNがいつの間にか切断され、通常のインターネット接続へ戻ってしまう可能性があったことです。

そこで、VPNが切断されたときに通信を遮断するKill Switchに加え、接続状態を監視して自動的に再接続する仕組みもアプリに実装しました。

当時は通信経路上での妨害や端末側の問題なども疑いましたが、原因を特定することはできませんでした。

今回の研究を知って、当時の経験を思い出しました。

もちろん、以前の切断が同じような攻撃によるものだったという証拠はありません。

ただ、この経験から学んだことがあります。

VPNは、暗号化されているだけでは十分ではないということです。

VPNが切断された際に、通信が保護されていない回線へ流れてしまえば、それまでVPNで守られていた通信経路が変わります。

HTTPS通信なら、VPNが切断されてもTLSによる保護は残ります。

しかし、HTTPなどの暗号化されていない通信が流れたり、VPN内部に収容されていた通信が信頼できないWi-Fi上へ直接流れたりする可能性があります。

そのため、次の2つを分けて考える必要があります。

• Kill Switch：VPNが切断されたとき、意図しない直接通信を防ぐ
• 自動再接続：VPNの切断を検知し、接続を復旧する

どちらも重要ですが、役割は異なります。

セキュリティには可用性も必要

情報セキュリティでは、一般に次の3つの要素が重視されます。

要素	意味	対策の例
機密性	第三者に情報を知られない	暗号化、アクセス制御
完全性	情報を不正に改ざんされない	TLS、認証、改ざん検出
可用性	必要なときに利用できる	再接続、冗長化、復旧手順

これらはCIAと呼ばれています。

通信内容が暗号化されていても、VPNが頻繁に切断されて仕事にならなければ困ります。

逆に、通信を復旧することを優先するあまり、VPNを使わない通信へ自動的に切り替わってしまうのも問題です。

通信を保護することと、安全に利用を継続できること。その両方を考える必要があります。

私たちにもできるセキュリティ対策

ここまでの話を聞くと、Free Wi-Fiを利用するのが怖くなってしまうかもしれません。

しかし、危険だから使わないというだけでは、問題の解決になりません。

ホテルやカフェのネットワーク設備を、利用者が変更することはできません。

また、普段使っているすべてのWebサービスについて、認証やセッション管理の実装を調査することもできないでしょう。

では、私たち自身には何ができるのでしょうか。

身近なところから実践できるセキュリティ対策の一つが、VPNの利用です。

VPNを利用すれば、端末からVPNの出口までの通信を暗号化されたトンネルに収容できます。

これにより、信頼できないWi-Fi上の第三者が、VPN内部の通信内容やTCPヘッダーを直接観測することを防げます。

特に、ホテルやカフェ、空港など、自分で管理できないWi-Fiを利用する際には、VPNによる通信経路の保護を基本にすることをおすすめします。

ただし、VPNを利用しても、接続先サービス自体の脆弱性がなくなるわけではありません。

また、VPNの出口からアクセス先までの通信が、必ずしもVPNによって暗号化されるわけではありません。HTTPSなど、アプリケーション側の暗号化も引き続き重要です。

そして、もう一つ確認しなければならないことがあります。

VPNにはさまざまな種類があり、VPNを利用すること自体が別のリスクを生む場合もあるということです。

ただし、VPNなら何でもよいわけではない

VPNの安全性は、暗号化アルゴリズムだけでは決まりません。

どの通信方式を使っているのか。接続する前にどのような認証が必要なのか。VPNが切断されたらどうなるのか。自宅や会社のネットワークを外部へ公開する必要があるのか。

こうした違いも重要です。

TCPを使用するVPNには注意

従来型のSSL VPNや、TCPモードのOpenVPNなどには、VPNの外側にTCP接続を使用する構成があります。

この場合、外側のTCP接続が攻撃対象になれば、VPNトンネル全体が切断される可能性があります。

また、P2P型VPNの中には、端末同士の直接接続が成立しない場合、自動的に中継サーバーへ切り替わる製品があります。

その中継方式がTCP/TLSなら、利用者が意識しないうちに、VPNの外側でTCP通信を使用している場合もあります。

もちろん、すべてのSSL VPNやP2P型VPNがTCPを使用するわけではありません。

TCPを使用しているからといって、直ちに暗号化が破られるわけでもありません。

しかし、今回の研究のようなTCP固有の攻撃を考えると、VPNが実際にどの通信方式で動作しているのかを確認する価値があります。

特に重要なのが、VPN切断時の挙動です。

Kill Switchが機能せず、VPNから通常回線へ通信が切り替わる構成では、意図しない情報の露出につながる可能性があります。

VPNに接続するためのユーザー認証は安全か？

もう一つ、意外と見落としやすいのが、VPNへ接続する前に行われるユーザー認証です。

VPNサービスによっては、接続時にユーザー名とパスワードを入力したり、ブラウザを開いてSSOやOAuthなどによる認証を行ったりする必要があります。

ここで考えたいのは、VPN接続前の通信経路です。

例えば、ホテルのFree Wi-Fiに接続し、VPNサービスへログインしてから業務システムにアクセスするとします。

この場合、Webログインや認証トークンの取得がVPN接続前に行われる構成では、その認証通信は、まだVPNによって保護されていません。

もちろん、適切にHTTPSで保護されていれば、Wi-Fi上の第三者が認証情報を簡単に盗み取れるわけではありません。

しかし、HTTPSで保護された認証通信でも、外側のTCP接続を妨害される可能性があります。

また、利用者を偽のログイン画面へ誘導するフィッシングや、認証トークンの不適切な管理など、認証処理そのものに関わるリスクも考える必要があります。

特に、認証エラーや再接続が発生した際に、保護されていないHTTP通信へ切り替わるような実装があれば、認証情報の漏洩につながるおそれがあります。

さらに、認証サーバーへ到達できない場合、VPNそのものを開始できなくなることもあります。

ただし、これはユーザー認証を行うVPNが危険だという意味ではありません。

ユーザー認証やMFAは、VPNへの不正接続を防ぐための重要な対策です。問題は、その認証がいつ、どの経路で、どのように行われるのかという点です。

VPNの接続前認証を確認する際には、次のような違いを意識するとよいでしょう。

確認すること	なぜ重要か
接続前にWebログインが必要か	VPN外で行われる認証通信があるかを把握するため
認証ページが適切にHTTPSで保護されているか	認証情報の盗聴・改ざんを防ぐため
再認証時の動作はどうなるか	切断や通信妨害時の挙動を確認するため
認証後のトークンをどう管理するか	トークン漏洩・不正利用のリスクを抑えるため
VPNが接続できない場合、通信はどうなるか	意図しない直接通信を防ぐため

VPNで通信を保護するだけでなく、VPNに接続するまでの認証処理も安全に設計されているか。

これも、VPNを選ぶ際に確認したいポイントです。

自宅や会社に直接接続するVPNにもリスクがある

自宅や会社にVPNサーバーを設置し、外出先から直接接続する方法もあります。

この場合、一般的な構成では外部からVPNサーバーへ到達できる入口が必要です。

IPv4でのPort Forwardや、IPv6でのInbound Firewallルールなどを設定する場合があります。

VPNサーバーやルーターに脆弱性が存在すれば、その公開入口が攻撃対象になる可能性があります。

また、接続先として自宅や会社のPublic IPアドレスを相手に知らせる構成では、GeoIPなどから、おおよその地域や利用しているISPを推測される場合があります。

GeoIPだけで正確な住所がわかるわけではありません。しかし、接続相手が近隣の人物などであれば、ほかの情報と組み合わせて所在地を絞り込む手掛かりになる可能性があります。

P2P型VPNでも、直接接続する相手へPublic IPアドレスを知らせる方式があります。

ただし、P2Pだから必ずPort Forwardが必要というわけではありません。NAT Traversalなどを利用する方式もあります。

信頼できないWi-Fiで通信を守るためのVPNが、自宅や会社を新たな攻撃対象にしていないか。

この点も考えておきたいところです。

HomeGrid VPNとTCPベースVPNの違い

ここでは、HomeGrid VPNと、外側の通信にTCPを使用するVPNを直接比較します。通信方式と復旧動作に加え、接続時の認証や拠点側の公開範囲も確認します。

比較項目	TCPベースVPN	HomeGrid VPN
外側の通信方式	TCP	WireGuard / UDP
TCP RST攻撃	外側のTCP接続が対象になり得る	外側には直接適用されない
一時的な通信断	TCP接続の再確立が必要になる場合がある	TCP接続の張り直しは不要
通信復旧	製品の再接続処理による	必要に応じてハンドシェイクを実行
IPアドレスの変更	製品・実装による	Endpointのローミングに対応
Kill Switch	製品・設定による	クライアント・設定による
通常接続時の認証	製品・実装による	登録済み端末のWireGuard鍵（初回登録・管理画面は別認証）
拠点側のVPN公開入口	製品・構成による	Cloud HubへのOutbound接続で不要
通信妨害	TCP固有の攻撃面がある	UDPの遮断・妨害は受け得る

HomeGrid VPNは、WireGuard / UDPで暗号化されたIPパケットを転送します。

TCPのような接続確立・切断の仕組みを外側に持たず、必要に応じてハンドシェイクや鍵の更新を行います。

例えば、スマートフォンがホテルのWi-Fiからモバイル回線へ切り替わった場合にも、通信経路の変化に対応する仕組みがあります。

ただし、通信が途絶えている間もデータが流れ続けるわけではありません。通信断が長時間続けば、VPN内部のTCP接続がタイムアウトする場合もあります。

また、UDPが遮断されるネットワークでは接続できない可能性があります。

HomeGrid VPNが絶対に切断されないということではなく、TCPを外側に使用するVPNとは通信復旧の仕組みが異なるということです。

HomeGrid VPNは拠点側に公開入口を設けない

HomeGrid VPNは、WireGuard / UDPを使用したHub & Spoke型のVPNです。

自宅や会社側に設置するGridと、外出先のRemote端末が、それぞれCloud Hubへ接続します。

自宅や会社側からCloud HubへOutbound通信を行うため、拠点側でVPNの公開待受ポートを設ける必要がありません。

IPv4のPort ForwardやIPv6のInboundルール、DDNSなども前提としません。

また、リモート端末から自宅や会社のPublic IPアドレスへ直接接続する構成でもありません。

これにより、拠点に公開VPNサーバーを設置する方式とは、外部に公開するネットワークの範囲が異なります。

接続のたびにWebログインしない設計

HomeGrid VPNでは、初回登録時に端末を有効化した後、通常のVPN接続は端末側で管理するWireGuardの鍵を使用します。

そのため、VPNへ接続するたびに、ブラウザを開いてIDとパスワードを入力する必要はありません。

接続前のWebログインや、その都度の認証画面へのリダイレクトに依存しない構成です。

ただし、これは認証を省略しているという意味ではありません。

初回の端末登録や管理画面の利用には認証が必要であり、登録済み端末についてはWireGuardの鍵によって接続相手を識別します。

また、鍵を持つ端末自体が侵害された場合には別の対策が必要です。

重要なのは、VPNの利用開始時にどのような認証を行い、その後の接続をどのように維持する設計なのかという違いです。

Cloud Hubとインターネットへの出口は別

HomeGrid VPNでは、Cloud HubはVPN通信の中継点として経路上に存在します。

ただし、Cloud Hubがインターネットへの出口になるとは限りません。

例えば、自宅のGridをExitにした場合、通信はCloud Hubを経由して、実際に自宅回線からインターネットへ出ます。

このときアクセス先に見えるのは、Cloud HubのデータセンターIPではなく、自宅側のPublic IPアドレスです。

HomeGrid VPNでは、こうしたOutbound Only構成に加え、Kill SwitchやLAN ACLなどを利用して、通信経路やアクセス範囲を制御できます。

一方で、Cloud Hubは通信経路上の構成要素であり、中継基盤の可用性や運用上の信頼も考慮する必要があります。

また、HomeGrid VPNを利用しても、すべての通信障害や攻撃を防げるわけではありません。

重要なのは、VPNの通信方式だけでなく、接続前の認証、通信の切断時の動作、自宅や会社に公開する入口まで含めて設計することです。

自宅Wi-Fiは安全か？

ここまでは、自分で管理できないFree Wi-Fiの話をしてきました。

では、自宅のWi-Fiなら安心できるのでしょうか。

自宅でも、パスワードが弱かったり、多くの人に共有されていたりすれば、不正に接続される可能性があります。

そこで、家庭でも実践できる対策を考えてみましょう。

WPA2ではGPUによるオフライン攻撃に注意

WPA2-Personalでは、攻撃者が4-way handshakeなどの認証情報を取得すると、GPUを使ってパスワード候補をオフラインで検証できます。

公開されているNVIDIA GeForce RTX 5090のHashcatベンチマークでは、WPA2の解析に使用されるモード22000で、約336万候補/秒という結果が報告されています。

RTX 5090 Hashcat Benchmark

攻撃者が持っているパソコン1台の性能だけで、パスワードの安全性を判断してはいけません。

クラウドのGPUレンタルサービスでは、高性能GPUを時間単位で借りられます。1台のマシンで複数GPUを使う並列処理に加え、複数のマシンへ候補を分担する分散処理も可能です。攻撃者が機器をすべて所有している必要はありません。

大規模に計算資源を投入すると、何文字まで危ない？

ここでは、複数のマシンに分散した合計で、GPU100枚相当と1万枚相当の処理能力を比較します。

上記のWPA2ベンチマークを基に、大小英数字62種類から完全ランダムに生成したパスワードの全候補を探索する時間を計算すると、次のようになります。

文字数	GPU 100枚での全探索	GPU 1万枚での全探索	選ぶ際の目安
8文字	約7.5日	約1.8時間	避ける
10文字	約79年	約289日	新しく設定するなら、もっと長くする
12文字	約30万年	約3,000年	この条件の総当たりには強いが、長さに余裕を持たせたい
16文字	約4.5兆年	約450億年	完全ランダムなら十分に大きな探索空間
24文字	約9.8×10²⁶年	約9.8×10²⁴年	自宅Wi-Fiで推奨
32文字	約2.1×10⁴¹年	約2.1×10³⁹年	手入力が少ないなら推奨

※同等性能のGPUで候補を分担し、台数に比例して高速化できると仮定した概算です。起動・分配などの時間を含まず、完全ランダムなパスワードの平均発見時間は概ね半分になります。1万枚を同時に調達できることや、攻撃費用が見合うことを示すものではありません。長大な年数は現在の計算速度を固定した計算結果であり、将来の安全性をその期間にわたって保証するものではありません。

8文字では、GPU100枚で約7.5日だったものが、合計1万枚なら約1.8時間まで短くなる計算です。 並列化で期間を短縮しても、総GPU利用時間と費用が同じ割合で減るわけではありません。

完全ランダムな16文字なら、この条件での総当たりに対して十分に大きな余裕があります。Wi-Fiでは頻繁に手入力する必要がないため、自宅では24〜32文字程度を生成して使うことをおすすめします。

なお、これはWPA2の計算例です。漏洩したMD5やNTLMなどの高速なハッシュ値を解析する場合とは速度が異なり、「8文字なら何分」と一律には判断できません。数字だけの8文字なら、上記のWPA2ベンチマークではGPU1枚でも全候補を約30秒で検証できる計算です。

長ければ、人間が考えたパスワードでもよい？

さらに、人間が考えたパスワードでは、すべての候補を試す必要がない場合があります。

例えば、

• password123456
• MyHomeWiFi2026!
• TokyoYokohama2026
• P@ssw0rd12345678

といった文字列は、長く見えても人間が考えやすい規則性があります。

攻撃者は、すべての組み合わせを順番に試すのではなく、辞書に登録された単語や年号、典型的な文字置換などを優先して試すことができます。

人間が考えた20文字のパスワードと、乱数で生成した20文字のパスワードは、同じ強度とは限らないのです。

WPA3ならどうなる？

WPA3-Personalでは、SAEという認証方式が採用されています。

SAEは、WPA2-PSKで問題となる、取得したハンドシェイクに対する通常のオフライン辞書攻撃に耐性を持つよう設計されています。

そのため、WPA2のように認証通信を記録してGPUで大量のパスワード候補を検証する攻撃は、通常成立しません。

ただし、WPA3だから短いパスワードでよいわけではありません。

パスワードそのものの漏洩、機器の脆弱性、オンラインでの推測など、ほかのリスクは残ります。

混在モードでは、切断を利用した誘導にも注意する

WPA2/WPA3混在モードでは、WPA3接続にはPMF（Protected Management Frames）が必要ですが、WPA2接続では必須になっていない場合があります。その場合、PMFで保護されていない端末は、偽造Deauthフレームによって切断される可能性があります。

攻撃者は、その接続障害を利用して、偽アクセスポイントへの再接続や、セキュリティ設定の変更、偽画面でのパスワード入力を促すことがあります。また、端末の対応や設定によっては、WPA2認証へ誘導するダウングレード攻撃の余地も残ります。WPA3とTransition Disableの解説

切断されたこと自体でWPA3からWPA2へ自動的に切り替わるわけではありません。SSIDをコピーしただけで、PSKを知らない偽APが保存済みのWPA2接続を正常に成立させられるわけでもありません。しかし、「つながらないから保護を弱める」という操作を誘われることにも注意が必要です。

こうした誘導は、攻撃者が電波の届く範囲にいれば、自宅でも起こり得ます。「復旧や更新のためWi-Fiパスワードを入力してください」と突然表示されても安易に入力せず、普段使う管理アプリや既知の管理画面から確認してください。接続障害を理由に暗号化やPMFを無効にしないことも重要です。PMFは偽造Deauthへの対策になりますが、電波妨害全般を防ぐものではありません。

自宅の機器が対応しているなら、WPA3-Personal専用モードと、十分に長いランダムパスワードの組み合わせをおすすめします。

リモートワークでは接続先の認証も重視する

業務で使うWi-Fiでは、パスワードの長さだけでなく、偽アクセスポイントへ誘導されても、不正な接続先を受け入れない構成を重視しましょう。

組織が認証基盤と端末設定を管理できる場合は、WPA2-Enterprise（EAP-TLS）とPMF必須化を推奨します。端末には信頼する認証局と認証サーバー名をあらかじめ設定し、サーバー証明書を正しく検証させます。不明な証明書を利用者の操作で承認させたり、検証を無効にしたりしないことが重要です。EAP-TLSのサーバー認証要件

家庭などでその運用が難しい場合は、対応機器でWPA3-Personal専用モードを優先しましょう。WPA2へのフォールバックを残さず、PMFが必須となる接続を使えます。ただし、共有パスワードを知る相手の偽APまで識別するものではなく、EAP-TLSの証明書による認証と同等ではありません。

EAP-TLSの認証相手は認証サーバーであり、PMFは接続先の身元を証明する機能ではありません。認証と切断通知の保護を組み合わせ、接続障害を理由に保護を弱めないことが大切です。どちらの構成でも、端末・機器の更新と業務通信のVPN・HTTPSによる保護は引き続き必要です。

自宅でも、接続先のWi-Fiを無条件に信用しない

長いパスワードを設定しても、認証方式や端末設定、利用者の操作によっては、気づかないうちに偽アクセスポイントへ接続してしまうリスクがあります。通信の切断や再接続を、その誘導に利用される場合もあります。

これはホテルやカフェだけの問題ではありません。自宅でも外出先でも、信頼できないWi-Fiへ接続してしまう可能性を考慮する必要があります。

使わなくなったFree Wi-Fiの接続設定は削除し、保存済みネットワークやOS・キャリア提供機能の自動接続は、必要なものに限定しましょう。

接続先のネットワークが安全だと確信できないからこそ、VPNで通信経路を保護することは、利用者自身で実施できる数少ないセキュリティ対策の一つです。対象の通信を正規のVPNへ通し、切断時にはKill Switchで直接通信を防ぎましょう。

適切なHTTPS通信の保護は偽AP上でも残りますが、HTTPなど保護されていない通信では、認証情報やセッション情報の漏洩につながるおそれがあります。VPN接続前の通信や偽画面に直接入力する情報は、そのVPNでは保護できないため、HTTPSの利用と不審な認証画面への警戒も引き続き必要です。

パスワードは乱数から生成する

Wi-Fiのパスワードは、頻繁に手入力するものではありません。

無理に覚えやすい文字列を考えるより、暗号学的に安全な乱数から生成した方が合理的です。

例えば、Pythonならsecretsモジュールを使って生成できます。

import secrets
import string

alphabet = string.ascii_letters + string.digits

password = ''.join(
    secrets.choice(alphabet) for _ in range(32)
)

print(password)

この例では、英大文字・小文字・数字を使った32文字のパスワードを生成します。

さらに、手入力時に間違えやすい文字を除外することもできます。

import secrets

alphabet = (
    "ABCDEFGHJKLMNPQRSTUVWXYZ"
    "abcdefghijkmnopqrstuvwxyz"
    "23456789"
)

password = ''.join(
    secrets.choice(alphabet) for _ in range(32)
)

print(password)

こちらでは、0とO、1とlなど、見間違えやすい文字を除外しています。

利用する文字の種類は少なくなるため、先ほどの62種類の表とは条件が変わりますが、32文字あれば十分に大きな探索空間を確保できます。

Wi-Fiのパスワードなら、24〜32文字程度を一つの目安にするとよいでしょう。

生成したパスワードは、パスワード管理ツールに保存するか、紙に正確に記録して安全な場所に保管してください。

スマートフォンなどが故障しても確認できるよう、復旧手段も考えておくと安心です。

自宅Wi-Fiの安全性は、高価な機器を導入する前に、認証方式とパスワードを見直すところから改善できます。

来客には別の接続情報を渡し、必要なときだけ有効にする

QRコードで共有しても、Wi-Fiの接続情報を相手へ渡したことになります。画像の転送や端末からの再共有も考え、仕事や家庭内機器に使うメインのパスワードは、そのまま来客へ渡さないようにしましょう。

来客用には別SSID・別パスワードを用意し、来客時だけ有効にして、帰ったら無効にする運用が手軽です。接続情報が意図せず広まった場合は、来客用のパスワードを変更してください。

ただし、SSIDを分けただけでは、家庭内LANから分離されるとは限りません。対応機器ではゲスト機能などで家庭内LANや管理画面へのアクセスを禁止し、現在のルーター／APモードでも分離が機能するか確認しましょう。分離できない場合は、来客自身のモバイル回線を利用してもらう方法もあります。

SSIDを停止しても、同じ名前の偽APへの接続リスクまでなくなるわけではありません。別の接続情報、必要なときだけ有効化、可能ならLAN分離を組み合わせましょう。

長いパスワードや更新だけで安心しない

「WPA2でも長いパスワードなら安全」「KRACKなどの既知の脆弱性は修正されたので問題ない」という説明だけでは、残るリスクを十分に判断できません。

十分に長いランダムパスワードは、主にパスワード推測への対策です。ファームウェアの更新も、既知の脆弱性を修正するために欠かせません。しかし、最新版にしているだけで、Wi-Fiの安全性が確保されるわけではありません。

更新しても、PMFを使わない設定や、不十分な認証サーバーの証明書検証が自動的に改善されるとは限りません。偽アクセスポイントへの誘導や、接続障害を口実に保護を弱めさせる攻撃にも、別の備えが必要です。

対応している機器では、ファームウェアの自動更新や更新通知を有効にし、メーカーのセキュリティ情報をメールなどで受け取れるようにしておきましょう。

自動更新がない場合は、定期的に確認する予定を設けるなど、修正の公開に早く気づき、速やかに適用できる仕組みを用意してください。サポートが終了し、セキュリティ更新が提供されなくなった機器は、買い替えも検討しましょう。

長いパスワードも、ファームウェアの更新も必要です。ただし、どちらか一つで十分ではありません。認証方式とPMFの設定、端末側の証明書検証、VPNによる通信経路の保護を組み合わせて考えましょう。

将来の量子計算まで考えるなら

将来の量子計算では、Groverのアルゴリズムによってパスワードの総当たり探索が高速化される可能性があります。その意味でも、短いパスワードに頼らず、十分に長いランダムパスワードを使うことが重要です。

ただし、上のGPUの速度から量子計算での所要時間を算出することはできません。量子回路の実装コストや並列化の制約もあります。NISTの解説

また、パスワードを長くするだけで、WPA2やWPA3を含む通信方式全体が耐量子になるわけではありません。暗号方式や鍵交換の仕組みも関係します。

家庭での実践としては、まず24〜32文字程度のランダムパスワードを使い、機器を更新し続けましょう。長期間の機密性まで求める場合は、パスワードの長さに加え、通信方式の耐量子対応も確認する必要があります。

社内システムも通信経路を見直そう

ここまでの考え方は、企業の情報システムにも当てはまります。

例えば、社内LANで利用することを前提に作られた業務システムやREST APIを、リモートワークのためにインターネットへ公開していないでしょうか。

近年は「VPNは古い」「これからはゼロトラスト」という話を耳にすることもあります。

しかし、ゼロトラストとは、VPNを廃止したり、すべての業務システムをインターネットへ公開したりすることではありません。

重要なのは、ネットワークの内側にいるという理由だけでアクセスを信用せず、利用者や端末、アクセス先に応じて適切に認証・認可することです。

ZTNAやSASEも、その考え方を実現するための選択肢です。ただし、導入しただけでアプリケーション自体の脆弱性や、不適切なアクセス制御がなくなるわけではありません。

適切に構成したZTNAでは、アプリケーションをインターネットへ直接公開せずにアクセスさせることもできます。

同様に、HTTPSで通信を暗号化し、Reverse Proxyで認証を追加しても、それだけで既存の業務システムが安全になるとは限りません。

本来、社内LANで利用するために作られたシステムを、わざわざインターネットへ直接公開する必要があるのか。

まずは、その構成自体を見直すことも重要です。

既存システムを公開せずにリモートから利用する

例えば、HomeGrid VPN経由で業務システムやREST APIへアクセスする構成にすれば、既存のアプリケーションを大きく改修せずに利用できる場合があります。

自宅や会社側はCloud HubへOutbound接続するため、VPN接続用に拠点のInboundポートを公開する必要もありません。

リモートアクセスのためだけに外部公開していたReverse ProxyやAPIの入口も、不要であれば廃止できます。

さらに、LAN ACLによってVPN内部のアクセス範囲を制限できます。

ただし、VPNの利用自体がゼロトラストを実現するわけではありません。アプリケーションの認証・認可、端末管理、必要最小限のアクセス制御は引き続き重要です。

VPNかゼロトラストかという二者択一ではなく、不要な公開入口を減らし、必要なアクセスだけを許可する。

それが、既存システムを活用しながらネットワークを見直す考え方です。

クラウドに仮想サーバールームを作る

さらに、業務システムをAWSやAzureなどのVPC/VNetへ移し、クラウド上に「仮想サーバールーム」を構築する方法もあります。

オフィスに設置した物理サーバーは、地震、浸水、火災、停電などで利用できなくなる可能性があります。

HomeGrid VPNのSite Linkでオフィスとクラウドを接続すれば、業務システムをインターネットへ直接公開せずに利用できます。

必要に応じて、リモート端末からもVPN経由でアクセスできます。

この構成なら、オフィスの物理設備に業務システムを集中させるリスクを減らしながら、既存のシステムを活用することも可能です。

もちろん、クラウドへの移行だけでBCPが完成するわけではなく、バックアップや冗長化、障害時の復旧手順も必要です。

アプリケーションを作り直す前に、どこに配置し、誰に、どの通信経路からアクセスさせるのかを見直してみる。

それも、現実的なセキュリティ対策の一つです。

これからはVPNの仕組みも確認して選ぶ

セキュリティ対策を導入していた企業でも、情報漏洩や不正アクセスの被害が発生することがあります。

VPNやセキュリティサービスを選ぶ際、運営企業の知名度や導入実績、利用者数などを重視することは、決して間違いではありません。

しかし、それだけで技術的な安全性まで判断できるわけではありません。

攻撃手法は研究され続け、従来は十分に意識されていなかったリスクも明らかになっています。

今回紹介した研究も、その一例です。

これからは、誰が提供しているかだけでなく、どのような仕組みで通信を保護しているのかを確認することが重要です。

例えば、VPNサービスを選ぶ際には、次の点を確認してみましょう。

• 接続前の認証：VPNへ接続する前にWebログインが必要か。その認証はどのように保護されているか。
• 通信方式：TCPなのかUDPなのか。中継時に方式が変わるのか。
• 切断時の動作：Kill Switchがあり、意図しない直接通信を防げるか。
• 公開範囲：自宅や会社に外部公開されたVPN入口が必要か。
• 運用と復旧：通信が切断されたとき、安全に再接続できるか。脆弱性にどう対応するか。

わからないことがあれば、サービス提供元へ問い合わせてみましょう。

もちろん、HomeGrid VPNについても同じ基準で確認してほしいと考えています。

「有名だから安心」から、「仕組みを理解して選ぶ」へ。

これからのセキュリティ対策には、そうした意識の転換も必要なのではないでしょうか。

まとめ：身近なところからセキュリティを見直そう

今回紹介した研究では、WPA2/WPA3で暗号化されたWi-Fiでも、条件によってはTCP接続を妨害したり、平文HTTP通信へ不正なデータを注入したりできることが示されました。

こうした攻撃が別の脆弱性を悪用するきっかけになれば、認証情報の漏洩やセッション乗っ取り、不正アクセスへ発展する可能性もあります。

もちろん、適切にHTTPSで保護された通信が、TCP接続を切断されただけで乗っ取られるわけではありません。

しかし、利用するすべてのサービスに脆弱性が存在しないことを、私たちが確認するのは現実的ではありません。

だからこそ、自宅やオフィス以外の信頼できないWi-Fiでは、VPNで通信経路を保護することを基本にしましょう。

ただし、VPNにもさまざまな方式があります。

VPN接続前のユーザー認証が安全に保護されているか。通信が切断された際に保護が失われないか。自宅や会社に不要な公開入口を設けていないか。

こうした実際の仕組みを理解することが重要です。

自宅Wi-Fiについても、WPA3の利用や、十分に長いランダムパスワードの設定など、身近なところから実践できる対策があります。

そして、こうした考え方は企業の情報システムにも当てはまります。

ゼロトラストはVPNの対義語ではありません。

ネットワークの内側だから安全と決めつけず、不要な公開入口を減らし、必要なアクセスだけを許可する。

既存システムやREST APIをHomeGrid VPN経由で利用する構成に変更すれば、大きな改修をせず、不要な公開入口を減らせる場合があります。

さらに、クラウド上に仮想サーバールームを構築し、Site Linkで社内ネットワークと接続する方法もあります。

セキュリティ対策は、必ずしも大規模なシステム改修から始める必要はありません。

まずは、自分が使っているWi-Fi、VPN、そして業務システムへの通信経路を確認する。

身近なところから実践できる対策を、一つずつ積み重ねていきましょう。

---

参考資料

• Ziqiang Wang et al., Off-Path TCP Hijacking in Wi-Fi Networks: A Packet-Size Side Channel Attack, NDSS 2025
  https://www.ndss-symposium.org/ndss-paper/off-path-tcp-hijacking-in-wi-fi-networks-a-packet-size-side-channel-attack/
• RFC 5961, Improving TCP’s Robustness to Blind In-Window Attacks
  https://www.rfc-editor.org/rfc/rfc5961
• WireGuard公式サイト
  https://www.wireguard.com/
• Hashcat RTX 5090 Benchmark
  https://github.com/0x3444/hashcat_benchmarks/blob/main/NVIDIA_GeForce_RTX_5090.txt
• Python公式ドキュメント：secrets
  https://docs.python.org/3/library/secrets.html
• OWASP, Session Management Cheat Sheet
  https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
• NIST SP 800-207, Zero Trust Architecture
  https://csrc.nist.gov/pubs/sp/800/207/final
• HomeGrid VPN公式サイト
  https://www.homegrid-vpn.com/