こんにちは！Development事業部フロントエンドエンジニアのさかなです。

「カフェのフリーWi-Fiは危険だから使わない」「業務で使うなら必ずVPNに接続するべき」といった話を、一度は耳にしたことがあるのではないでしょうか。

こうした考え方は、長い間セキュリティの常識とされてきました。しかし、HTTPSやTLSの普及によってWebを取り巻く環境は大きく変化し、フリーWi-Fiの脅威も以前とは様変わりしています。

では、現代のフリーWi-Fiで本当に警戒すべきものは何なのでしょうか。

本記事では、HTTP時代から現在までの脅威の変化を振り返りながら、HTTPSが解決したこと、そして今なお残るリスクについて解説します。

さかな：Development事業部フロントエンドエンジニア。東北大学文学部で心理学を学びながらカナダ・モントリオールに3年間居住。帰国後コーディングを独学し、GIGにジョイン。現在はサイト制作のフロント実装や自社サービスLeadGridの開発を行う。最近はAIやインフラに興味がある。

HTTP時代のフリーWi-Fiが危険だった理由

「フリーWi-Fiは危険だから使うな」

この考え方は、HTTP通信が主流だった時代であれば正しいものでした。同じネットワーク上の第三者が通信内容を盗み見できたからです。

しかし、現在ではHTTPSが当たり前になり、このような攻撃は難しくなりました。その変化を理解するために、まずはHTTP時代に何が危険だったのかを振り返ってみましょう。

通信内容が平文で流れていた時代

現在では当たり前になったHTTPSですが、2010年代前半まではHTTP通信が一般的でした。HTTP通信では通信内容が暗号化されないため、ブラウザとWebサーバーの間でやり取りされるデータは、そのままネットワーク上を流れていました。

たとえば、ユーザーが以下のようなリクエストを送信するとします。

---
http
POST /login HTTP/1.1
Host: example.com
username=taro
password=password123
---

HTTPではこの内容がそのまま送信されてしまいます。そのため同じWi-Fiネットワーク上に攻撃者がもしいれば、パケットキャプチャツールを利用して、この通信内容をそのまま閲覧できていたのです。

パスワードもCookieも盗み見できた

問題はログイン時のパスワードだけではありません。

当時は、ログイン状態を保持するためのセッションCookieもHTTP通信で送信されていたため、ネットワーク上で盗み見されると、そのまま本人になりすましてログインできました。

有名な例として2010年頃には「Firesheep」というFirefox拡張が話題になりました。

これはSSL化を推進する目的として作られ、同じWi-Fi上のユーザーのFacebookやTwitterのセッションを奪い、そのままアカウントを乗っ取れるツールです。特別な知識がなくても利用できたため、フリーWi-Fiの危険性が広く認識されるきっかけになりました。

当時「フリーWi-Fiは危険」と言われていたのは誇張ではなく、技術的に本当に危険だったのです。

HTTPS（TLS 1.3）はなぜ盗聴を防げるのか

現在のWebは、HTTPSが標準です。このHTTPSの中核技術がTLS（Transport Layer Security）であり、主に次の3つの機能を実現しています。

TLSの目的：暗号化・改ざん防止・認証

・Confidentiality（機密性）
第三者が通信内容を読めないようにします。ユーザー名、パスワード、Cookie、メール本文などが暗号化されます。

・Integrity（完全性）
通信途中でデータを書き換えられていないことを保証します。攻撃者が通信内容を書き換えても検知できます。

・Authentication（認証）
接続先が本物のサーバーであることを証明します。たとえば、「本当に example.com に接続しているのか」を確認する仕組みです。

TLSハンドシェイクの仕組み

HTTPS通信では、最初にTLSハンドシェイクと呼ばれる処理が行われます。

流れを単純化すると以下のような感じです。

