用于WiFi认证的OCSP与证书吊销

欢迎收听Purple技术简报。我是您的主持人，今天我们将深入探讨企业WiFi网络的一个关键安全机制：OCSP与证书吊销。 如果您是IT经理、网络架构师或管理酒店、零售或公共部门大型部署的首席技术官，您知道基于证书的认证——特别是802.1X上的EAP-TLS——是保障网络访问的黄金标准。但是，当设备被入侵、丢失或员工离职时会发生什么？您如何确保被吊销的证书立即被您的网络拒绝？ 这正是我们今天要讨论的内容。我们将分解CRL与OCSP之间的区别，解释RADIUS服务器如何检查吊销状态，探讨WiFi环境下OCSP装订的概念，并提供可操作的实施策略。 让我们从基础开始：CRL与OCSP。 当一台设备使用证书连接到您的WiFi时，RADIUS服务器需要验证该证书不仅在数学上有效且未过期，而且它未被证书颁发机构（CA）明确吊销。 历史上，这是使用证书吊销列表（CRL）完成的。CRL正如其名：一个包含每个已吊销证书序列号的大文件。RADIUS服务器定期下载此列表——可能每天一次，或每隔几小时一次。 在现代高密度环境中，CRL的问题有两个：延迟和带宽。如果您有大规模的PKI部署，那个列表会变得极其庞大。下载它消耗带宽，解析它消耗RADIUS服务器上的CPU周期。更糟糕的是，存在一个漏洞窗口。如果一台设备在上午9点被入侵，而您的RADIUS服务器直到中午才拉取新的CRL，那么那台被入侵的设备就有三个小时无限制地访问您的网络。 OCSP应运而生：在线证书状态协议。 OCSP是一种实时、目标查询。RADIUS服务器不会下载一个包含每个已吊销证书的大列表，而是简单地向CA的OCSP响应者询问：“嘿，这个特定的证书序列号现在有效吗？”响应者回复一个签名的消息：“良好”、“已吊销”或“未知”。 这大大减少了RADIUS服务器上的带宽和处理开销。更重要的是，它消除了漏洞窗口。吊销立即得到执行。 那么，这在WiFi认证流程中是如何工作的呢？ 当客户端设备——假设是一台公司笔记本电脑——尝试连接WiFi时，它与无线接入点通信。AP充当认证器，将EAP-TLS消息传递给RADIUS服务器。 笔记本电脑出示其客户端证书。RADIUS服务器根据其受信任的根CA验证加密签名。然后，RADIUS服务器暂停认证过程。它通过网络向客户端证书中嵌入的OCSP响应者URI发出请求。它等待响应。如果响应是“良好”，RADIUS服务器向AP发送Access-Accept消息，笔记本电脑便上线了。如果响应是“已吊销”，它发送Access-Reject。 现在，您可能会想，“这不会增加连接过程的延迟吗？”是的，会增加。每次认证都需要一次外部DNS查找和一次到OCSP响应者的HTTP请求。在一个繁忙的体育场或大型酒店的高峰入住时段，这可能会导致认证超时。 这引出了一个关键概念：OCSP装订。 在Web服务器领域，OCSP装订很常见。Web服务器定期向OCSP响应者查询自己的证书状态，获得一个带时间戳的签名响应，并在TLS握手期间将该响应“装订”到它发送给客户端的证书上。客户端无需查询CA；它只需验证装订响应上CA的签名。 我们能在WiFi中这样做吗？可以，但很复杂。 在EAP-TLS中，RADIUS服务器也会向客户端出示服务器证书，这样客户端就知道它正在与合法的网络通信，而不是一个邪恶孪生AP。RADIUS服务器可以在此处使用OCSP装订。它查询CA获取自己的状态，并将响应装订到EAP-TLS服务器Hello中。这避免了客户端设备必须对RADIUS服务器的证书执行OCSP查找。 然而，装订*客户端*的证书状态则不同。客户端无法装订自己的状态，因为网络尚未信任该客户端。因此，对于客户端证书验证，RADIUS服务器仍需执行传统的OCSP查询。 为了减轻这些查询的延迟，企业RADIUS服务器使用缓存。它们会将“良好”的OCSP响应缓存一段可配置的时间——比如15分钟或一小时。这意味着后续的漫游事件或重连不会触发新的外部查询，从而在安全与性能之间取得平衡。 让我们看一个真实的实施场景。 想象一家大型零售连锁店，拥有数千台销售点设备和企业笔记本电脑，通过EAP-TLS连接。他们正在部署Purple的WiFi平台。他们需要严格的安全性，但又不能让POS设备在认证过程中超时。 以下是推荐的方法： 首先，确保您的CA基础设施健全。您的OCSP响应者必须高度可用，理想情况下位于负载均衡器之后，并在地理上分布。如果您的RADIUS服务器无法访问OCSP响应者，它必须决定是“故障打开”（允许连接）还是“故障关闭”（拒绝连接）。在高安全环境中，您选择故障关闭。但如果您的OCSP响应者宕机，就没有人能连上WiFi。 其次，在您的RADIUS服务器上配置OCSP缓存。30分钟的缓存是一个良好的折衷。它显著减少CA的负载并加快认证速度，同时将吊销窗口保持在一个合理的紧缩范围内。 第三，实施回退机制。配置您的RADIUS服务器首先尝试OCSP。如果OCSP响应者不可达，则回退到本地缓存的CRL。这提供了对CA中断的弹性。 最后，考虑证书过期的影响。过期不是吊销。证书只是达到了其“不晚于”日期。您的RADIUS服务器将自动拒绝它，无需检查OCSP或CRL。这里的运营挑战是生命周期管理——确保证书在过期*之前*被续期并部署到设备上。 接下来，我们进入基于常见客户问题的快速问答。 问题1：“我们使用基于云的MDM来推送证书。我们还需要OCSP吗？” 回答：当然需要。您的MDM颁发证书，但RADIUS服务器执行网络访问。如果您在MDM中擦除一台设备，MDM告诉CA吊销该证书。但在RADIUS服务器通过OCSP检查该吊销状态之前，该设备仍然可以连接到WiFi。 问题2：“如果我们吊销证书时设备处于离线状态，会发生什么？” 回答：设备是否离线无关紧要。吊销发生在CA级别。下次该设备尝试连接WiFi时，RADIUS服务器将检查OCSP，看到“已吊销”状态，并拒绝访问。 问题3：“OCSP流量是否加密？” 回答：历史上，OCSP请求通过明文HTTP发送。这被认为是可接受的，因为响应本身由CA进行了加密签名，防止了篡改。然而，现代实施越来越多地使用HTTPS来保护隐私，防止观察者看到正在检查哪些证书。 总结并概述后续步骤： 证书吊销是安全802.1X部署中不可妥协的组成部分。虽然CRL对于小型网络可以接受，但OCSP对于企业规模至关重要，它提供了实时安全和更低的带宽开销。 对于您的后续步骤： 1. 审计您当前的RADIUS配置。您是否在检查吊销状态？ 2. 如果您正在使用CRL，评估列表的大小和下载频率。 3. 计划向OCSP迁移。确保您的CA基础设施能够处理查询负载，并在您的RADIUS服务器上配置合理的缓存以优化性能。 通过实施强大的OCSP检查，您可确保您的Purple WiFi部署保持安全、合规和高性能，让您对谁——以及什么——可以访问您的网络拥有绝对控制权。 感谢您收听本次Purple技术简报。