PEAP与TTLS：隧道型EAP的安全妥协

背景：国内企业WiFi网络绝大多数采用PEAP-MSCHAPv2认证方案，厂商宣传文档普遍标注"双向认证"，但实际部署中99%的场景仅完成服务器端验证。这一现象并非技术缺陷，而是设计上的有意妥协。理解其背后的安全代价，是评估企业WiFi风险的第一步。

1. 隧道型EAP的设计逻辑

EAP-TLS（见eap-tls-protocol-enterprise-wireless-authentication）要求客户端和服务端都持有X.509证书，完成真正的双向认证。但对于大型企业的无线网络部署而言，这需要管理数万甚至数十万张客户端证书——证书生命周期管理成本极高。

PEAP（Protected Extensible Authentication Protocol，RFC 5216）和TTLS（Tunneled TLS，RFC 5281）的设计思路是：先建立TLS隧道，在隧道内部进行轻量级认证。客户端无需证书，只需验证服务器的TLS证书；服务器端则通过隧道内部的MSCHAPv2、GTC等协议验证用户凭据。

EAP-PEAP 握手流程：

Step 1: TLS 握手（仅服务器认证）
  Client -> Server: ClientHello
  Server -> Client: ServerHello + Certificate + KeyExchange + ServerHelloDone
  Client -> Server: ClientKeyExchange + ChangeCipherSpec + Finished
  (此处客户端验证服务器证书合法性)

Step 2: 隧道内认证
  Client -> Server: EAP response (MSCHAPv2 challenge/response)
  Server -> Client: EAP request (MSCHAPv2 challenge/response)
  Client -> Server: EAP response (MSCHAPv2 result)
  Server -> Client: EAP success/failure

关键设计点：TLS握手的服务器证书验证由客户端自行决定是否执行。RFC 5216 §3.1 明确说明：

"The PEAP implementation MAY choose to validate the server certificate... This validation is implementation-dependent."

2. MSCHAPv2：一个有历史包袱的认证协议

MSCHAPv2（Microsoft Challenge Handshake Authentication Protocol version 2，RFC 2759）是Windows NT 4.0时代（1996年）设计的挑战-响应协议，使用LAN Manager哈希算法。其核心问题：

更严重的问题是离线字典攻击。如果攻击者捕获了MSCHAPv2挑战-响应交换（即便在TLS隧道内，若TLS实现存在漏洞或客户端跳过证书验证），可以通过NTLM哈希字典攻击还原用户密码。NIST SP 800-97 §5.3明确警告：

"MSCHAPv2 is vulnerable to offline dictionary attacks if the password is not sufficiently complex."

3. 为什么PEAP被广泛采用

既然PEAP+MSCHAPv2存在明显安全风险，为何仍成为企业WiFi的主流选择？

理由一：证书管理成本。EAP-TLS需要为每个用户或设备签发和管理证书，PKI基础设施部署复杂。PEAP只需服务器端证书，客户端只需信任CA——大幅降低运维负担。

理由二：用户习惯。企业IT部门对802.1X/EAP的认知水平参差不齐，许多管理员将PEAP视为"比WPA-PSK安全"的解决方案，却未意识到其安全边界。

理由三：兼容性。几乎所有企业级无线控制器（Aruba、Cisco、Ruckus等）和操作系统（Windows、macOS、iOS、Android）都默认支持PEAP，配置界面往往以"PEAP-MSCHAPv2"作为推荐选项。

理由四：监管合规的误导性。等保2.0（GB/T 22239-2019）和密评要求中提到"应采用双向认证机制"，部分企业将PEAP解释为符合要求的方案——但实际上PEAP并不提供真正的双向认证。

4. 安全风险：三个层次

4.1 中间人攻击（MitM）

当客户端跳过服务器证书验证时，攻击者可以伪造AP，捕获用户凭据。这是最常见的攻击场景：

攻击步骤：
1. 攻击者部署恶意AP（ESSID与合法网络相同）
2. 受害者连接恶意AP
3. 攻击者不验证服务器证书，TLS隧道建立
4. 攻击者记录MSCHAPv2挑战-响应
5. 攻击者离线破解用户密码