1. ブラウザがサーバーに接続する
2. サーバーが証明書を提示する
3. ブラウザが証明書を検証する
4. 鍵交換を行い、通信に利用する共通鍵を生成する
5. 以降はその共通鍵を使って暗号化通信を行う

TLS 1.3ではECDHE（楕円曲線Diffie-Hellman鍵共有）が採用されており、通信ごとに一時的な鍵が生成されます。

そのため、同じフリーWi-Fiに攻撃者がいて通信を傍受したとしても、見えるのは暗号化されたパケットだけです。

たとえば、通信内容が以下のようだったとします。

---
text
ログインID: taro
パスワード: password123
---

これはネットワーク上では以下のような暗号文にしか見えません。

---
text
3f8c91a5ab8f4d...
---

さらにTLS 1.3で使われる鍵はセッションごとに異なるため、あとから解析することも現実的ではありません。つまり、「同じカフェのWi-Fiを使っている知らない人にパスワードを盗まれる」という昔ながらの脅威は、HTTPSの普及によってほぼ解決されたと言ってよいでしょう。

HTTPSでも見えている情報とVPNの役割

ここまで説明した通り、HTTPSによって通信内容そのものの盗聴リスクは大きく下がりました。しかし、HTTPSを使っていれば通信に関するすべての情報が隠れるわけではありません。

HTTPSでもメタデータは見える

HTTPSによって通信内容が暗号化される一方で、HTTPSでも隠しきれない情報があります。代表的なのが以下です。

・接続先のIPアドレス
・DNS問い合わせ
・通信量
・通信タイミング

つまり、通信の中身は見えなくても、「どこに」「いつ」「どのくらい」通信したかは推測される可能性があります。

たとえば、あるユーザーが特定の時間帯に動画配信サービスへ大量の通信を行っていれば、動画を見ているのだろうと推測できます。また、特定の企業の管理画面やSaaSへ頻繁に接続していれば、この会社の関係者かもしれないと推測されることもあります。

VPNが必要になるケース

ここでVPNの役割が出てきます。HTTPSが守るのはブラウザとWebサーバー間の通信内容ですが、VPNが主に守るのは、自分がどこへ接続しているかというメタデータです。

VPNを使うと、Wi-Fi運営者から見ると通信先はVPNサーバーになります。その先でどのWebサイトにアクセスしているかは、少なくともローカルのWi-Fi運営者からは見えなくなります。

逆に言えば、HTTPSで保護された一般的なWebサービスを使うだけであれば、VPNがなければ即危険というわけではありません。重要なのは、「VPNを使えば安全」「VPNを使わなければ危険」と単純化しないことです。

現代のフリーWi-Fi最大の脅威「Evil Twin」

では、現代のフリーWi-Fiで本当に警戒すべき脅威は何でしょうか。その代表例が Evil Twinです。

Evil Twinとは

Evil Twinとは、正規のWi-Fiアクセスポイントに見せかけた偽アクセスポイントのことです。たとえばカフェの正規Wi-Fi名が、以下だったとします。

---
text
Cafe_Free_WiFi
---

攻撃者が近くで以下のような同じ名前もしくは似た名前のアクセスポイントを用意すると、利用者は正規のWi-Fiだと思って接続してしまう可能性があります。

---
text
Cafe_Free_WiFi
Cafe_Free_WiFi_5G
Cafe_Free_WiFi_Guest
---

接続後、攻撃者は偽のログイン画面や認証ページを表示します。そのサイトでユーザーは本物だと思って認証情報を入力してしまうかもしれません。Evil Twinはユーザーを偽の入口に誘導し、認証情報を入力させるフィッシング攻撃です。

HTTPSは通信相手との通信を保護する技術ですが、ユーザー自身が偽サイトを本物だと思って認証情報を入力してしまった場合は防げません。

この問題に対する有効な対策の一つがパスキーです。

パスキーはEvil Twinをどう解決するのか

パスキーは、FIDO2/WebAuthnをベースにした新しい認証方式です。

