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位元 (Suite B) 要求的 EAP 方法，且 PCI DSS 4.0 針對持卡人資料環境以及 NIST SP 800-120 針對高安全性無線部署，均強制要求或強烈推薦使用此方法。

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

EAP-TTLS 的結構

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

EAP-TTLS 在 macOS、Linux、Android 和 iOS 跨平台提供了極佳的支援。唯一需要注意的是 Windows：內建的 Windows 請求者 (supplicant) 原生不支援將 EAP-TTLS 用於無線 802.1X。擁有大量 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 通道將無法防範惡意存取點（Rogue AP）。

最佳實踐

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

對於 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 搞定一切：訪客、員工和物聯網的 WiFi 設計。

同步所有基礎設施的時間

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

故障排除與風險緩釋

未知的 CA 錯誤

如果 RADIUS 記錄顯示「未知的 CA」，則表示用戶端裝置不信任簽發 RADIUS 伺服器憑證的 CA。驗證您的 MDM 設定檔是否包含根 CA 憑證，且用戶端已設定為信任它。在 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 作為唯一允許的驗證方法，要求使用 TLS 1.2 或更高版本並搭配特定的加密套件 (ECDHE 搭配 P-384、AES-256-GCM)，且需要 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 的資源。