在 WebRTC 领域，TURN 服务器通常作为黑盒组件处理。我们需要它们，但不必定期进行配置。然而，17.7% 的 WebRTC 流量由 TURN 服务器处理。
什么是 TURN 服务器？
TURN 服务器充当具有网络限制的客户端的中继。
好了，我们知道 TURN 服务器的作用了，但 TURN 服务器并不认识客户端。因此，客户端应进行自我验证。怎么做呢？此外，我们还必须保持信息的完整性。TURN 服务器是如何处理的呢？在本文中，我们将尝试回答这些问题，并探索 TURN 验证的新方法。
长期身份验证
长期认证是一种传统的 “登录 “机制。说它传统，是因为用户名和密码在客户端成为用户或凭证有效之前都是持久的。
由于时间较长，重放保护无法通过时间限制来实现。为防止重放攻击，客户端必须完成摘要挑战。
- 客户端首先向服务器发送请求，不包括凭据或完整性检查。
- 服务器通过拒绝请求，并向客户端提供一个域（用于指导用户名和密码的选择）和一个 nonce。nonce 是服务器选择的唯一标记，经过编码后可显示其有效期或与特定客户端身份的关联。
- 然后，客户端重试请求，这次包括用户名、realm 和服务器提供的 nonce。客户端会对整个请求添加基于 HMAC 的信息完整性检查。
- 服务器将计算出的 HMAC 与接收到的值进行比较，从而验证 nonce 和信息完整性。如果计算出的 HMAC 与接收到的值相符，服务器就会验证请求。如果 nonce 不再有效，服务器就会将证书视为 “过期”，并拒绝请求，同时提供一个新的 nonce。
长期验证可能很方便。但是，它需要强大的安全措施来保护静态凭证。使用随机性至少为 128 位的密码，可减轻长期凭据机制对离线攻击的脆弱性。
REST API 身份验证
但长期来看存在多个问题：
- TURN 密码必须保密。
- TURN 密码容易受到离线字典攻击。
- TURN 服务器必须查阅密码数据库来验证客户端。
- TURN 用户名值以明文形式传递。它可以用于流量分析。
IETF草案解决了上述长期认证问题。不幸的是，草案已经过期。然而，这是一个有趣的提议。
该草案定义了一种 HTTP 服务，客户端通过 HTTP 请求获取短暂（有时间限制）的证书。
这意味着：
- 凭证不再是秘密
- 无法通过用户名识别
- 密码是机器生成的，以防止字典攻击
- 响应包含 TURN 服务器位置
摘要
目前可用的 TURN 服务器只支持长期身份验证机制。不过，我们可以看到社区正在体验新的身份验证方法。此外，如果你想了解更多有关 TURN 身份验证或 TURN 的信息，可以访问这些项目：
- Pion TURN：Pion TURN 是一个用于构建 TURN 服务器和客户端的 Go 工具包。
- STUNner：WebRTC 的 Kubernetes 媒体网关。此外，它还实现了用于 TURN 身份验证的 REST API。
- coturn：coturn 是 TURN 和 STUN 服务器的免费开源实现。
作者：Ricsi
本文为原创稿件，版权归作者所有，如需转载，请注明出处：https://www.nxrte.com/jishu/webrtc/29399.html
