EAP-TLS 對決 EAP-TTLS：您應該選擇哪種憑證式 WiFi 協定？

執行摘要

為您的 802.1X 部署選擇合適的 EAP 方法，決定了您的企業 WiFi 是真正安全，還是僅在紙面上合規。在 RFC 5216 中定義的 EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) 需要雙向憑證驗證：用戶端裝置與 RADIUS 伺服器雙方都必須在授予網路存取權限之前，出示有效的 X.509 憑證。在整個過程中絕不交換密碼。而在 RFC 5281 中定義的 EAP-TTLS (Tunneled Transport Layer Security) 僅需要伺服器端憑證來建立加密的 TLS 通道，用戶端在此通道內使用現有的目錄認證資料進行驗證。

對於管理零售連鎖店、餐旅場所和公共部門組織基礎設施的 CTO 與網路架構師來說，這個抉擇可以簡化為一個問題：您是否管理這些裝置？如果您透過 MDM 控制裝置群，EAP-TLS 是絕對的首選。如果您支援多樣化的 BYOD 環境，或缺乏健全的公開金鑰基礎建設 (PKI)，EAP-TTLS 則提供了一個務實且高度安全的替代方案。Purple 為超過 80,000 個實體場所的 員工 WiFi 支援這兩種驗證路徑。

技術深度剖析

EAP-TLS 架構

EAP-TLS 在 IEEE 802.1X 架構下運作，採用雙向驗證模型。每次驗證交換都涉及三個核心組件：請求端 (用戶端裝置)、驗證發起端 (無線基地台) 和 驗證伺服器 (RADIUS 伺服器)。基地台本身不做出驗證決定，而是扮演透明中繼的角色，將 EAP 訊息封裝至 RADIUS 封包中，並轉發至驗證伺服器。 EAP-TLS 握手的程式如下。無線基地台發送一個 EAP-Request/Identity 給連線裝置。裝置以其身分識別回應。RADIUS 伺服器以 EAP-TLS/Start 訊息啟動 TLS 握手。用戶端發送 ClientHello，宣告其支援的 TLS 加密套件。RADIUS 伺服器回應 ServerHello、其 X.509 伺服器憑證以及憑證請求。用戶端根據其信任的根憑證授權單位 (CA) 存放區驗證伺服器憑證。如果驗證失敗，握手即告終止 - 從而提供針對惡意無線基地台的防護。接著，用戶端出示其自身的 X.509 憑證。RADIUS 伺服器驗證用戶端憑證，檢查簽章鏈直至信任的根 CA，確認憑證未過期，並檢查憑證撤銷清單 (CRL) 或查詢 OCSP。只有在雙方都滿意的情況下，才會建立 TLS 隧道並授予網路存取權限。

由於不交換密碼，EAP-TLS 可以免受離線字典攻擊、認證資料填充和網路釣魚的威脅。它是唯一符合 WPA3-Enterprise 192-bit (Suite B) 要求的 EAP 方法，並且受到 PCI-DSS 4.0 針對持卡人資料環境以及 NIST SP 800-120 針對高安全性無線部署的強制或強烈推薦。

**EAP-TLS 需要 PKI。**您至少需要一個離線根 CA 和一個線上發行 CA。根 CA 必須與網路隔離 (air-gapped)，因為其私鑰是您整個憑證階層的主信任錨點。發行 CA 處理日常的憑證簽發並發佈 CRL。用戶端憑證是簽發給個別裝置，而非使用者 - 這是一種裝置身分識別模型。這種區別對於 IoT 裝置、共用終端和無介面 (headless) 系統至關重要。

EAP-TTLS 的架構

EAP-TTLS 的設計旨在提供強大的 802.1X 安全性，而無需在每個用戶端裝置上部署憑證的營運負擔。它分為兩個階段進行。在第一階段，RADIUS 伺服器出示其憑證並建立安全的 TLS 隧道。只有伺服器需要憑證。在第二階段，用戶端在該加密隧道內使用內部驗證方法進行授權。常見的內部方法包括 PAP (密碼驗證協定)、CHAP 和 MS-CHAPv2。用戶端發送其使用者名稱和密碼，但由於此交換發生在 TLS 隧道內，因此認證資料在傳輸過程中會被加密，絕不會在空中暴露。

EAP-TTLS 在 macOS、Linux、Android 和 iOS 上提供了極佳的跨平台支援。需要注意的是 Windows：內建的 Windows 懇求端 (supplicant) 預設並不原生支援無線 802.1X 的 EAP-TTLS。擁有大量 Windows 裝置的環境可能需要第三方懇求端，這會增加營運複雜性。對於以 Windows 為主的環境，使用 MS-CHAPv2 的 PEAP 通常是更務實的選擇。

