素のEAP-TLSは安全とは言えない

プライバシー保護の点では……

無線LANなどの認証プロトコルとしておなじみのEAP-TLS。ID・パスワードを使うEAP-TTLSやPEAPと比べて、より優れたセキュリティを実現できるものとして、二重丸が付けられた比較表などをよく見かけます。ところがこれ、うたい文句通りに受け取ってはいけないものだったりします。

"パスワードレスなんだ～！証明書を使うなら安全だね！" 😇

ま、まて、まて……🫠

以下、このようなお話です。

基本形のEAP-TLSには、認証のセキュリティは高くても、証明書の中身が基地局やハブの事業者にも見えるという、プライバシー保護上の問題がある。
プライバシー保護の観点で、基本形のEAP-TLSは、EAP-TTLSやPEAPに劣る。
EAP-TLSもトンネルで保護してみよう
OSの対応は今後の課題

何が問題なのか？

素のEAP-TLSの何が問題なのかというと、ズバリ、プライバシー保護が不十分です。プライバシー保護も広義のセキュリティに入れるなら、安全とは言えなくなります。

ところでさっきから頭に「素の」と書かれているのはいったい？🤔

WPA2/WPA3 Enterpriseの無線LANでは、ID・パスワード方式のEAP-TTLSやPEAPよりも高いセキュリティが欲しいといった時に、RFC 5216の (基本的な) EAP-TLSが利用されることがあります。処理の大雑把な流れとしては、正規の認証サーバに接続しているかどうかを端末が検証するための「サーバ認証」が行われ、検証結果が正しければ、反対に端末が正規の利用者のものかを検証するための「クライアント認証」が行われるという、双方向認証になっています。

サーバ認証とクライアント認証のそれぞれで、電子証明書を用いた認証が行われます。認証のセキュリティがどうのという議論は、ここでは行いません。

最近問題視されるようになったのは、プライバシー保護です。例えば、公衆無線LANの利用者がどこそこの店のアクセスポイントを使って、その後はどの店に行って、夕方にはよくこの辺に居るからおそらく自宅はこの辺……といった行動情報は、プライバシーに関わるものです。公衆無線LANの事業者には、利用者から同意なくこのような行動解析を行わないことが求められています。

しかし、中にはプライバシー保護がザルの事業者もあるかもしれない(?)ので、利用者側の対策として、端末に「MACアドレスランダム化」などの仕組みが入るようになりました。利用者認証 (または端末認証)のある無線LANでは、IDも利用者の追跡に使えるので、これを保護するための仕組みがEAP-TTLSやPEAPには用意されています。具体的には、端末と認証サーバの間にTLSトンネルを作り、基地局やハブを運用する事業者にはIDを見せないようにします。詳しくは以前の記事を見てください。

hgot07.hatenablog.com

EAP-TLSのどこで情報が漏洩するか

EAP-TTLSやPEAPと違い、(基本形の) EAP-TLSにはトンネルがありません。TLS 1.2の場合、証明書の情報が平文で通信路を流れます。クライアント証明書には利用者を識別するためのIDに相当するSubjectが含まれており、これも平文で流れます。

より具体的には、Serial Number, Issuer, SubjectなどがEAP-Messageに平文で含まれており、基地局やハブの事業者にも見えます。実際の利用者と紐づかないとしても、このように長期間に渡るユニークな固定値は、利用者端末の追跡に悪用される恐れがあります (実際は悪質な事業者とはローミングしないように運用されるのですが)。

マジか？

なんでしたら、RADIUS proxyのところでEAP-Messageを眺めてみましょう。FreeRADIUSなら、radiusd -fxx -l stdout でデバッグメッセージを出して、EAP-Messageを簡単にダンプできます。

アカウントを発行して認証処理を行うIDプロバイダが、自身も基地局を運用する場合は、データがその事業者に閉じているので、問題は生じません。一方、ローミング環境では、データ利用に関する合意がない限り、他の事業者に実IDを秘匿することが推奨されています。

