我们默认使用 PEAP 和 MS-CHAPv2 作为内部身份验证。
我担心恶意 AP 会带来安全风险，但一位同事告诉我，预配置的客户端不存在任何风险。
他告诉我，只有未预配置 WiFi 的客户端才会有风险，因为大多数用户会信任假证书。相反，对于预配置的客户端，所有请求者都会断开或拒绝连接，用户将不被允许信任假证书。但为什么会这样呢？可能是因为请求者会检查该 SSID 是否已安装证书？
此外，请求者在这件事上一直都是这么安全吗？还是补丁在一段时间内已经应用过？如果是后者，我怎么知道补丁是在什么时候应用的，以及在哪个操作系统版本中应用的？这会很有帮助，因为例如，我可以建议苹果移动设备只使用 iOS 7 及以上版本（我只是猜测，我不知道这是否是正确的版本）。
答案1
请求者可以通过三种方式验证其正在与合法服务器通信：
- 验证 RADIUS 服务器提供的证书属性是否符合预期。这通常是 CN。
- 验证其信任的 CA 之一与 RADIUS 服务器提供的证书之间是否存在信任关系（请注意，RADIUS 服务器可以发送其他证书来帮助完成此链）。
- 检查服务器是否在握手过程中发送了 OCSP 装订响应。这实际上是服务器代表客户端执行 OCSP 检查并转发响应。
配置文件/配置通常与 SSID 绑定。如果找到与当前 SSID 匹配的配置，则该配置将用于确定要执行哪些检查，并设置预期 CN 和 CA 等的值。
如果这些检查失败，则 TLS 会话将在 EAP 方法的第 2 阶段启动之前被销毁。
如果未找到 SSID 的配置文件/配置，大多数请求者（使用 Win10 和 macOS High Sierra 测试）将提示用户接受所出示的证书，但不会对生成的临时配置文件启用上述任何检查。如果 RADIUS 服务器出示的证书发生变化，请求者将提示用户重新确认他们信任此新证书，但不会明确告知他们证书已更改。如果用户接受新证书，请求者将修改现有的临时配置并启动第 2 阶段。
因此，您的同事的所有说法都是正确的。
至于修补，这是一个很难回答的问题。据我所知，自从它被引入到各种操作系统以来，这种行为一直保持一致，但我不能保证。我知道至少 Win 2K SP4 中 Microsoft 请求者的初始版本表现出上述行为，并且知道 Win 10 也表现出这种行为，但除此之外，我不知道它是否一直保持一致。