RadSec：通过 TLS 加密 RADIUS 如何提升 WiFi 认证安全性

RadSec：通过TLS加密RADIUS如何提升WiFi认证安全性 Purple企业WiFi智能简报 大约时长：10分钟 --- [引言与背景 — 约1分钟] 欢迎收听Purple企业WiFi智能系列。我是主持人，今天我们讨论一个正好处于网络安全和运营风险交叉点的话题：RadSec——在RFC 6614中正式定义——以及如果它还未出现在你的基础设施路线图上，为什么应该考虑。 如果你是负责酒店集团、零售园区、体育场或公共部门园区企业WiFi的IT经理、网络架构师或CTO，本次简报就是为你准备的。我们将介绍RadSec究竟是什么，为什么传统RADIUS协议会让你暴露风险，如何在真实环境中部署RadSec，以及那些常让团队陷入困境的陷阱。不为了理论而理论——只为你本季度做出决策所需的信息。 让我们开始。 --- [技术深潜 — 约5分钟] 那么，先来看问题。RADIUS——远程认证拨入用户服务——自20世纪90年代以来一直是企业WiFi认证的基石。当用户或设备连接到你的企业或访客WiFi时，接入点作为RADIUS客户端，将认证请求转发至RADIUS服务器，后者根据你的目录（Active Directory、LDAP或云身份提供商）验证凭证，并决定授予或拒绝访问。这正是支撑WPA2-企业版和WPA3-企业版网络的802.1X认证模型。 问题在于，传统RADIUS是为另一个时代设计的。它运行于UDP——用户数据报协议——端口1812和1813。UDP是无连接的，这意味着没有握手，没有会话状态，而且至关重要的是，没有原生加密。接入点和RADIUS服务器之间唯一的保护是共享密钥——本质上是一个密码——用于在传输过程中通过MD5哈希来混淆用户密码。众所周知，MD5已被加密学破解，多年前就已破解。 这在实践中意味着什么？这意味着在攻击者可以拦截RADIUS流量的任何网络段——包括被攻陷的交换机、管理VLAN上的恶意设备，或者远程接入点与云托管RADIUS服务器之间的任何点——他们都有可能捕获认证交换，尝试对共享密钥发起离线字典攻击，并在某些配置下彻底暴露用户凭证。 对于在所有200家分店运行访客WiFi的酒店集团，或者每家门店都有接入点并通过公共互联网回传至中心RADIUS服务器的零售连锁店，这不是一个理论风险。这是一个活生生的攻击面。 这正是RadSec所解决的。RadSec——定义于RFC 6614并经RFC 7360更新——将RADIUS流量包裹在TLS隧道内。它不使用UDP，而是使用TCP端口2083。它不使用共享密钥和MD5，而是使用基于X.509证书的双向TLS认证。RADIUS客户端和RADIUS服务器都出示证书，验证彼此身份，并在交换任何认证数据之前建立加密会话。TLS 1.3是当前推荐的版本，它提供前向安全性并消除了一系列遗留密码漏洞。 实际效果非常显著。凭证数据、用户属性和会话令牌在接入点（或RadSec代理）与RADIUS服务器之间端到端加密。在线路上拦截流量的攻击者只能看到加密的TLS记录。共享密钥虽然仍为向后兼容而存在，但已不再承担任何有意义的安全工作——TLS承载了这一切。 这里还有一个越来越重要的维度：漫游。用于跨欧洲及其他地区大学和研究机构的Eduroam联邦，多年来一直将RadSec作为其机构间漫游基础设施的一部分。最近，Wi-Fi Alliance的OpenRoaming标准——它支持在参与场所之间无缝进行WiFi漫游——强制要求所有联邦流量使用RadSec。如果你正在部署支持OpenRoaming的基础设施，RadSec不是可选项；它是先决条件。Purple根据Connect许可支持OpenRoaming，在联邦内充当身份提供商，而RadSec是该安全漫游网络运作的核心。 从合规角度看，RadSec对PCI DSS 4.0越来越重要，该标准收紧了关于传输中认证数据保护的要求。如果你的WiFi基础设施涉及支付卡环境——在零售和酒店业中经常如此——传统RADIUS的加密缺口是一个迟早会被发现的发现项。GDPR同样要求采取适当的技术措施保护个人数据；在你的网络中未加密传输的用户凭证和会话元数据，在数据保护审计中将难以辩护。 现在我们谈谈架构。RadSec有两种主要的部署模式。 第一种是在你的RADIUS服务器和接入点上使用原生RadSec支持。FreeRADIUS 3.0及以上版本原生支持RadSec。Microsoft NPS截至目前版本不原生支持RadSec，这对运行以Windows为中心的基础设施的组织来说是一个重大限制。Cisco ISE支持RadSec。Aruba ClearPass支持RadSec。如果你的RADIUS服务器和接入点供应商都原生支持RadSec，这是最简洁的路径——在两端配置TLS证书，在防火墙上打开TCP 2083，你的RADIUS流量就实现了端到端加密。 第二种模式是RadSec代理。这在实践中更为常见，特别是对于拥有传统RADIUS基础设施或混合供应商环境的组织。一个RadSec代理——radsecproxy是部署最广泛的开源实现——位于你的接入点和RADIUS服务器之间。接入点在本地网络上通过UDP向代理发送标准RADIUS。代理终止该连接，将RADIUS流量重新封装在TLS隧道内，并通过TCP 2083将其转发给上游RADIUS服务器。这种方法允许你在不更换RADIUS服务器的前提下为现有基础设施添加RadSec，当你的RADIUS服务器托管在云端或通过公共互联网访问时尤其有用。 证书管理是你需要规划的运营复杂性。你需要一个PKI——公钥基础设施——来颁发和管理用于双向TLS的X.509证书。这意味着一个证书颁发机构，为每个RADIUS客户端和服务器颁发证书，并制定证书到期前的轮换流程。未被注意的证书过期将同时导致网络上所有用户的认证中断——这是你要避免的情况。使用ACME或你的CA的API实现证书自动续期，并在到期日前很久就设置监控警报。 --- [实施建议与陷阱 — 约2分钟] 让我给出一些实用的建议。 第一：部署前先审计。绘制每一个RADIUS客户端——接入点、VPN集中器、执行802.1X的交换机——和环境中每一个RADIUS服务器的地图。了解哪些原生支持RadSec，哪些需要代理。这次审计通常会暴露出根本不支持TLS的过时设备，这些需要纳入你的替换路线图。 第二：从最高风险流量开始。如果你有穿越公共互联网的RADIUS流量——远程站点、云托管RADIUS、多分支酒店集团——这是你的第一优先。在良好分段的管理VLAN上的本地RADIUS流量风险较低，但仍应列入路线图。 第三：上线前全面测试双向TLS。RadSec部署中最常见的故障模式是证书验证错误——通用名称不匹配、中间证书过期，或者客户端不信任签署服务器证书的CA。在切换生产流量前，使用openssl s_client测试TLS握手。 第四：不要忽视监控。RadSec增加了一个传统RADIUS所没有的TCP连接层。TCP连接故障、TLS握手超时和证书错误将对用户表现为认证故障。确保你的RADIUS服务器日志和代理日志都输入到你的SIEM或监控平台，以便你能区分RadSec连接问题和认证策略问题。 我最常见到的陷阱是组织在服务器端部署了RadSec，却忘记更新防火墙规则。TCP 2083需要在每一个RADIUS客户端和RADIUS服务器或代理之间开放。如果你习惯于管理UDP 1812规则，TCP 2083在防火墙变更过程中容易被遗漏。 --- [快速问答 — 约1分钟] 让我快速回答几个我经常听到的问题。 “RadSec是否替代802.1X？”不。RadSec保护接入点和RADIUS服务器之间的传输层。802.1X是客户端设备和接入点之间的认证框架。它们运行在不同层，是互补的。 “所有接入点供应商都支持RadSec吗？”并非普遍支持。Cisco、Aruba、Ruckus和Meraki都有不同程度的RadSec支持——请检查具体固件版本。如果没有原生支持，RadSec代理就是你的解决方案。 “DTLS呢——RADIUS over DTLS？”RFC 7360定义了RADIUS over DTLS，它使用UDP而非TCP，保留了传统RADIUS的一些无连接特性，同时增加了加密。它的部署不如RadSec over TLS广泛，但如果在高吞吐环境中延迟是个问题，值得评估。 “这如何影响漫游性能？”RadSec的TCP连接是持久的，这实际上可以通过减少后续认证请求的连接建立开销，提升联邦环境中的漫游性能。 --- [总结与下一步 — 约1分钟] 总结：RadSec是针对传统RADIUS真正安全缺口的一个成熟、基于标准的答案。如果你在大规模运行企业WiFi——跨多个站点、通过互联网、或者在受PCI DSS或GDPR约束的环境中——问题不是要不要部署RadSec，而是何时以及如何部署。 你的下一步：本周审计你的RADIUS基础设施。识别你最高风险的流量流。检查你的RADIUS服务器和接入点供应商文档的原生RadSec支持情况。如果你运行FreeRADIUS，你可以在一天内启动一个测试性的RadSec部署。如果你使用Microsoft NPS，开始评估代理或向支持RadSec的服务器迁移的路径。 Purple的平台设计用于与企业RADIUS基础设施集成，支持企业和访客WiFi环境的安全认证流。如果你想了解RadSec如何融入你的特定部署，Purple团队可以为你介绍。 感谢聆听。下次再见。 --- 脚本结束