なお、TLS 1.3の0-RTT (Zero Round Trip Time)なら大丈夫という説もありますが、0-RTTはリプレイ攻撃に弱いという別の問題があります。(識者におまかせ)

[2024/2/28追記] RFC 5216 2.1.4にPrivacyの記述がありますが、オプションなので常に利用できるわけではありません。

トンネルで保護してみよう

証明書のやり取りをトンネルで保護すればよいのでは？
(一応、EAP-TLSでTLS 1.3を使えという声もあるのですが、今後の課題)

そう、こんなこともあろうかと、使えそうな手法が用意されています。EAPを考案した人たちの洞察力には恐れ入ります。

EAP-TTLSやPEAPを使う方法があります。

"EAP-TTLSやPEAPって、ID・パスワードを使う方式なんでは？" 🤔

なんと、これも違うんですよね。EAP-TTLSやPEAPでは、端末と認証サーバの間にトンネルを掘った後に、phase2として、PAPやMSCHAPV2などの認証が行われます。実は、サーバ証明書を用いた認証も、このトンネルの中で行うことができます。

参考文献はこちら ↓

learn.microsoft.com

PEAPはMicrosoft独自の方式で、標準化されていないので、使うなら EAP-TTLS の方でしょう。Passpointでも、EAP-TTLS は仕様に盛り込まれていますが、PEAPはありません。

具体的には、EAP-TTLSのトンネルの中でEAP-TLSを実行する方法があります。この方法を何と呼ぶのが適切か分かりませんが、EAP-TTLS/PAP のような表記に習えば、EAP-TTLS/TLS あたりでしょうか。これだと EAP-TTLS or EAP-TLSのように誤解されそうな気もします。

とりあえず、やってみましょう。

こんなEAP-TLS用の eapol_test.conf があったとします (wpa_supplicant.conf でも同様)。EAP-TLSでは identity= のレルムさえ合っていればよく、ユーザIDは匿名で構いません。

network={
        ssid="onin_no_LAN"
        key_mgmt=WPA-EAP
proto=RSN
eap=TLS
        identity="anonymous@example.com"
        domain_suffix_match="idp.example.com"
        client_cert="/etc/wpa_supplicant/XxV1ZaqB.cer"
        private_key="/etc/wpa_supplicant/XxV1ZaqB.key"
        private_key_passwd=""
}

eapol_test -c eapol_test.conf -s testing123 とかすれば、SUCCESSが返ってきます (証明書が検証に通れば！)。

上のファイルを、下のように書き換えます。

network={
        ssid="onin_no_LAN"
        key_mgmt=WPA-EAP
proto=RSN
eap=TTLS
        identity="anonymous@example.com"
        domain_suffix_match="idp.example.com"
domain_suffix_match2="idp.example.com"
      phase2="autheap=TLS"
        client_cert2="/etc/wpa_supplicant/XxV1ZaqB.cer"
        private_key2="/etc/wpa_supplicant/XxV1ZaqB.key"
        private_key2_passwd=""
}

(あっ、"2" ってこういう風に使うんだ……)

これだけです！

認証サーバにFreeRADIUSを使っているなら、サーバ側の変更は不要です。

OSの対応状況

EAP-TTLSのトンネルでEAP-TLSが使えるかどうか、各種OSの対応状況をざっくりと調べてみた結果が以下のとおりです。

Linux, OpenWrt

wpa_supplicant ベースなら、先に書いたとおりで、対応可能です。

Windows

できました 😇

p12形式の証明書ファイルを読み込ませて、まずはEAP-TLSの設定を済ませておきます。その後、設定メニューの「既知のネットワークの管理」で「高度なWi-Fiネットワークプロパティ」を編集して、認証方法をEAP-TTLSに変更します。さらに、「認証にEAPメソッドを選択する」の中でEAP-TLSを選択します。