实测数据显示，使用GPU加速的John the Ripper配合MSCHAPv2字典，6位数字密码可在数分钟内破解，8位复杂密码平均需数小时。

4.2 降级攻击

某些实现（尤其是移动端）允许"降级"到PEAP-0（早期版本）或PEAP-GTC，这些版本的加密强度更低。攻击者可以强制客户端使用弱认证方法。

4.3 凭据重用

MSCHAPv2的哈希值可以被捕获并重放（尽管有chaining机制，但实现差异可能导致漏洞）。一旦用户密码被破解，攻击者可以使用该凭据访问其他系统。

5. 国密视角：PEAP在国内合规环境中的定位

国密标准体系中，GM/T 0054-2018《信息系统密码应用基本要求》明确要求：

"应采用双向认证的机制实现通信过程中通信双方身份的鉴别。"

对于高安全要求的场景，建议考虑：

• EAP-TLS：基于X.509的双向认证，国际通用方案
• 国密SM2-WLAN方案：部分厂商提供基于SM2的WiFi认证扩展，符合GM/T 0061系列规范（注：GM/T 0061为行业内部规范，尚未纳入公开标准数据库）

6. 何时应该选择PEAP

PEAP+MSCHAPv2并非一无是处。在以下场景中，其风险可接受：

• 服务器端TLS配置符合最新标准（TLS 1.2+，禁用弱cipher suite）
• 客户端强制验证服务器证书（配置策略文件禁止跳过验证）
• 密码策略强制执行复杂度要求
• 定期轮换服务器证书和用户密码

7. 替代方案：从EAP-TLS到国密SM2

如果安全要求高于PEAP+MSCHAPv2，有三种升级路径：

7.1 EAP-TLS（国际通用方案）

使用X.509证书双向认证，安全性最高。推荐场景：高安全要求企业、金融机构、政府机构。

7.2 EAP-TTLS（隧道TLS）

与PEAP类似，但支持更多内部认证方法（PAP、CHAP、MSCHAPv2、GTC）。TTLS的灵活性更高，但安全风险相近——取决于内部认证方法的选择。

7.3 国密SM2-WLAN（相关规范）

部分厂商已提供基于SM2算法的WiFi认证扩展方案，使用SM2替代RSA/ECC，SM3替代SHA，SM4替代AES。这是国内高安全场景的合规方向。

8. 检查清单

评估企业WiFi认证方案时，逐项核对：

• [ ] 认证协议是否为PEAP/TTLS？
• [ ] 如果是，内部认证方法是什么？（MSCHAPv2/GTC/PAP）
• [ ] 服务器端TLS证书是否强制验证？
• [ ] TLS版本是否≥1.2？
• [ ] cipher suite是否禁用RC4/DES/NULL？
• [ ] 密码策略是否要求12位以上复杂度？
• [ ] 是否有日志审计用户登录行为？
• [ ] 服务器证书是否定期轮换（建议1年）？

总结

PEAP+MSCHAPv2是国内企业WiFi的主流选择，其设计初衷是在安全性和易用性之间取得平衡。但这种平衡的本质是安全妥协：用隧道的TLS保护一个已过时的认证协议，且服务器端验证的实现取决于客户端配置。

对于普通企业WiFi，只要严格执行服务器证书验证和强密码策略，PEAP方案的风险可控。但对于金融、政务等高安全要求场景，应升级到EAP-TLS或国密SM2方案。

一句话结论：PEAP的"双向认证"是营销话术，实际部署中往往是单向认证——除非你确认客户端强制验证了服务器证书。

参考资料：

• RFC 3748: The Extensible Authentication Protocol (EAP)
• RFC 5216: Protected EAP (PEAP)
• RFC 5281: Tunneled TLS (TTLS)
• RFC 2759: MSCHAPv2
• NIST SP 800-97: Establishing Wireless robust keying and authentication mechanisms
• GM/T 0054-2018: 信息系统密码应用基本要求
• eap-tls-protocol-enterprise-wireless-authentication