【论文分享】邮件服务厂商中DANE机制部署趋势测量与安全隐患分析

admin 2022年10月29日15:20:10评论81 views字数 5930阅读19分46秒阅读模式

今天分享的主题为“邮件服务厂商中DANE机制部署趋势测量与安全隐患分析”。研究成果为同一研究团队发表的两篇论文。


第一篇论文面向邮件服务厂商中DANE机制的部署情况,开展了大规模测量研究,全面展现了DANE的生态现状。第二篇论文,作为对上述测量工作的延续,围绕DANE的管理和验证情况,针对知名邮件服务商开展了用户调查研究(User Study),剖析DANE机制部署应用存在的安全隐患,并分析问题产生的根本原因


论文分别于2020年、2022年发表在网络安全顶级学术会议USENIX Security:

1.《A Longitudinal and Comprehensive Study of the DANE Ecosystem in Email》
发表于USENIX Security 2020(录用率:16.1%=156/977)
2.《Under the Hood of DANE Mismanagement in SMTP》
发表于USENIX Security 2022 (录用率:17.2%=256/1492)


    本推送梳理并整合介绍两篇论文的重要发现,全文约3200字,阅读时间约9分钟。


    01

    【背景介绍】


    互联网公钥基础设施的正常运转依赖于证书颁发机构(CA)。作为数字公钥证书体系的信任锚点,CA可为任意域名签发证书。然而,CA也并非绝对可靠。例如DigiNotar事件表明,知名的CA也有可能会被攻击者攻破[1]


    为削弱对第三方CA的依赖,2012年互联网技术标准组织提出了DNS-based Authentication of Named Entities (DANE)协议[3]。DANE协议允许域名所有者通过配置DNS TLSA资源记录,进而决定可被终端设备信任的域名证书。与此同时,借助于域名安全领域的最佳实践——DNSSEC,TLSA记录的真实性和完整性可以得到进一步保障。


    当前,由于DANE机制的部署应用会带来额外的网络延迟(包括查询TLSA记录、验证DNSSEC记录),DANE在Web应用中尚未得到广泛普及。相对而言,邮件通信过程对DANE引入的延迟具有更高的容忍度,而且,邮件通信协议SMTP面临的中间人攻击问题日益严峻。因此,近年来,DANE机制在邮件服务中得到了相对广泛的部署和应用。甚至部分国家的政府机构在公开招标中要求邮件服务供应商必须支持DANE机制[4][5]。


    【论文分享】邮件服务厂商中DANE机制部署趋势测量与安全隐患分析

    图表1 DANE SMTP验证流程


    然而,正如图表1所示,在邮件服务中部署DANE非常复杂——需要邮件客户端、中间件、邮件服务端、域名所有者和域名权威服务器诸多实体共同参与,且涉及DNSSEC验证、证书部署和TLSA记录验证等多个流程[6]。任一实体配置和流程错误都有可能致使DANE验证失败。


    我们接下来介绍的两篇论文对邮件安全通信中DANE部署、配置、管理和验证策略展开了长期且大规模的测量分析,希望能够促进DANE机制的广泛部署。论文主要研究以下问题:


    1. 目前DANE机智在邮件服务(SMTP)中的部署趋势如何?

    2. 是否存在误配置或可用性问题?

    3. 误配置的原因是什么?部署过程中有哪些技术壁垒?



    02

    【研究方法】


    作者分别从邮件“服务端”和“客户端”两个角度出发展开大规模主动测量:(1)为分析邮件服务端对于DANE机制的实现策略,作者收集5个主要TLD下所有二级域名的MX记录,并主动探测邮件服务器(即MX记录中的目标地址)的配置情况,包括DNS记录与TLS证书等;(2)为检测邮件客户端的支持和验证情况,作者针对主流的邮件服务商、MTA软件和DNS软件展开了端到端的控制性实验。


    1. 服务端数据收集


    获取邮件服务域名及DNS资源记录:

    [USENIX'20] 2017年10月22日-2019年10月31日,每天从OpenINTEL获取DNS数据,选取三个gTLD(.com, .net, .org)和两个ccTLD(.nl, .se)下所有二级域名的权威服务器(SOA记录)、邮件服务器(MX记录)和DNSSEC相关配置(DNSKEY、RRSIG等),共涵盖178M域名。

    [USENIX'22] 2019年7月13日-2021年02月12日,获取除.nl之外其他四个TLD的上述数据,共涵盖121M域名。总体数据情况见图表2。


    【论文分享】邮件服务厂商中DANE机制部署趋势测量与安全隐患分析

    图表2 两次测量数据集汇总


    测量邮件服务器的DANE部署和证书配置情况: 作者在俄勒冈、弗吉尼亚、圣保罗、巴黎和悉尼五个观测点自建SMTP客户端,每小时主动与MX记录中邮件服务器的25、465、587号端口分别建立SMTP连接、发送STARTTLS命令、获取TLSA记录和TLS证书、验证DANE(包括DNSSEC验证和TLSA验证),以探测邮件服务器和DNS服务器的行为。



    2. 客户端测试对象与测试方法


    测试对象

    (a) 29家流行邮件服务提供商及其DNS解析服务器,包括mail.com、Gmail等;

    (b4种支持DANE的邮件传输代理(MTA)的软件实现,包括Postfix、Exim等;

    (c10种流行DNS应用的软件实现,包括BIND9、PowerDNS、MicrosoftDNS。


    测试方法:端到端的控制实验

    如图表3所示,首先自建SMTP服务器和DNS权威服务器,分别配置STARTTLS、证书、DNSSEC,涵盖多种类型的DANE误配置。随后在各家邮件服务商注册服务,分析其在发送(如是否发送STARTTLS命令)和接收阶段对各种(误)配置组合(如接收无效证书、证书与TLSA不匹配等)的验证和处理情况。


    【论文分享】邮件服务厂商中DANE机制部署趋势测量与安全隐患分析图表3 邮件服务商测试流程


    3. DANE SMTP的管理模式分类


    DANE SMTP部署过程中涉及到多方主体。为了清晰地划分各方职责、对部署问题做归因分析,作者根据SMTP和DNS服务器的管理主体,将DANE管理模式分为三种类型(图表4):

    SO:SMTP服务外包、DNS服务自建

    SSDO: SMTP服务自建、DNS服务外包

    SSDS:SMTP服务和DNS服务均自建

    【论文分享】邮件服务厂商中DANE机制部署趋势测量与安全隐患分析图表4 DANE部署和管理模式



    03

    【主要发现】


    1. DANE SMTP部署现状


    如图表5所示,MX记录中DANE的支持率整体偏低(gTLD下域名的支持率不足1%),但稳中有升。此外,少数邮件服务商正在积极推动DANE的部署,例如one.com和Loopia。

    【论文分享】邮件服务厂商中DANE机制部署趋势测量与安全隐患分析

    图表5 DANE支持比例及趋势


    然而,大量域名的MX记录未完全支持DANE,即只为部分MX域名配置了TLSA记录。18%的.com, .net和.org、39%的.nl域名存在此类问题,可能受到降级攻击威胁。


    2. DANE管理模式及存在的问题

    正确的DANE管理要求域名所有者:(1)正确地配置DNSSEC;(2)为域名配置TLSA记录;(3)支持STARTTLS,并提供可以通过TLSA记录验证的证书。作者通过主动探测实验,分别对DANE验证失败的原因和TLSA验证失败的影响展开了分析。


    2.1 DANE部署和管理模式

    【论文分享】邮件服务厂商中DANE机制部署趋势测量与安全隐患分析图表6 不同管理模式下域名的部署情况


    在实验涉及的全部域名中,96.6%依赖公共邮件服务托管商(SO),97.9%依赖公共DNS服务提供商(DO)。作者通过分析不同管理模式下的DANE部署情况(图表6),发现自建的SMTP服务(SS)更容易出错;而外包SMTP服务(SO)的域名部署状况良好。


    2.2 DANE验证失败的主要原因


    原因一:缺乏STARTTLS的正确支持。约0.22%的邮件服务器未实现STARTTLS,0.29%虽支持STARTTLS但未提供有效的TLS证书。


    原因二:DNSSEC验证失败。80%的TLSA记录已被DNSSEC签名,但其中18.5%缺少DS记录,说明多数邮件服务即使部署了DANE,也无法得到有效保护。如果服务商自动支持DNSSEC并创建信任链,将极大缓解TLSA验证失败的问题


    原因三:TLSA记录和证书不匹配。16%~23%的TLSA记录和对应证书不匹配,使得SMTP连接出错并直接中止。具体原因包括TLSA记录未及时更新(如图表7)、参数配置错误等。

    【论文分享】邮件服务厂商中DANE机制部署趋势测量与安全隐患分析图表7 TLSA记录匹配已弃用证书的比例


    2.3 DANE密钥轮换问题

    作者从数据集中筛选了2,569个SMTP服务器,通过分析TLSA更新和证书更新时间,发现87%的SMTP服务器存在TLSA更新延迟、未删除旧记录及未引入新记录等问题。


    此外,94.4%标记用途为DANE-EE的证书(可任意指定证书,且不验证有效期)由第三方CA签发的,且通常是Let’s Encrypt等自动化工具签发的证书,有效期短且默认更换公私钥,因此DANE管理员也需要跟随着及时更新TLSA。但目前没有自动化的工具实现TLSA的同步配置


    3. 客户端对DANE的支持情况

    SMTP客户端是否查询并验证TLSA记录也是DANE部署的关键。作者对29家主流的邮件服务提供商、4种邮件传输代理(MTA)和10种DNS软件进行了分析。


    3.1 流行的邮件服务提供商

    (a) 23/29家提供商不验证DNSSEC,易受到DNS缓存投毒攻击;

    (b) 24/29家提供商支持STARTTLS,但是没有一家能正确验证证书;

    (c) 只有4家提供商请求TLSA记录并进行了验证。


    3.2 流行的MTA和DNS软件

    (a) 所有SMTP服务都依赖外部的递归解析器解析TLSA记录

    (b) 4种MTA软件均支持STARTTLS,但只有Postfix、Exim会查询TLSA (表8)

    【论文分享】邮件服务厂商中DANE机制部署趋势测量与安全隐患分析图表8 流行MTA软件的支持情况

    (c) 6/10种DNS软件支持DNSSEC并验证TLSA(图表9)

    【论文分享】邮件服务厂商中DANE机制部署趋势测量与安全隐患分析

    图表9 流行DNS软件的支持情况


    4. 问卷调查:DANE SMTP的管理状况和主要挑战

    为了深入分析邮件服务提供商部署DANE的主要原因、实践方案和技术壁垒,作者对两家域名注册局(.nl, .se)、三家网络提供商(NANOG,DENOG,NLNOG)和39家邮件服务提供商展开了问卷调查。主要问题和结论为:


    Q:部署/不部署DANE的原因

    A:部署原因:(1)防御STARTTLS stripping ;(2)不信任CA,想要控制自己的证书。不部署的原因:操作复杂。


    Q:为何使用第三方CA签发证书

    A:想要和不支持DANE的SMTP服务器保持兼容(该现象会引入一个矛盾:由于客户端几乎不支持DANE,流行的邮件服务器选择使用第三方CA签发的证书以保持兼容性;而客户端认为即使不支持DANE、不验证TLSA,接收的证书也是可信的,因此不必支持DANE)。


    Q:是否遇到过DANE管理问题

    A:一些管理员称未遇到过DANE配置问题,但是实验显示其配置存在错误(说明DANE验证失败难以被发现)。特别地,4家提供商使用了自动化脚本更新证书和TLSA记录,是解决DANE部署的有效方案,但该方法目前未被普及。


    5. 作者对DANE部署的思考与讨论

    DANE机制是让域名所有者设置自己信任的证书,不依赖于第三方CA机构。而作者发现,很多TLSA记录中的配置的仍然是第三方CA签发的证书,相当于同时受两套独立的安全机制(PKIX和DANE)的约束。当CA证书更新时,所有域名的TLSA记录也需要同步更新。不但没有达到信任转移的目的,还增加了额外的复杂度。


    此外,由于TLSA记录和证书分别由DNS权威服务器和SMTP服务器分别控制,如何确保二者的同步是正确部署DANE的主要技术挑战之一。


    04

    【结论】


    本文围绕邮件服务中DANE机制部署的现状和脆弱性问题展开研究。作者对178M SLD和29家邮件服务提供商展开持续三年的测量分析,通过主动探测邮件服务器的配置策略,发现DANE整体部署比例依旧很低,多数邮件通信并未得到DANE的有效保护,主流软件对DANE提供默认支持的情况仍不乐观。作者还通过对主流邮件和DNS服务提供商开展问卷调查,发现了DANE部署和验证过程中的确存在技术壁垒,DNSSEC策略的实现、DNS权威服务器与SMTP服务器的同步配置可能是导致DANE部署比例低和易出错的主要原因。


    参考文献

    [1] DigiNotar SSL certificate hack amounts to cyberwar: https://www.theguardian.com/technology/2011/sep/05/diginotar-certificate-hack-cyberwar

    [2] French gov used fake Google certificate to read its workers' traffic.https://www.theregister.com/2013/12/10/french_gov_dodgy_ssl_cert_reprimand/

    [3] Paul E. Hoffman, Jakob Schlyter. The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA. RFC 6698: 1-37 (2012)

    [4] STARTTLS en DANE(Forum Standaardisatie 2016: https://www.forumstandaardisatie.nl/open-standaarden/starttls-en-dane

    [5] BSITR-03108-1:SecureE-MailTrans-port 2016: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03108/TR03108-1.pdf

    [6] Microsoft-How SMTP DNS-based Authentication of Named Entities (DANE) secures email communications.https://learn.microsoft.com/en-us/microsoft-365/compliance/how-smtp-dane-works?view=o365-worldwide


    原文链接

    1. https://www.usenix.org/conference/usenixsecurity20/presentation/lee-hyeonmin

    2. https://www.usenix.org/conference/usenixsecurity22/presentation/lee


    开源数据和分析代码

    https://dane-study.github.io


    编辑&审校|张一铭、刘保君



    原文始发于微信公众号(NISL实验室):【论文分享】邮件服务厂商中DANE机制部署趋势测量与安全隐患分析

    • 左青龙
    • 微信扫一扫
    • weinxin
    • 右白虎
    • 微信扫一扫
    • weinxin
    admin
    • 本文由 发表于 2022年10月29日15:20:10
    • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                     【论文分享】邮件服务厂商中DANE机制部署趋势测量与安全隐患分析https://cn-sec.com/archives/1372893.html

    发表评论

    匿名网友 填写信息