EAP-TLS 與 PEAP：安全性、數位憑證與適用性比較
Published
關於 eap tls vs peap 最常見的建議既乾淨俐落卻又是錯的。選擇 EAP-TLS 是因為它「更安全」，並將 PEAP 留給尚未跟上腳步的團隊。這忽略了決定多據點 WLAN 是否能在星期一正常運作的關鍵問題：您是否能為預期使用的每台裝置發放、更新和撤銷憑證？
{ "block_1": "\n我不會在整個環境中僅採用單一方法。EAP-TLS 適用於您可以進行註冊與更新的裝置。PEAP（幾乎總是搭配內部 EAP-MSCHAPv2）則適用於已存在目錄密碼且無法進行憑證註冊的情境。安全性較高的方法並不總是您能順利運作的方法。飯店後勤辦公室中過期的憑證會將員工鎖在系統外，即使他們的帳號依然有效。而跳過伺服器檢查的 PEAP 設定檔，則可能將目錄密碼暴露給偽造的存取點。這兩種失敗都屬於維運層面的問題。請根據使用者群組指派適當的方法，而不是盲目尋求全域通用的最佳解。
", "block_15": "\n維運上的權衡非常明確：EAP-TLS 需要用戶端憑證、更新機制與復原途徑，而 PEAP 則需要伺服器憑證與謹慎的 Supplicant 設定。請將 EAP-TLS 指派給已註冊的員工與特權裝置；將 PEAP 留給無法加入憑證管理的未管理端點。運作 會員平台無伺服器架構 的團隊可能會劃分不同的會員、員工與裝置群組，但託管模型並不會決定驗證方法。憑證類型必須配合您所能管理的對象。
", "block_63": "\n一篇關於 無線驗證延遲的 ACM 論文 指出，效能主要取決於交握次數、漫遊、憑證驗證以及後端延遲，而非方法名稱本身。標準的 EAP-TLS 會在 TLS 交換過程中完成用戶端與伺服器的憑證驗證。PEAP 則是先建立 TLS 隧道，接著執行內部驗證，從而增加了額外的階段。該論文中引用的 Cisco 技術資料指出，搭配內部 EAP-TLS 的 PEAP 會涉及兩次 TLS 交握，當漫遊期間發生完整重新驗證時，速度可能會變慢。
", "block_83": "\n我們可以在每個據點將此規劃拆分為三個網路。訪客使用 Captive Portal，若據點設有 PMS，則包含房號核對功能。員工使用 EAP-TLS 或 Passpoint。物聯網裝置則使用單一裝置金鑰。Cloud RADIUS 會根據身分將每台裝置導向正確的網路與 VLAN，並拒絕已停用帳號的離職員工。淘汰共用員工密碼的轉移路徑，與我們關於 將多據點員工 WiFi 轉移至 802.1X 的指南中所述相同。
", "block_34": "\n攻擊者透過偽造隧道取得擷取到的 MS-CHAPv2 回應後，可以進行離線破解。驗證隧道安全性是關鍵控制措施；若設定檔接受了不受信任的伺服器，內部方法也無法救回安全性。相同的密碼風險不限於 WiFi。關於 澳洲小型企業外洩憑證 的報告強調了為何重複使用的目錄密碼對攻擊者而言依然極具價值。
" }目錄
EAP-TLS 與 PEAP 完整比較
EAP-TLS 與 PEAP 之間的實際差異，在於每個端點所能支援的憑證類型，以及維持其可用性所需的作業。對於您可以註冊與更新的裝置，請使用 EAP-TLS。若使用者已有目錄密碼且憑證註冊並不實用，請使用 PEAP。沒有任何一種方法是適用於所有使用者群體的唯一標準答案。
| 評估標準 | EAP-TLS | PEAP |
|---|---|---|
| EAP 類型 ID | 13 | 26 |
| 用戶端憑證 | X.509 用戶端憑證 | 使用者名稱與密碼，通常為 EAP-MSCHAPv2 或 EAP-GTC |
| 伺服器憑證 | RADIUS 伺服器憑證 | 外層 TLS 隧道上的 RADIUS 伺服器憑證 |
| 雙向驗證 | 用戶端與伺服器憑證 | 伺服器憑證加上內層使用者或裝置驗證 |
| 網路傳輸中的密碼 | 無 | 有，位於 TLS 隧道內部 |
| 若用戶端略過伺服器檢查，流氓 AP 可竊取的內容 | 無類似密碼的資料；驗證失敗即關閉連接 | 目錄密碼 |
| 單一裝置的撤銷處理 | 撤銷或讓該憑證過期 | 停用帳戶或重設可能重複使用的密碼 |
| PKI 工作量 | 伺服器與用戶端憑證、更新與復原 | 僅需伺服器憑證 |
| 最佳首選情境 | 受 MDM 管理的員工與特權裝置 | 無法註冊憑證的未受管理端點 |
一篇 2025 年 Authentik 技術文章 指出 EAP-TLS 的 EAP 類型 ID 為 13，而 PEAP 為類型 ID 26。這些 ID 向 RADIUS 與 supplicant 識別具體方法，但不會決定哪些人員或裝置應該使用它們。
這些欄位實際上改變了什麼
用戶端憑證決定了營運邊界。EAP-TLS 出示 X.509 用戶端憑證。PEAP 使用使用者名稱與密碼，通常透過 EAP-MSCHAPv2 或 EAP-GTC。這使得憑證註冊與更新成為決定性的工作負擔，而非理論上的方法排名。
信任檢查也有所不同。EAP-TLS 會同時對用戶端和伺服器憑證進行驗證。PEAP 則會在外部 TLS 隧道上驗證 RADIUS 伺服器憑證，接著使用內部方法對使用者或裝置進行身份驗證。
密碼暴露風險取決於 supplicant 設定。EAP-TLS 在傳輸時不包含密碼。PEAP 會在其通道內傳送密碼，因此若用戶端跳過伺服器檢查，可能會向偽造的存取點洩漏目錄密碼。使用 EAP-TLS 時，缺少或不受信任的用戶端憑證會直接導致驗證失敗。
離職處理也取決於受控對象。您可以撤銷裝置憑證或任其過期，而無需重設該員工的目錄密碼。停用帳戶或變更重複使用的密碼，可能會影響綁定該憑證的其他登入。
維運上的權衡非常明確：EAP-TLS 需要用戶端憑證、更新機制與復原途徑，而 PEAP 則需要伺服器憑證與謹慎的 Supplicant 設定。請將 EAP-TLS 指派給已註冊的員工與特權裝置；將 PEAP 留給無法加入憑證管理的未管理端點。運作 會員平台無伺服器架構 的團隊可能會劃分不同的會員、員工與裝置群組，但託管模型並不會決定驗證方法。憑證類型必須配合您所能管理的對象。
每種方法的驗證方式以及密碼洩漏的位置
EAP-TLS 並非自動適合每位使用者。關鍵決策在於您的團隊是否能為每個使用者群組可靠地簽發、續約和撤銷憑證。PEAP 可以簡化非託管使用者的入網流程，但其密碼安全性取決於正確的 Supplicant 設定。
兩種方法皆使用 802.1X。supplicant 是請求存取的裝置，authenticator 是轉發該請求的存取點或交換器，而 RADIUS 伺服器 則負責接受或拒絕請求。它們共用 EAP 架構，而非共用憑證。
IETF EAP 規格索引 將 IETF RFC 5216 所定義的 EAP-TLS 描述為基於憑證的用戶端與伺服器驗證，具備雙向驗證、受完整性保護的加密套件協商以及金鑰衍生功能。該規格於 2008 年 3 月發布。在實際應用中，EAP-TLS 需要透過 PKI 核發的用戶端憑證以及 RADIUS 伺服器憑證。
兩個流程，一個架構
EAP-TLS 在一次 TLS 交換中同時驗證兩個端點：
- 請求者（supplicant）與驗證者啟動 EAP，驗證者將請求轉發至 RADIUS。
- 伺服器與用戶端憑證會在 TLS 交換過程中進行檢查。
- 此交換可保護加密套件交涉並衍生金鑰，無須傳送可能遭網路釣魚、重放或暴力破解的密碼。
- 若缺少或未信任用戶端憑證，即表示裝置會被拒絕。系統無法退回至輸入密碼的方式。
PEAP 會建立一個對伺服器進行驗證的外層 TLS 隧道，然後執行內層方法，通常為 EAP-MSCHAPv2 或 EAP-GTC。由於內層方法可以使用使用者名稱與密碼，因此端點通常不需要用戶端憑證。IETF EAP 規格索引也描述了這些方法所使用的標準架構。
使用者看不到 PEAP 的外層隧道。內部身份（通常是使用者名稱與密碼或權杖）僅在建立 TLS 後傳送。這使 PEAP 對於基於目錄的 Supplicant 來說相當熟悉，但如果用戶端沒有正確驗證隧道，密碼就會暴露。
帶有內部 EAP-TLS 的 PEAP 是更為複雜的特例，它將憑證方法與外部 TLS 隧道相結合。通常標記為 "PEAP" 的部署指的是 PEAP-MSCHAPv2。
Supplicant 決定結果的位置
企業無線 EAP 方法分析說明 解釋了其中的差異：EAP-TLS 使用雙向 X.509 驗證。RADIUS 驗證用戶端憑證，而用戶端驗證伺服器憑證。沒有密碼可用於網路釣魚、重放或暴力破解。該說明還指出，NIST 要求無線工作站和驗證伺服器都必須持有有效憑證。
使用 PEAP 時，用戶端必須驗證 RADIUS 憑證鏈 和 預期伺服器名稱。如果缺少任何一項檢查，偽冒的存取點就可以索取目錄密碼。設定為「不驗證」的 Supplicant 設定檔無法保護密碼。
實用規則：請在 WiFi 設定檔中固定 RADIUS 伺服器名稱與發行 CA。如果沒有這些檢查，PEAP 可能會向流氓伺服器提供密碼。
攻擊者透過偽造隧道取得擷取到的 MS-CHAPv2 回應後，可以進行離線破解。驗證隧道安全性是關鍵控制措施；若設定檔接受了不受信任的伺服器，內部方法也無法救回安全性。相同的密碼風險不限於 WiFi。關於 澳洲小型企業外洩憑證 的報告強調了為何重複使用的目錄密碼對攻擊者而言依然極具價值。
將 EAP-TLS 指派給您能夠維運其憑證生命週期的受控管裝置和使用者。在使用者或裝置無法穩定接收和更新憑證的情況下使用 PEAP，但須透過 supplicant 設定檔強制執行伺服器名稱和 CA 驗證。營運上的權衡非常直接：憑證需要註冊與復原工作，而密碼則會讓您需要管理重複使用與帳號變更。更好的方法取決於您能管理哪些對象，而不是為每個 SSID 宣佈單一贏家。
推廣前的憑證需求
在首次正式上線前，請先在實驗室環境中確認這六個項目。缺少憑證鏈或名稱錯誤看起來會像 "WiFi 斷開"，而非憑證錯誤。
- RADIUS 伺服器憑證。由您的私有 CA 發行。將請求者 (supplicant) 設定檔釘選的名稱放在主體或 SAN 中。設定伺服器驗證用途，並隨憑證提供完整的中間信任鏈。使用會簽署任何符合名稱的公開 CA 對內部 RADIUS 名稱而言是錯誤的信任模型。
- 用戶端憑證。每個裝置或使用者一張，具備用戶端驗證用途。在 SAN 中放唯一的識別資料，例如使用者主體名稱 (UPN) 或裝置序號。當平台支援時，請將私鑰儲存在 TPM 或安全圍域 (secure enclave) 中。
- 信任錨點。透過 MDM 設定檔安裝內部根 CA 或發行 CA。不要將裝置指向公開根 CA 並期望名稱檢查就足夠。
- 效期與續約。發佈伺服器憑證與用戶端憑證的效期。建立重疊的時間視窗，以便在舊憑證到期前安裝替代憑證。
- 撤銷。為 RADIUS 伺服器提供其可存取的 CRL 或 OCSP 端點。以書面方式決定當該端點離線時驗證是失敗還是繼續進行。測試離線狀況，不要在 WAN 發生瞬斷時才發現問題。
- 註冊管道。透過 MDM 使用 SCEP 或 PKCS#12 交付憑證。在將目標推廣至群組之前，先在一台裝置上驗證此流程 (包含續約)。
假設某個診所站點使用 Okta 管理員工身份，並使用 Intune 管理筆記型電腦。設定檔中的 RADIUS 名稱必須與憑證相符，且應該分配至臨床 VLAN 的 Okta 群組必須與 MDM 用于註冊的群組一致。我們關於 Okta WiFi authentication 的說明檔案詳細介紹了身份交接流程，而不會將實驗室變成需要密碼的 SSID。
在進入實際部署區域前，請先連線一台測試筆記型電腦，撤銷其憑證，並確認下一次關聯失敗。
憑證生命週期與推廣工作量
當憑證過期或用戶端無法取得撤銷資訊時，即使使用者帳號完全有效，EAP-TLS 的安全性也會演變成服務中斷。這才是值得思考的問題。「憑證比較難管理」並不能算是一個架構設計理由。
NIST Special Publication 800-120 也提出了相同的風險。EAP-TLS 需要可靠的核發、分發、更新、信任鏈管理與撤銷檢查。憑證已過期或撤銷服務無法連線的裝置，即使使用者的身分依然有效，也可能失去網路存取權限。PEAP 通常在外部 TLS 階段驗證伺服器，並透過內部方法（例如 MS-CHAPv2）驗證使用者名稱與密碼，因此跳過了該用戶端生命週期管理。第一天雖然較為輕鬆，但負擔會轉移到密碼重置與錯誤設定檔的處理上。
防止憑證成為服務中斷的原因
設計上的應對方案是自動化，而不是撰寫更長的作業手冊。
- 透過 MDM 註冊。 一併推播設定檔、信任錨點與憑證。手動 WiFi 設定容易導致伺服器名稱檢查被取消勾選。
- 重疊更新時間。 在舊憑證到期前安裝新憑證。如果每台筆記型電腦在週末同時無法連線，代表重疊時間過短。
- 測試離線撤銷。 瞭解當無法擷取 CRL 或 OCSP 時，RADIUS 是會選擇失敗關閉（fail closed）還是失敗開放（fail open）。
- 保留復原途徑。 發生故障的端點需要一種復原機制，而非「借用別人的 PEAP 密碼」。使用有線技術支援連接埠或範圍嚴格限制的復原 SSID，遠勝於寫在白板上的共用金鑰。
Purple Access 透過 SCEP 接收來自 Microsoft Intune、Jamf Pro、JumpCloud、Kandji、Hexnode、Iru 和 Addigy 的 EAP-TLS 憑證，組織只需進行一次五到十分鐘的設定，而非針對每台裝置重複操作。安全網路採用無密碼和基於憑證的架構，未通過合規性評估（posture）的裝置將透過 Conditional Access 在驗證時被拒絕。這是受合規性限制的連線，而不是第二次密碼提示。
當 PKI 尚未成熟、外包廠商無法納入 MDM，或是混合 BYOD 環境無法接受憑證時，PEAP 仍是簡單直接的選擇。醫療保健、教育、餐飲旅宿業和其他多據點場域通常會同時面臨這三項挑戰。請對受控管的公司、員工及高風險裝置使用 EAP-TLS。為非受控管或臨時終端裝置保留嚴格控制的替代方案。場域規模的身分識別才是關鍵決策，而不是「TLS 擊敗密碼」這種口號。
如果 RADIUS 本身是脆弱的一環，託管式後端可消除「總部機房只有一台伺服器」的單點故障風險。在您歸咎於 EAP 方法之前，可以參考我們關於 RADIUS-as-a-Service 的文章，以檢查連線能力與備援機制。
下方簡短的示範展示了憑證註冊與密碼內部方法的對比，這也是求助桌在續約過期時常見的差異情況。
撤銷漫遊速度與用戶端支援
支援度與速度屬於查詢性質的問題。現行的 Windows、macOS、iOS、Android 與 ChromeOS 請求者 (supplicant) 皆支援這兩種方法。兩者的差異在於失敗時的運作模式。
當設定檔、簽發 CA 或有效日期錯誤時，EAP-TLS 會失敗。當內層方法、身份格式或伺服器名稱檢查與 RADIUS 策略不符時，PEAP 會失敗。這兩種失敗都不代表存取點「不支援企業級功能」。
撤銷機制也有類似的差異。撤銷單一裝置憑證只會阻斷該台筆電，不會影響該使用者的其他登入資訊。重設目錄密碼則會波及每一個仍在使用該密碼的非受控用戶端。即時且針對特定裝置的切斷能力是 EAP-TLS 的優勢，而憑證過期導致的硬性斷線則是需要承擔的代價。
著重握手協定，而非品牌名稱
一篇關於 無線驗證延遲的 ACM 論文 指出，效能主要取決於交握次數、漫遊、憑證驗證以及後端延遲，而非方法名稱本身。標準的 EAP-TLS 會在 TLS 交換過程中完成用戶端與伺服器的憑證驗證。PEAP 則是先建立 TLS 隧道，接著執行內部驗證，從而增加了額外的階段。該論文中引用的 Cisco 技術資料指出，搭配內部 EAP-TLS 的 PEAP 會涉及兩次 TLS 交握，當漫遊期間發生完整重新驗證時，速度可能會變慢。
請分別測量這些項目。不要只憑單一平均登入時間就判定何者勝出。
- 第 95 百分位的關聯至 IP 時間
- 完整驗證與漫遊復原延遲
- RADIUS 往返時間
- 身份驗證失敗率
- 憑證續約失敗
連線階段復原（session resumption）、PMK 快取或 802.11r、本機 RADIUS 可達性，以及較短的憑證鏈，對這些數據的影響遠大於更換加密套件。PEAP 在第一天可能看起來很簡單，但仍可能因重複的密碼交換和使用者修復而產生延遲。EAP-TLS 在註冊後可能感覺是即時連線，但之後可能會因憑證過期而嚴重失敗。
| 症狀 | 較可能採用的方法 | 常見原因 | 實用修復方案 |
|---|---|---|---|
| 在未知的 AP 附近重複出現密碼輸入提示 | PEAP | 用戶端（Supplicant）未驗證伺服器名稱或信任鏈 | 推播固定 RADIUS 名稱與憑證授權單位（CA）的設定檔 |
| 角色變更後，單一筆記型電腦無法連線 | EAP-TLS | 憑證已被撤銷或裝置已從 MDM 移除 | 確認撤銷狀態並僅重新註冊該裝置 |
| 週一整個團隊皆被鎖定無法連線 | EAP-TLS | 憑證同時到期或更新重疊時間過短 | 在到期前分階段更新，並保留復原途徑 |
| 僅在完全重新驗證時漫遊感覺緩慢 | 採用內部 EAP-TLS 的 PEAP | 進行了兩次 TLS 握手 | 優先使用快速恢復、PMK 快取或 802.11r；除非必要，否則避免使用內部 EAP-TLS |
| 僅在單一據點出現隨機拒絕連線 | 兩者皆有可能 | RADIUS 往返時間或信任鏈擷取延遲，而非 EAP 名稱問題 | 在變更方法前，先測量 RTT 與第 95 百分位的關聯至 IP 時間 |
單一場地的漫遊速度緩慢，通常是 RADIUS 距離過遠或憑證鏈擷取延遲，並不能證明您選錯了 EAP 類型。
指派每個群組並證明分流結果
同一棟大樓可能包含員工筆記型電腦、會議室訪客、承包商 Mac 和收銀機。他們不應共用相同的憑證類型。請針對每個使用者群組進行規劃，在您既有的網路旁試行一個據點，並在複製此設計前評估工單與身份驗證記錄。
| 族群 | 建議使用 | 請勿使用 | 原因 |
|---|---|---|---|
| 經 MDM 管理的員工與特權使用者 | WPA-Enterprise SSID 上的 EAP-TLS | 共用 PSK 或 PEAP | 憑證身分識別、依群組劃分 VLAN，且停用帳戶時即終止存取權限 |
| 短暫停留的訪客與賓客 | 訪客 VLAN 上的 Captive Portal 或 Passpoint | 在服務台進行 PEAP 或 EAP-TLS 註冊 | 無憑證生命週期問題，亦無目錄密碼遭網路釣魚的風險 |
| 未受管理的筆記型電腦與承包商 | 僅限搭配強制伺服器驗證的 PEAP-MSCHAPv2 | 無法註冊或更新憑證時的 EAP-TLS | 密碼已存在，但設定檔必須檢查 RADIUS 憑證 |
| 印表機、電視、收銀機、CCTV 與感測器 | 具備獨立 VLAN 的單一裝置 PSK | EAP-TLS 或共用的 PEAP 密碼 | 這些裝置通常無法儲存憑證，且共用金鑰難以定期輪替 |
| 單一建築內的混合型場域 | 按身分拆分至不同的 VLAN | 所有人共用單一 SSID 與單一驗證方式 | 員工、訪客與物聯網裝置的失敗模式各異，不應共用憑證類型 |
誰繼續使用密碼，以及誰絕不能繼續使用
受控管的工作人員與特權使用者會在 WPA-Enterprise SSID 上使用 EAP-TLS。房務、櫃檯與營運人員可透過 SCEP 使用來自 MDM 的憑證進行驗證，依目錄群組分流至特定 VLAN，並在帳號停用時立即失去存取權限。共用 PSK 或 PEAP 密碼只會讓您想淘汰的舊架構重現。
訪客與來賓會保留在 Captive Portal 或 Passpoint 以及訪客 VLAN 上。請勿在櫃檯註冊憑證，也不要將他們放在 PEAP 上。您無需執行生命週期管理，而且這是您不希望被釣魚的目錄密碼。Passpoint 設定檔可以在下次造訪時自動重新連線，無需開立新工單。
非受控筆電與外包廠商可保留在 PEAP-MSCHAPv2，且僅限於設定檔有強制執行伺服器驗證的情況。如果您無法為其註冊或更新憑證，EAP-TLS 將會導致他們無法連線。如果您無法強制執行伺服器檢查，密碼風險將超過其便利性，他們根本不該出現在員工 SSID 上。
印表機、電視、收銀機、EPOS、CCTV、感測器和門禁控制器會取得單一裝置 PSK 和專屬的 VLAN。這些裝置通常無法儲存憑證。使用共用的 PEAP 密碼會重新引入共用金鑰的問題。PCI DSS v4.0.1 Req 2.3.2 要求當任何知道無線金鑰的人離職時必須變更金鑰，而共用金鑰會使這項要求難以實施。xPSK 才是適合這些設備的方案。客房電視、恆溫器和收銀機應屬於訪客永遠看不到的受金鑰保護 VLAN。
先在單一據點進行驗證
將新設計部署在該場地現有的存取點上，與現有網路並存。根據工單和稽核證據來評估效果，而不是只看展示登入。
需要一個驗證日誌，記錄每一次接受與拒絕的身份、裝置、MDM 註冊狀態、方法、存取點、SSID、站點、VLAN、角色、原因與時間。該日誌本身就是符合 ISO 27001 存取與日誌記錄控制，以及 PCI-DSS 要求 8 與 10 的佐證資料。若沒有 MDM，請先鎖定 PEAP 設定檔，並僅針對受控管的人群排程憑證發放。
我們可以在每個據點將此規劃拆分為三個網路。訪客使用 Portal，若據點設有 PMS，則包含房號核對功能。員工使用 EAP-TLS 或 Passpoint。物聯網裝置則使用單一裝置金鑰。Cloud RADIUS 會根據身分將每台裝置導向正確的網路與 VLAN，並拒絕已停用帳號的離職員工。淘汰共用員工密碼的轉移路徑，與我們關於 將多據點員工 WiFi 轉移至 802.1X 的指南中所述相同。
我會建議先從託管員工 SSID 與收銀機的每台裝置金鑰開始試行，並讓承包商保留在已驗證的 PEAP 設定檔中，直到正式完成註冊。對所有人使用單一方法在圖表中看起來比較整潔，但在實際運作時卻會以三種不同的方式失敗。
Purple Access 在您現有的存取點上運行基於憑證的員工 WiFi，並為物聯網裝置提供單一裝置金鑰，因此 eap tls vs peap 變成了使用者群體選擇問題，而非全域性的賭博。您可以在單一站點上驗證開放式、安全性與 xPSK 網路，並在擴大部署前評估支援單與驗證日誌。請造訪 Purple Access 以規劃您的員工、訪客與裝置網路。
