域名系统(DNS)是互联网的基础服务,也是互联网接入的重要入口。域名隐私保护是DNS安全领域的研究热点。本文提出一种基于用户数据报协议的DNS传输中用户隐私保护的加密方法:。该方法利用PKI加密系统与DNS协议集成,不仅解决了域名隐私保护问题,而且与传统DNS系统兼容,保持了DNS系统简单高效的技术特点。
域名系统(name,DNS)是互联网的重要基础服务之一。主要通过域名和互联网协议地址(IP)等互联网基础资源之间的映射和转换,实现互联网上服务器和服务入口的识别和定位。 DNS是一个相对成熟的全球分布式数据库,为互联网提供高效、稳定的互联网身份解析服务。
1983年,DNS架构被提出,随后该架构不断演进和优化。域名系统在设计之初并没有考虑域名协议中完整的安全机制。 1999年,DNS安全扩展协议(name)被提出,可以有效降低中间人攻击的风险,保证DNS传输数据的完整性,从而提高DNS系统的安全服务能力。 2010年,互联网域名根服务开始部署服务,标志着域名服务开始走向安全服务。 DNS也从简单的名称和地址翻译服务发展成为复杂且可信的解析服务。传输层安全协议DANE(命名为DNS-based)是基于该协议通过DNS服务发布数字证书,以确保证书来自特定的证书颁发机构。
随着互联网普及率的不断提高以及对生产生活的不断渗透,人们对互联网的依赖性越来越强。当前的互联网不仅是一种获取和共享信息的方式,而且已经成为大多数传统行业业务系统的基本载体,隐私问题成为互联网上亟待解决的重要问题。 DNS主要采用用户数据报协议(user,UDP)协议明文传输方式进行名称和地址转换。该协议虽然增加了数据篡改的难度,但仍然采用明文的方式提供解析服务。 DNS作为互联网基础服务,在用户隐私保护方面仍然存在漏洞。目前,DNS的安全相关命题很少得到真正解决,隐私问题成为业界关注的焦点并逐渐受到重视。一方面,业界利用查询最小化(query)方法降低隐私被盗风险,利用数据最小化(data)原则减少DNS权威服务对个人隐私信息的收集;另一方面,针对DNS解析服务过程中的隐私泄露问题,国际组织任务组(IETF)于2014年专门成立了DNS(DNS)工作组,讨论制定DNS隐私保护协议,希望利用数据加密传输实现DNS隐私保护。基于此背景,本文提出一种基于UDP的DNS传输中用户隐私保护的加密方法。
研究现状
目前,DNS服务与终端之间的绝大多数数据交换(主要包括请求和反馈)都是以明文且未加密的方式进行,这将导致用户隐私在互联网通信中暴露,其隐私漏洞将被暴露。被黑客利用,例如,黑客可以收集用户访问痕迹(查询时间、访问内容、用户IP地址等)等信息来分析用户习惯。针对这一问题,目前主要有两种方法来保护DNS查询过程中的用户隐私。
DNS数据报文加密
提出了一种基于现有 DNS 架构、在客户端和服务器端交换密钥并提供身份验证和数据加密的方法。服务器的公钥存储在“NS”记录中并发送到客户端,因此使用加密的 DNS 消息不会导致额外的查询延迟。它是一个比较知名的实现,并已广泛部署在服务上,以解决最终用户的隐私保护问题。同样,DNS扩展机制也用于为DNS协议添加加密功能。它提出了一种新的资源记录类型“”来将DNS服务器的公钥传输到客户端。然后客户端使用服务器的公钥来加密 DNS 查询请求,并使用客户端的公钥来加密 DNS 响应,从而加密和保护 DNS 请求和反馈数据。这两种方案虽然可以有效解决DNS明文传输带来的漏洞问题,但是都需要在DNS通信的两端部署安装插件(或者升级解析软件)才能达到DNS通信由明文转为密文的目的,并且推广成本比较高。由于体积较大,目前应用并不广泛。
DNS通信链路加密
TLS(层)是一种为网络通信提供数据机密性和完整性的安全协议。它在传输层加密网络连接。目前,TLS最常见的应用是HTTPS协议,它使用公钥加密来验证网站,并使用对称加密来加密数据传输。 TLS需要TCP协议来保证通道的可靠传输,不能直接用于UDP协议中的数据加密和保护。如果DNS想要使用TLS加密来保护数据,就必须使用TCP协议。然而,目前的情况是大多数DNS查询都使用UDP协议。切换到TCP协议是一个长期的过程,成本巨大。因此,现阶段DNS-over-TLS并不是一个可行的隐私保护解决方案。
DTLS(layer)分组传输层安全协议是在TLS架构上提出的扩展,可以支持UDP协议。 DTLS使得直接加密UDP协议的DNS查询消息成为可能。 IETF草案提出的DNS-over-DTLS详细描述了如何使用DTLS技术来加密DNS消息。
DNS-over-TLS和DNS-over-DTLS使用互联网标准协议TLS和DTLS来实现DNS密文通信。这两种方法都是利用TLS协议来完善DNS,但是这种方法需要在通信之前建立握手、认证等一系列复杂的网络通信。对于访问量巨大、开销相对较小的DNS服务,提出了更高的要求。网络开销和性能要求。
上述两种方式给时延敏感、高吞吐量的互联网基础服务DNS带来了巨大的挑战。
DNS密文通信方式
提出了一种新的DNS加密通信方法(DNS数据),该方法在现有DNS架构和消息格式下使用非对称加密算法进行密文通信。通过DNS查询的方式传输客户端的公钥,以降低基于TLS等方法建立链接的成本,减少查询延迟。同时利用其无状态的特性来提高服务器端的并发性。
消息结构
1) 加密标记位。为了标记DNS消息是否是加密消息,将DNS消息头后的第一个字节定位为加密标志位。对于正常的未加密DNS消息,该字节代表查询域名第一段的长度。根据互联网协议标准(RFC),长度应小于64。该字节被扩展为加密标志位。如果该字节小于64,则表示该DNS消息是未加密的消息。如果大于64,则说明该DNS消息是加密消息。
2) 密钥格式。采用非对称加密方式,通信密钥对(包括公钥和私钥)在DNS终端和DNS服务器上独立生成。 DNS服务器的公钥是通过现有的证书颁发结构()颁发的,使用DNS服务器的客户需要手动配置公钥。 DNS 客户端使用的密钥是在查询超限期间临时生成的。考虑到查询效率等因素,DNS客户端密钥可以在一段时间内重复使用。
客户端的公钥由客户端以EDNS0格式添加在DNS报文的附加段中,并通过DNS查询发送给DNS服务器。具体格式如图1所示。
图1 EDNS0格式传输PKI公钥密钥
密钥的具体内容存储在上述选项数据中。前两个字节是算法标志位,标识密钥使用的加密算法。接下来的两个字节是保留的标识位,最后一部分是具体的公钥数据。具体格式如图2所示。
图2 密钥格式
3) 加密消息格式。加密后的DNS报文的报文头与普通DNS报文一致,报文头后的一字节为加密标志位。标记位后面的两个字节是加密数据的长度,最后一部分是加密数据。具体格式如图3所示。
图3 加密后的DNS报文格式
加密查询方式
使用该方法时,DNS终端需要手动配置DNS服务器的公钥。服务器的公钥可以通过PKI系统进行验证。当DNS终端向DNS服务器发送查询请求时,使用DNS服务器的公钥对所请求的资源记录(RRset)进行加密。将DNS终端的公钥做成RRset,用DNS服务器的公钥加密生成DNS。消息格式数据被传输到DNS服务器。
DNS终端将生成的DNS查询报文按照DNS协议的要求发送给DNS服务器。 DNS服务器将使用自己的私钥解密并恢复需要查询的域名记录和DNS终端的公钥信息,并根据DNS查询逻辑进行搜索查询。然后,使用恢复的DNS终端公钥对查询结果进行加密并发送给DNS终端。
DNS终端收到响应消息后,使用其私钥信息解密响应消息的响应资源记录(RRset),并根据DNS协议进行处理。
具体流程如图4所示。以查询为例,实现加密查询方法主要包括以下步骤: (1)服务器通过PKI发布公钥,客户端手动配置服务器公钥; (2) 客户端生成密钥对; (3) 客户端在构造的查询包中,将客户端的公钥添加到查询包的附加部分,并用服务器的公钥加密后,将查询包发送到服务器; (4) 服务器收到加密后的查询数据包,使用服务器的私钥解密得到DNS查询内容和客户端的公钥; (5) 服务器构造响应包,用客户端的公钥加密,并将响应包发送给客户端; (6) 客户端收到加密后的响应包,使用客户端的私钥解密并获取响应内容。
图4 加密DNS查询流程
实验与分析
为了测试可行性,进行了相关实验,对比了基于TLS和DTLS加密方法的DNS查询,验证了其可行性以及相对于目前流行的加密方法的低延迟优势。
实验方法
由于DNS查询主要通过UDP传输,因此实验主要关注基于DTLS加密方法的DNS查询数据包的延迟。实验测试了使用RSA和ECC算法的两种加密方法对不同大小的数据包的性能。通过发起多次DNS查询并取平均值,计算出每种方法下的DNS查询延迟,并对两种方法在DNS加密的使用上进行比较。功能开启。
实验使用-0.9.8和++5.6.5加密库实现RSA和ECDSA加密,并通过编程模拟两种加密方式下DNS服务器和客户端的软件行为。客户端DNS查询全部通过脚本定时循环调用实现,因此基于DTLS加密的查询每次都会触发新的DTLS连接,并且不使用历史会话。实验运行环境为5.7,服务器和客户端部署在北京同城的不同节点上。
实验结果与分析
1)固定通信字节延迟比较。采用10 Bit通信数据,使用不同强度的密钥进行测试,实验结果如图5所示。
图5 两种DNS加密方式时延对比
从实验结果来看,当密钥长度相等时,基于DTLS加密的DNS查询在连接建立过程中协商密钥的时间较长,整体DNS查询延迟大于该方法下的DNS延迟。 RSA加密算法下,加密强度越小,密钥越短。与DTLS方法相比,性能是DTLS方法的2.79倍(加速比定义为DTLS方法与延迟的比值,比值越高,延迟越长,速度越低,速度越快) );随着RSA密钥长度增加到2048 Bit,由于客户端的密钥需要加密然后通过DNS消息传输到服务器,因此加密时间明显增加,但总延迟仍然低于DTLS加密方法(图6) (一个))。
图6 ECDSA算法下两种DNS加密方式的加速比
当使用ECDSA加密算法且密钥长度为112、160或256 Bit时,密钥加密的成本小于DTLS密钥协商的通信成本,因此整体网络延迟优于DTLS方法,但加密强度增加后,加密密钥本身的开销大幅增加,明显大于DTLS密钥协商的通信开销,导致加密DNS查询延迟急剧增加。在ECDSA 512下,性能低于DTLS方法(图6(b))。
2) 修复了密钥长度延迟比较。使用RSA算法,选择密钥长度为1024位,测试了DTLS方法中不同长度的DNS消息的延迟。实验结果如图7所示。
图7 1024位密钥长度下RSA时延对比
由于DTLS在密钥协商成功后使用对称密钥对数据进行加密,因此随着DNS消息大小的增加,基于DTLS的DNS加密方法的延迟并没有明显增加。当 DNS 消息变大时,其传输时间也会增加。增长率显着提高(图8)。
图8 DTLS与1024位密钥长度下DTLS的加速比
从实验可以看出,在1024位密钥加密的情况下,整体传输延迟明显低于基于DTLS的DNS加密方法。
综上所述,当密钥长度和传输消息较小时,延迟明显低于DTLS方法;对于基于DTLS加密的方法,由于连接建立后双方都使用对称密钥加密,所以耗时的增加大于小于;由于大多数DNS报文的大小一般都在该范围内,因此与DTLS方法相比,可以显着降低DNS加密传输延迟。另外,基于DNS传输,其无状态特性也可以显着提高服务器的并发能力。
随着互联网上的个人隐私问题越来越受到关注,DNS隐私泄露问题将变得越来越突出。针对DNS个人隐私问题现有技术进行了分析,并在现有技术方案的基础上提出了一种新的DNS加密通信方法:与传统方法相比,该方法在现有DNS架构和消息格式下,采用非对称加密算法进行密文通信。不仅完成了DNS个人隐私保护,还提高了核心域名解析算法的并行粒度,降低了成本。 DNS终端和DNS服务器之间的通信开销有效地保持了DNS的低延迟特性。
对RSA、椭圆加密动物算法(ECC)等加密算法进行了实验,为后续通信加密应用研究和DNS安全解析并行研究以及深入探索TLSA的扩展方法提供一定的参考协议,提高加密通信的安全级别。后续我们将深入研究该方法对在线社交和大数据交换领域的改进和影响,以进一步降低互联网隐私泄露的风险。 (刘志远编辑)
参考文献(略)
本文作者:张海阔、卢中华、陈文宇、陈联东、左鹏、王珏、徐彦之
作者简介:张海阔,中国科学院计算机网络信息中心、中国科学院大学、中国互联网络信息中心,博士研究生,研究方向为计算机系统结构;陈文宇(通讯作者),中国科学院计算机网络信息中心、中国科学院大学、中国互联网络信息中心,高级工程师,研究方向为计算机系统架构。
扫一扫在手机端查看
我们凭借多年的网站建设经验,坚持以“帮助中小企业实现网络营销化”为宗旨,累计为4000多家客户提供品质建站服务,得到了客户的一致好评。如果您有网站建设、网站改版、域名注册、主机空间、手机网站建设、网站备案等方面的需求,请立即点击咨询我们或拨打咨询热线: 13761152229,我们会详细为你一一解答你心中的疑难。