不知道读者里面有没有德国足球（以及拜仁慕尼黑）的球迷，如果有，你们肯定对今天推荐的这篇论文的作者单位所在的城市——波鸿和帕德博恩——很熟悉，两座城市的球队都还算在德国有点知名度，当然和足球队比起来，波鸿鲁尔大学和帕德博恩大学在德国的排名说不定更高。那今天我们就要介绍一下德国研究人员针对12个不同的 DTLS 服务器程序的安全现状进行调研的论文 Exploring the Unknown DTLS Universe: Analysis of the DTLS Server Ecosystem on the Internet

TLS 已经是当前网络应用层事实上的标准安全协议了，但是在基于 UDP 的网络传输中，TLS 标准模式并不适用。为了让 UDP 传输也能更加安全，DTLS 便应运而生了。关于 DTLS 最新的 RFC 标准是2022年4月发布的RFC 9147（参见 https://datatracker.ietf.org/doc/html/rfc9147 文档 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3），而历史经验教训告诉我们，在短短的这一年时间，软件实现肯定很难快速跟上标准实现，因此在这其中必然存在安全隐患。

更重要的是，UDP 传输的无连接、无状态特性，导致它天然有如下图所示的一些问题，这些问题在安全应用场景（特别是对数据传输的机密性和完整性有严格要求的场景）中是致命的。

为了对 DTLS 生态的安全进行调研，作者将研究目标集中在服务器上使用的 DTLS 服务软件（一般都是由主流的密码算法库提供支持）。作者首先总结了 DTLS 常见的安全问题和安全威胁，然后针对12款 DTLS 服务软件进行调查（包括代码实现分析和全网扫描），具体的测试内容如下图所示：作者将17项测试集成到了原来只支持 TLS 的开源工具 TLS-Scanner 中，令其支持 DTLS 安全测试，同时也利用了 ZMap 来进行大规模扫描。

https://github.com/tls-attacker/TLS-Scanner

如果你没有耐心读完全文，那就先看一下整个论文的重要结果。

代码实现的问题

在测试中，作者发现 PionDTLS 中存在的 padding oracle 相关漏洞；TinyDTLS 中存在的明文注入漏洞；Scandium、JSSE、wolfSSL 中存在的 DTLS 流量放大攻击（分别对应 CVE-2022-2576、CVE-2023-21835、CVE-2022-34293）；MatrixSSL 中存在的资源消耗攻击（利用 HelloVerifyRequest 请求）；Botan、JSSE、MatrixSSL、PionDTLS 中存在的资源消耗攻击（利用 ClientHello 请求）；MatrixSSL 中存在的内存越界读漏洞（由于收到乱序包导致）。除了这些漏洞之外，TinyDTLS 和 Botan 对重传和分片机制的支持有问题，会导致一些互操作和兼容性问题。更多细节，请看下表：

网络服务的问题

作者通过使用ZMap进行全网扫描，探测到超过60万台服务器支持 DTLS 协议：

这些 DTLS 服务中，常见的（可以被识别的）应用层协议主要是 VPN、WebRTC 用到的 TURN、NAT 用到的 STUN等协议。

作者对这些服务的密码学安全进行了评估，主要借鉴了以前针对 TLS 的一些评估项，结果如下：

作者还测试了一些已知的协议漏洞，结果如下表：

这个全网扫描更为细节的内容，如下表所示：

论文的附录里面还有一些对证书和密码算法的更为细节的调查，如果感兴趣，读者可以自行去查阅。虽然作者没有公开这些测试的站点的具体数据，但是因为这些测试都很具体，我们的读者完全有能力去重新对这些测试进行复现。

论文：https://www.usenix.org/system/files/usenixsecurity23-erinola.pdf
slides：https://www.usenix.org/system/files/sec23_slides_erinola.pdf