EAP-TTLS 的最大限制在於它並未消除密碼固有的風險。如果使用者選擇了弱密碼，它仍然容易受到離線暴力破解攻擊。如果內部驗證使用 PAP，密碼將在通道內以純文字形式傳送 - 如果您信任您的 RADIUS 基礎架構，這是可以接受的，但這仍然是必須理解的重要信任模式。

逐項對比

實作指南

為託管裝置部署 EAP-TLS

部署 EAP-TLS 需要運作正常的 PKI 與 MDM 平台。在企業規模下，手動安裝憑證是不可行的。您必須使用 SCEP (Simple Certificate Enrolment Protocol) 或 EST (Enrolment over Secure Transport) 將您的 PKI 與 MDM 整合。當企業裝置註冊時，它會自動請求並接收其憑證，無需使用者干預。

在身分識別管理方面，Purple 在 Connect 授權下，為 OpenRoaming 等服務充當免費的身分識別提供者，利用底層憑證和身分識別框架，促進跨不同地點的安全漫遊。

在 RADIUS 方面，請設定您的伺服器，以根據您的內部 CA 驗證用戶端憑證，並檢查 CRL 或使用 OCSP 進行即時撤銷檢查。支援的 RADIUS 平台包括 FreeRADIUS、Microsoft NPS 和 Cisco ISE。Purple 的雲端重疊網路與 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 硬體整合。

在混合環境中部署 EAP-TTLS

對於擁有非託管裝置的環境，EAP-TTLS 是最佳選擇。您只需要在 RADIUS 伺服器上部署受信任的憑證即可。請確保您的 RADIUS 伺服器直接與您的目錄服務（Microsoft Entra ID、Okta 或 Google Workspace）整合，以驗證內部驗證憑證資訊。請設定您透過 MDM 部署的 WiFi 設定檔，以強制針對您特定的受信任 CA 進行伺服器憑證驗證。如果缺少此步驟，TLS 通道將無法防範惡意無線基地台。

最佳做法

在每台用戶端上強制執行伺服器憑證驗證

針對 EAP-TLS 與 EAP-TTLS，最關鍵的設定步驟是在用戶端裝置上強制執行伺服器憑證驗證。如果裝置沒有針對特定的信任 CA 驗證 RADIUS 伺服器的憑證，它就會連線到任何出示任何憑證的伺服器 - 包括惡意存取點。請務必在 MDM 部署的 WiFi 設定檔中指定信任的 CA 和預期的伺服器名稱。這項單一的設定檢查是您今天可以實施的最有效安全性改善措施。

自動化憑證生命週期管理

憑證會過期。如果您沒有自動化的更新程序，當憑證同時過期時，您將面臨大規模的驗證失敗。使用 SCEP 或 EST 來自動化更新，並在過期日之前提早設定監控警報。如果裝置遺失或員工離職，請立即撤銷憑證。設定您的 RADIUS 伺服器以檢查 CRL，或使用 OCSP 進行即時驗證。

依驗證方法對您的網路進行區段劃分

在大規模或分散式的環境中，請考慮在個別的 SSID 上執行這兩種協定。公司託管的裝置在專屬的員工 WiFi SSID 上透過 EAP-TLS 進行驗證。約聘人員與 BYOD 裝置則在具有適當 VLAN 區段劃分的獨立 SSID 上透過 EAP-TTLS 進行驗證。這種模式在 Premier Inn 和 Whitbread 等旅宿集團中很常見，其員工裝置受到管理並獲發憑證，而顧客基礎設施則使用獨立的驗證路徑。如需有關 SSID 架構的更多詳細資訊，請參閱我們的指南 三個 SSID 搞定一切：顧客、員工與 IoT 的 WiFi 設計。

在所有基礎設施上同步時間

憑證驗證依賴準確的系統時間。用戶端裝置或 RADIUS 伺服器上的時鐘偏差會產生「尚未生效」或「已過期」的憑證錯誤，這很難進行診斷。請確保所有基礎設施元件都與可靠的 NTP 伺服器同步。

疑難排解與風險緩解

未知的 CA 錯誤

如果 RADIUS 記錄顯示「未知的 CA」，表示用戶端裝置不信任簽發 RADIUS 伺服器憑證的 CA。請驗證您的 MDM 設定檔是否包含根 CA 憑證，且 supplicant 已設定為信任它。在 CA 輪替或憑證更新後，請重新將更新後的 CA 憑證包推送至所有裝置。