従来のパスワード認証では、ユーザーが秘密情報であるパスワードをサーバーへ送信していました。一方、パスキーでは秘密鍵をデバイス側に保持し、サーバーには公開鍵だけを登録します。

ログイン時には、サーバーから送られたチャレンジに対して、デバイス内の秘密鍵で署名します。サーバーは登録済みの公開鍵で署名を検証し、正しいユーザーかどうかを判断します。つまり、パスワードのように「入力して送る秘密情報」が存在しません。

パスキーはなぜフィッシングに強いのか

パスキーの最大の特徴は、認証情報がドメイン（正確にはオリジン）に紐付いていることです。たとえば `example.com` で登録したパスキーは、原則として `example.com` でしか利用できません。

そのため、攻撃者が `examp1e.com` や `example-login.com` のような偽サイトを作ったとしても、ブラウザやOSは別のサイトとして扱います。本物サイト用のパスキーは偽サイトでは利用できません。

これはパスワード認証との大きな違いです。パスワードは偽サイトに入力してしまえば漏洩しますが、パスキーはブラウザやデバイスが認証先のドメインを検証するため、偽サイトでは認証そのものが成立しません。

つまりパスキーは、ユーザーが偽サイトを見抜けるかどうかに依存せず、ブラウザとデバイスの仕組みによってフィッシングを防ぐ認証方式なのです。

これは、Evil Twinのような人を騙す攻撃に対して非常に有効です。

まとめ

かつてフリーWi-Fiの最大の脅威は通信の盗聴でした。しかし、HTTPSとTLSの普及によって、そのリスクは大きく低下しています。

現代のWebセキュリティは、「どこから接続するか（ネットワークの安全性）」だけでなく、「どうやって認証するか（パスキーなどのアイデンティティ重視）」へとシフトしています。フリーWi-Fiを過剰に恐れる必要はありませんが、認証情報の保護には最新の技術アプローチが必要です。

GIGでは、今回ご紹介したようなセキュリティのトレンドを正しく捉えたWebシステム・アプリケーション開発を行っています。「自社サービスのセキュリティを高めたい」「最新技術を取り入れた開発を行いたい」という企業様は、ぜひGIGにご相談ください。また、こうしたモダンな技術に挑戦したいエンジニアの応募もお待ちしています！

株式会社GIGは、コーポレートサイト・採用サイト・ステークホルダー向けサイトのリニューアルや、企業理解を踏まえた情報設計、サイトリリース後の運用伴走支援がそろったデジタルコミュニケーション企業です。

・制作実績1,500社以上
・サービス利用継続率98%以上
・「Web制作会社」Google検索 1位獲得率55.8％
・AWS公式Technology Partner認定
・ASPICクラウドアワード先進技術賞受賞

ブランド表現と更新しやすさを両立したサイト設計と、公開後も改善し続ける伴走支援が強みです。

株式会社GIGは、お客様と丁寧で密なコミュニケーションを重ねてきたと自負しております。「まず話だけでも」という段階でも、ぜひお問合せ（https://giginc.co.jp/contact）ください。専任の担当者が、お客様の状況にあわせた最適な提案をいたします。

■株式会社GIG
・お問い合わせはこちら
https://giginc.co.jp/contact
・制作実績はこちら
https://giginc.co.jp/works
・事例インタビューはこちら
https://giginc.co.jp/blog/casestudy
・求人応募はこちら（GIG採用サイト）
https://recruit.giginc.co.jp/
・求人応募はこちら（Wantedly）　
https://www.wantedly.com/companies/giginc

さかな

Development事業部フロントエンドエンジニア。東北大学文学部で心理学を学びながらカナダ・モントリオールに3年間居住。帰国後コーディングを独学し、GIGにジョイン。現在はサイト制作のフロント実装や自社サービスLeadGridの開発を行う。最近はAIやインフラに興味がある。