エンタープライズWi-Fiの現場に足を踏み入れると、家庭用のルーター選びとは全く異なる空気感が漂っています。パスワードをぽんと入力して繋がるコンシューマー向けの世界とは違い、オフィスや大学キャンパスでは「IEEE 802.1X」という堅牢な認証の壁が待ち構えています。
その中でも、RADIUSサーバーとクライアントの間で最も広く採用されているのが、今回深掘りする PEAP（Protected EAP）-MSCHAPv2 です。
「サーバー証明書だけを検証し、クライアント側は使い慣れたIDとパスワードでログインできる」という手軽さから、多くのインフラエンジニアが最初に導入する鉄板の認証方式ですが、その裏側のハンドシェイクや脆弱性、そして適切なポリシー設定を理解していないと、ある日突然のトラブルシューティングに頭を抱えることになります。
今回は、数々の現場でパケットキャプチャを開き、RADIUSのログと格闘してきたシニアエンジニアの視点から、PEAP-MSCHAPv2のリアルな挙動と実務で役立つ設定の極意を紐解いていきましょう。
—
PEAP-MSCHAPv2の全体像と通信の舞台裏
PEAPは、IETFのRFC（厳密には標準化の途上ですが、実質的なデファクトスタンダード）に基づき、TLS（Transport Layer Security）のトンネル内部でレガシーな認証プロトコルを安全にカプセル化するためのフレームワークです。
なぜこのような回りくどいことをするかといえば、MSCHAPv2単体では通信が平文（あるいは容易に解読可能なハッシュ）で流れてしまい、中間者攻撃（MitM）やパスワードクラックの格好の餌食になるからです。外側に堅牢なTLSのコートを着せ、その中で安全にパスワード認証を行うのがPEAPの基本戦略です。
ハンドシェイクの全体シーケンス
実際の認証プロセスがWi-Fiの空中でどのように展開されているのか、パケットの流れを追ってみましょう。
クライアント ( supplicant ) オーセンティケーター ( AP ) RADIUSサーバー
| | |
| ------ (1) EAPOL-Start ------------> | |
| <----- (2) EAP-Request/Identity ---- | |
| ------ (3) EAP-Response/Identity --> | ------ (4) Access-Request -> |
| | |
| <----- (5) TLS Handshake (Server) -- | <----- (6) Access-Challenge |
| (サーバー証明書提示) | |
| ------ (7) TLS Handshake (Client) -> | ------ (8) Access-Request -> |
| (TLSトンネル確立) | |
| | |
| <--- (9) PEAP/EAP-MSCHAPv2 チャレンジ | <--- (10) Access-Challenge |
| ---- (11) PEAP/EAP-MSCHAPv2 応答 ---> | ---- (12) Access-Request --> |
| | |
| <--- (13) EAP-Success -------------- | <--- (14) Access-Accept --- |1. フェーズ1：EAPトランスポートの確立
クライアントがAPに接続を試みると、APはアイデンティティ（ユーザー名）を要求します。ここで重要なのは、ステップ(3)で送信されるアイデンティティ（外側アイデンティティ）は、必ずしも実際のユーザー名である必要はないという点です。匿名IDを使うことでプライバシーを保護することも可能です。
2. フェーズ2：TLSトンネルの構築
RADIUSサーバーが自身のサーバー証明書をクライアントに提示します（ステップ5）。クライアントは、自身のトラストストア（ルート証明書）を元にサーバーが信頼できるかを検証します。ここでサーバー証明書の検証を甘く設定していると、偽のRADIUSサーバーを立てた中間者攻撃に足元をすくわれることになります。検証が成功すると、暗号化されたTLSトンネルが確立されます（ステップ7）。
3. フェーズ3：内側でのMSCHAPv2認証
確立されたTLSトンネルの内部で、いよいよユーザーのIDとパスワードの検証が行われます（ステップ9〜12）。ここで行われるのが、Microsoft由来のチャレンジ・レスポンス方式であるMSCHAPv2です。
—
MSCHAPv2の仕組みと抱える脆弱性
内部で使われるMSCHAPv2は、歴史的経緯からいくつかの構造的な弱点を抱えています。実務を預かるインフラエンジニアとして、これらのリスクを正しく把握しておく必要があります。
脆弱性の核心：チャレンジ・レスポンスの弱点
MSCHAPv2は、パスワードそのものをネットワーク上に流しません。その代わり、サーバーから送られてきたチャレンジとパスワードから生成したハッシュ値を返します。しかし、このプロトコルには以下の深刻な懸念があります。
- 双方向認証の不完全さ: サーバー側はクライアントのパスワードハッシュを検証しますが、クライアント側はサーバーが「本当に正しいパスワードを知っているか」を完全に検証しているわけではありません（※厳密にはレスポンスに含まれますが、実装上の脆弱性が指摘されてきました）。
- オフライン辞書攻撃への耐性の低さ: キャプチャされたMSCHAPv2のハンドシェイク（チャレンジとレスポンスのペア）を悪意ある第三者が傍受した場合、強力なGPUクラスターを用いてオフラインで総当たり攻撃（ブルートフォース/辞書攻撃）を仕掛けられれば、脆弱なパスワードは数分で解読されてしまいます。
だからこそ、「外側のTLSトンネル（PEAP）」が正しく機能し、第三者がパケットを傍受できない環境を担保することが絶対条件となるのです。
—
現場で役立つ設定例とデバッグの極意
ここからは、実務で遭遇する設定ファイルやコマンドの具体例を見ていきましょう。今回は、Linuxの代表的なRADIUSサーバーであるFreeRADIUSの設定概念と、クライアント側（主にLinux/wpa_supplicantや一般的なモバイル端末）の心構えを解説します。
1. FreeRADIUS側でのPEAP設定スニペット
FreeRADIUSの eap.conf における、PEAPセクションの設定例です。セキュリティを高めるためのパラメータに注目してください。
# /etc/freeradius/3.0/mods-available/eap の抜粋
eap {
default_eap_type = peap
peap {
# 内部で使用する認証方式としてMSCHAPv2を指定
default_inner_type = mschapv2
# クライアント側にサーバー証明書の検証を強制（非常に重要）
require_client_cert = no # PEAPでは通常クライアント証明書は不要（ID/PWのため）
# 使用するTLSのバージョン制限（古い脆弱なプロトコルを排除）
tls = tls-config
}
}
tls-config tls-common {
private_key_file = ${certdir}/server.key
certificate_file = ${certdir}/server.crt
ca_file = ${certdir}/ca.pem
# SSL/TLSの古いバージョンを不許可にし、TLS 1.2以降を強制
cipher_list = "DEFAULT@SECLEVEL=2:HIGH"
disable_tls1 = yes
disable_tls1_1 = yes
}2. クライアント（wpa_supplicant）の設定例
Linux端末やIoTデバイスをエンタープライズWi-Fiに収容する際によく使われる wpa_supplicant.conf の設定です。現場のトラブルシューティングでは、この設定ファイルの不備が原因の大半を占めます。
# /etc/wpa_supplicant/wpa_supplicant.conf
network={
ssid="Enterprise-Secure-WiFi"
scan_ssid=1
key_mgmt=WPA-EAP
# 認証プロトコルとしてIEEE 802.1Xを指定
eap=PEAP
# 実際のRADIUSサーバーに登録されているユーザー名
identity="network-admin@example.com"
# 内側で利用するパスワード
password="SuperSecretPassword123!"
# 内部認証フェーズでMSCHAPv2を指定
phase2="autheap=MSCHAPV2"
# 【最重要】ルート証明書のパスを指定し、サーバー証明書の偽装を防ぐ
ca_cert="/etc/ssl/certs/corporate_ca.pem"
# 証明書の検証時にサーバーのSAN（Subject Alternative Name）やCNをチェック
domain_match="radius.example.com"
}ここで ca_cert を省略したり、デバイス側の設定画面で「証明書の検証をスキップする（安全ではない接続を許可する）」にチェックを入れたりする運用をしていませんか？ これを許容してしまうと、前述した中間者攻撃に対して完全に無防備になってしまいます。
—
トラブルシューティングの現場から：よくある罠
最後に、実際のインフラ運用現場で遭遇しがちなトラブルと、そのデバッグ手法を共有します。
トラブル1：認証が突然失敗し始める（原因不明）
現場でのアプローチ: まず raddebug やFreeRADIUSのフォアグラウンド実行（freeradius -X）でログをリアルタイムに監視します。多くの場合、以下のようなログが出現します。
MS-CHAP-Error: E=691 (Authentication failure)
これは単純なパスワードミス、あるいはActive Directoryなどのバックエンド連携におけるアカウントロックアウトが原因であることがほとんどです。
トラブル2：スマホやPCの一部機種だけが接続できない
現場でのアプローチ: 近年のOS（特にAndroidやiOS、Windows 11の近年のアップデート）では、セキュリティポリシーの強化により、サーバー証明書の検証要件が厳格化されています。
具体的には、オレオレ証明書（自己署名証明書）や、証明書内の Subject Alternative Name (SAN) が適切に設定されていないサーバー証明書を使用している場合、クライアント側が「信頼できない接続」と判断して静かに切断します。
パケットキャプチャ（Wiresharkなど）を空中で取得し、TLSのハンドシェイク中にクライアント側から Alert (Level: Fatal, Description: Bad Certificate) が返されている場合は、サーバー側の証明書チェーンの不備を疑ってください。
—
まとめ：便利さと安全性のバランスを見極める
PEAP-MSCHAPv2は、クライアントに証明書を配布する手間がなく、導入のハードルが低いという圧倒的なメリットを持っています。その一方で、内側で使われるMSCHAPv2の特性や、サーバー証明書の検証を厳格に行う重要性を理解していないと、ネットワークの安全性を大きく損なう諸刃の剣でもあります。
実務においては、以下のポリシーを徹底することがエンジニアとしてのプロフェッショナリズムと言えます。
1. ルート証明書のデバイスへの事前配布・強制: 「検証をスキップする設定」をユーザーに選ばせない仕組みづくり。
2. TLSバージョンの厳格化: 古い暗号スイートやTLS 1.0/1.1の完全排除。
3. 将来への移行を見据える: パスワードベースのPEAP-MSCHAPv2から、証明書認証ベースの EAP-TLS や、よりモダンな認証方式へのステップアップを常に視野に入れておくこと。
ネットワークのパケットは嘘をつきません。挙動がおかしいと感じたら、迷わずログとパケットを広げ、TLSのトンネルの内部と外部で何が起きているのかを冷静に観察していきましょう。あなたのインフラ運用の一助になれば幸いです。
コメント