EAP 方法不匹配

如果裝置連線到存取點但驗證失敗，請檢查用戶端上設定的 EAP 方法是否與 RADIUS 伺服器接受的方法相符。設定為 EAP-TLS 的裝置設定檔在僅設定為 PEAP 的 RADIUS 伺服器上將會驗證失敗。

憑證過期導致的大規模失敗

如果大量裝置同時無法進行驗證，請先檢查憑證到期日。這是 EAP-TLS 部署中發生大規模 802.1X 失敗最常見的原因。請實施監控系統，在到期前 60 天、30 天和 7 天發送警示。

RADIUS 用戶端設定錯誤

每個無線基地台或無線控制器都必須定義為 RADIUS 用戶端，並設定正確的 IP 地址和共用金鑰。不匹配會導致驗證逾時，這通常會被錯誤地歸咎於 EAP 方法。請從第一天起就啟用詳細的 RADIUS 記錄。如需進一步的 WiFi 疑難排解指南，請參閱我們的指南 疑難排解公用 WiFi：解決「已連線，無網際網路」和快顯網頁重新導向失敗問題。

合規性與法規接軌

對於 CISO 和網路架構師而言，在 EAP-TLS 和 EAP-TTLS 之間做出選擇時，了解法規環境至關重要。EAP 方法的選擇會直接影響您在多個關鍵框架中的合規狀況。

PCI DSS 4.0（支付卡產業資料安全標準）要求在持卡人資料環境中對無線網路進行強密碼驗證。要求 8.3 規定對 CDE 的所有存取都必須進行多因素驗證，且範圍內的無線網路必須使用強驗證機制。具有憑證型雙向驗證的 EAP-TLS 絕對符合此要求。如果內部驗證得到妥善保護且強制執行伺服器憑證驗證，則使用 MS-CHAPv2 的 EAP-TTLS 是可以接受的，但 EAP-TLS 是更穩健且更易於通過稽核的選擇。 HIPAA（健康保險便利及責任法案）要求受規範實體實施技術保障措施，以保護透過電子通訊網路傳輸的電子受保護健康資訊 (ePHI)。HIPAA 安全規則並未強制規定特定協定，但對於傳輸 ePHI 的無線網路，其對加密和存取控制的預期，在管理醫療裝置群時強烈傾向於使用 EAP-TLS，而在員工裝置上則傾向於使用強制執行伺服器憑證驗證的 EAP-TTLS。

WPA3-Enterprise 192-bit（也稱為 Suite B 或 CNSA 模式）是 Wi-Fi Alliance 的 WPA3 認證中最高安全等級。它規定 EAP-TLS 為唯一允許的驗證方法，要求使用具有特定加密套件（帶有 P-384 的 ECDHE、AES-256-GCM）的 TLS 1.2 或更高版本，並要求使用 ECDSA 或 RSA-3072 憑證。針對政府、國防或關鍵基礎設施應用部署 WPA3-Enterprise 192-bit 的組織必須使用 EAP-TLS。 ISO 27001 並未強制規定特定的協定，但要求組織針對網路資源實施適當的存取控制。部署採用 EAP-TLS 或 EAP-TTLS（並強制執行伺服器憑證驗證）的 802.1X，即可滿足附錄 A.9.1 和 A.13.1 的網路存取控制要求。

投資報酬率與企業影響

遷移至 EAP-TLS 需要對 PKI 和 MDM 整合進行初期投資，但這能消除密碼重設的營運開銷，並降低因憑證遭破解而導致網路入侵的財務風險。對於擁有 400 家門市的零售連鎖店而言，在共用 PSK 網路上單一遭破解的密碼就可能危及整個資產的安全。EAP-TLS 完全消除了該攻擊管道。

對於多租戶環境和交通樞紐，安全驗證可確保只有授權用戶才能存取網路頻寬，從而最佳化基礎設施利用率。透過 RADIUS 憑證屬性進行動態 VLAN 分配，可實現加密強制的網路分段，確保裝置根據憑證屬性放置在正確的網路分段上，而不是依賴 SSID 選擇或 MAC 位址篩選。

Purple 的 WiFi Analytics 平台與這兩種驗證路徑整合，可讓您掌握整個資產中的裝置數量、工作階段持續時間和網路利用率。如需特定產業的部署指南，請瀏覽我們針對 Hospitality、Retail、Healthcare 和 Transport 的資源。