原文标题：Exploring the Unknown DTLS Universe: Analysis of the DTLS Server Ecosystem on the Internet
原文作者：Nurullah Erinola, Marcel Maehren, Robert Merget, Juraj Somorovsky, Jörg Schwenk原文链接：https://www.usenix.org/conference/usenixsecurity23/presentation/erinola发表会议：USENIX Security笔记作者：宋坤书@安全学术圈主编：黄诚@安全学术圈
1 研究背景
DTLS协议是为了保护UDP通信设计的，它是基于TLS协议的，因此它继承了TLS的安全漏洞。同时，DTLS协议自身特有的机制（如消息重传、消息分片）也可能引入新的风险。本文围绕（DTLS服务器实现的现状如何？它们是否容易受到已知攻击？它们实现了哪些功能？）和（DTLS服务器部署在可公开访问的互联网上的什么位置，DTLS服务器生态系统的现状如何？服务器存在哪些漏洞？）这两个核心研究问题对DTLS协议的实现安全性展开系统分析。
为了回答第一个问题，本文参考了已知的TLS攻击，并对DTLS的RFC文档进行了分析，以识别DTLS特有的功能与潜在漏洞。他们通过调整开源工具TLS-Attacker和TLS-Scanner来分析DTLS实现，从而对实现DTLS协议功能的各种软件库进行了分析，通过实验评估发现了它们存在的问题。
研究者开展了大规模的DTLS互联网扫描，以研究DTLS在互联网上的部署情况及其生态系统现状，从而回答第二个问题。本文使用ZMap工具，采用三步法来进行扫描，首先对每个端口随机采样217个IPv4地址进行预扫描，然后将每个端口的样本量增加到220个，最后选择响应最多的8个端口进行全IPv4扫描。
2 DTLS协议分析
DTLS协议是为基于UDP的通信设计的TLS变体，它具备TLS的核心结构，即握手阶段与记录层。握手过程中，客户端与服务器协商加密套件、交换密钥并生成对称密钥以加密后续通信，同时加入防DoS机制（如HelloVerifyRequest中的cookie验证）来避免伪造请求攻击。此外，DTLS还支持会话恢复（避免重复公钥操作）、重新协商、协议扩展等，并引入了显式序列号和epoch编号机制以应对UDP中的包乱序传送和丢失的问题。DTLS握手过程如下图：
2.1 DTLS协议缺陷分析
DTLS协议引入了新功能来支持无状态和不可靠传输。本文仔细分析了DTLS的RFC文档和先前已知的TLS漏洞，对DTLS的实现过程中存在的缺陷进行了分析。
无状态Cookie交换：RFC文档中对Cookie生成的规范较为宽松，攻击者可能通过预测Cookie值来跳过交换过程，甚至通过伪造会话ID来诱使服务器跳过Cookie交换，进而触发DoS攻击。此外，发出的Cookie必须是无状态的，如果发送的有状态的Cookie并且需要在本地对其进行存储，那么服务器就可能会被大量伪造IP地址的请求所淹没。
重新协商：DTLS协议中的重新协商功能虽然没有明确提及，但通过“Epoch”概念暗示了其存在。由于缺乏明确规定，关于是否需要执行Cookie交换的问题存在不确定性。如果客户端和服务器对这一点的理解不同，就可能导致互操作性问题，影响协议的正确运行。
重传：DTLS协议必须支持重传以实现客户端与服务器之间的互操作性，但如果服务器错误地重传HelloVerifyRequest，它就需要为每个客户端维持状态信息，这可能会导致其遭遇DoS攻击并耗尽资源。
握手消息分片：DTLS协议要求支持握手消息的分片和对接收的握手消息片段进行处理，但如果服务器允许对初始ClientHello消息进行分片，或者服务器在Cookie验证之前就过早的为每个客户端分配状态，则可能会因内存耗尽而导致DoS漏洞。
密钥状态并行：由于DTLS记录可能会被重新排序，记录可能会在新的Epoch开始后才到达。在一般情况下，建议丢弃来自早期epoch的包，但如果丢包导致问题，可以保留旧epoch的密钥材料以支持包的重新排序。然而，这一做法存在模糊性，如果服务器接受完成握手后来自早期epoch（如epoch 0）的记录，攻击者可能会注入未加密的应用数据，从而引发类似重新协商攻击的安全问题。
3 研究方法
本文在现有开源工具TLS-Attacker和TLS-Scanner的基础上，扩展了对DTLS协议的支持，以对DTLS实现的进行评估并构建首个相关数据集。TLS-Attacker提供了构造和修改TLS/DTLS协议流程的能力，而TLS-Scanner则借助TLS-Attacker的灵活性自动检测服务器支持的功能。为适应大规模扫描，研究人员还使用了TLS-Crawler对任务进行分发与并行处理。
现有的TLS-Attacker中对DTLS支持并不稳定，因此本文研究人员在其中添加了对重传处理、消息分片等功能的支持，并将其集成至TLS-Scanner中，同时根据DTLS特性调整现有测试策略并增加了新的测试项。
3.1 通用(D)TLS测试策略
现有测试策略主要用于评估服务器对(D)TLS协议的协议支持、安全性配置及潜在漏洞的识别，包括支持的协议版本、密码套件、压缩算法和扩展等。通过变换ClientHello报文内容来判断服务器配置，并分析是否仍使用过时或不安全算法。同时收集证书信息以识别自签名、过期或使用弱公钥类型的证书。利用ALPN扩展识别服务器使用的应用协议，并构造相应测试数据验证其应用层行为。最后，执行多种已知漏洞的测试（如Renegotiation、CBC Padding Oracle、Bleichenbacher等），评估服务器是否存在协议级安全问题。
3.2 DTLS专属测试策略
为对DTLS实现的缺陷进行检测，本文新增了四类测试：无状态Cookie交换测试，验证服务器是否正确使用Cookie并避免维护客户端状态；超时与重传测试，检查服务器是否会自动或按请求重传握手消息；握手消息分片测试，评估服务器是否支持UDP数据报中的消息分片，并检测潜在的DoS风险；多密钥状态测试，通过故意打乱epoch的使用顺序检查服务器是否正确处理密钥状态变化。这些测试针对DTLS的协议特性进行设计，以揭示实际部署中的实现缺陷。
4 实验结果
4.1 软件库的评估
本文总结了对十二种开源DTLS实现的评估，包括OpenSSL、LibreSSL、Mbed TLS、GnuTLS等常见库，以及PionDTLS、Scandium和TinyDTLS这些变体库。所有实现都在实验室环境中通过扩展版TLS-Scanner进行评估。测试启用了RSA、DH、ECDH等密钥交换算法，并在可能的情况下，进行PSK密码套件和客户端认证的测试。对于PSK密码套件和客户端认证测试，并未观察到显著的差异。最终，本文基于5种情况对评估结果进行了分析：
Cookie交换：此处漏洞涉及在会话恢复过程中跳过Cookie交换，导致DoS放大攻击和内存耗尽。wolfSSL、Scandium和JSSE可以通过特定的ClientHello消息触发完整握手，从而绕过Cookie交换，使DoS放大攻击成为可能。MatrixSSL存在HelloVerifyRequest重传问题，攻击者可通过发送多个ClientHello消息耗尽服务器内存并进行放大攻击。此外，MatrixSSL会在接收到初始ClientHello后创建客户端状态，易受资源耗尽攻击。
消息重传：此处漏洞涉及多个库的重传问题。MatrixSSL在握手完成后错误地重传ChangeCipherSpec和Finished消息，导致通信失败。Botan和TinyDTLSC不支持重传机制，丢包时会导致连接失败，而TinyDTLSE仅能正确处理接收到的重传但不能发送。OpenSSL和LibreSSL的示例服务器在RSA密钥交换中遇到格式错误的ClientKeyExchange和ChangeCipherSpec时无法正确关闭连接，导致服务器在重试连接时发送错误消息，直到重启才恢复正常。
消息分片：此处漏洞涉及多个库处理分片的方式。Botan、JSSE、MatrixSSL和PionDTLS在未交换cookie时就处理分片的ClientHello消息，这会导致服务器为每个客户端创建状态，从而使攻击者可以通过大量分片触发内存耗尽的DoS攻击。虽然MatrixSSL对ClientHello消息的大小和分片数有限制，减少了攻击的严重性，但JSSE和PionDTLS的漏洞依赖于服务器配置。OpenSSL和LibreSSL也存在类似问题，但可以通过设置无状态cookie交换来缓解。TinyDTLS变体则不支持分片处理。
消息顺序与epoch：此处漏洞涉及多个库对消息顺序和epoch处理的缺陷。TinyDTLSC允许在握手后处理未加密的应用数据，攻击者可以利用此漏洞注入任意数据。Botan也允许在握手过程中处理未加密的Finished消息，但不立即构成漏洞。MatrixSSL会在收到错误顺序的消息时崩溃，导致会话恢复错误。多个库（如Botan、GnuTLS、PionDTLS等）在接收到错序消息时会导致握手延迟或失败，而TinyDTLSC则会中断连接。
加密漏洞：此处漏洞包括PionDTLS存在CBC填充oracle攻击漏洞，可以通过观察填充处理差异提取机密数据。TinyDTLSC存在不安全的重新协商漏洞，容易受到重新协商攻击，且该问题未修复。
所有软件库评估发现的错误和漏洞如下表：
4.2 DTLS生态系统评估
本文利用评估开源库获得的知识，对2022年5月至6月互联网上服务器端DTLS生态系统的状况进行了首次大规模研究。
研究通过ZMap扫描了217个随机IP地址，发现了2343个端口和2403个主机，估算全球约有7870万个DTLS IPv4主机。进一步扫描了8个端口，以确定部署最多DTLS服务器的端口。在评估过程中，部分主机无法完整评估，主要由于服务器未响应或DTLS实现的缺陷。其中，端口443的未评估主机比例最高，达到38.15%，这些主机大多使用OpenConnect VPN协议，需要客户端先通过TLS握手进行身份验证才能切换到DTLS通道，因此这些主机被排除在外。同时，端口12681上的主机因扫描触发服务中断而被排除。8个端口的扫描结果如下：
此外，研究通过ALPN扩展协议和服务器响应确定了服务识别，其中Fortinet的VPN应用程序在端口443、10443和4433上最为常见，而端口12346和12446上的大多数主机运行Viptela。已识别服务的分布如下：
4.2.1 数据收集分析
通过对不同端口的DTLS主机进行分析，发现协议版本、加密套件、椭圆曲线及扩展支持存在明显差异。端口3391几乎只使用DTLS 1.0，而端口12346和12446主要使用DTLS 1.2。Camellia、ARIA、ChaCha20等现代加密套件在部分端口广泛支持，但端口443上仍有13.5%主机接受不加密（NULL）套件，端口1106和3391上则大量使用不安全的旧算法如3DES和RC4。ECDHE是首选密钥交换机制，部分端口强制使用具备前向保密性的套件。常见支持的椭圆曲线为secp256r1、secp384r1和secp521r1，x25519仅在端口3391被广泛支持。除了Heartbeat扩展外，大部分服务器支持的扩展较为一致，然而Heartbeat扩展的支持率仅为5.18%，这可能与OpenSSL的Heartbleed漏洞修复相关。
4.2.2 证书细节
在评估的服务器中，98.55%能够提供证书。其中一些服务器仅支持带有预共享密钥的密码套件，因此它们没有用于身份验证的X.509证书。端口1106上99.75%的服务器使用自签名证书进行身份验证，但由于自签名证书无法通过公钥基础设施验证，因此不能与公共对等体进行通信。几乎所有的服务器使用相同的自签名证书，并错误地支持RC4流密码。大多数证书使用ECDSA公钥和签名，少数证书使用RSA公钥和签名，且过期证书的使用较为普遍。
4.2.3 DTLS专属功能测试
在DTLS特有功能测试中，本文发现它的多个实现存在安全和协议偏差问题。例如，在端口443上，13.5%的服务器未正确验证cookie，容易被用于放大攻击。尽管大部分服务器在建立新会话时会执行cookie交换以防DoS攻击，仍有少数在会话恢复时跳过该过程。大多数服务器支持重传功能，但依赖客户端先进行重传才能响应。部分端口（如3391）上的服务器不支持消息重排序或分片，可能导致连接不稳定。另有约1万台服务器（多为AnchorFree）在握手后发送无法解密的加密数据包，表现出异常实现行为。
4.2.4 DTLS生态系统漏洞分析
DTLS生态系统面临多种协议攻击风险。其中，对ALPACA攻击的防护措施极少，仅有63个主机执行严格的ALPN验证；16.75%的服务器支持3DES和IDEA加密，它们存在遭受Sweet32攻击的风险；约24000台服务器因重复使用临时DH密钥可能受到Raccoon攻击，尤其集中在端口12346和12446上。1124台服务器支持不安全的重新协商，存在协商攻击风险；472台主机存在CBC填充oracle漏洞，但总体影响低于TLS协议；28台主机存在Bleichenbacher攻击风险，可用于恢复RSA加密的预主密钥；11台服务器仍支持DEFLATE压缩，这可能受到CRIME攻击。值得注意的是，DTLS系统中未发现对FREAK、Logjam、GnuTLS会话票据漏洞或无效曲线攻击的易受攻击主机，说明这些攻击在DTLS中已基本被缓解。已测试的攻击和易受攻击的主机数量如下：
5 本文贡献
系统分析了 DTLS 的特有特性，并构建了DTLS实现常见威胁和安全陷阱的威胁目录；
对12个开源DTLS服务器进行了实验室安全评估，发现了11个安全漏洞，包括填充预言、明文插入、内存耗尽DoS攻击、DoS放大攻击以及缓冲区过度读取等；
通过改进的扫描方法进行互联网扫描，并发布了第一个基于520849台主机的综合数据集，占全球可访问DTLS IPv4主机的约0.66%。对该数据集的分析揭示了当前DTLS部署中的漏洞和兼容性等问题。
安全学术圈招募队友-ing
有兴趣加入学术圈的请联系 secdr#qq.com
声明：本文来自安全学术圈，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
