电子邮件是当前网络办公中最重要的沟通工具之一, 其传输的数据通常是用户的私人通信信息、密码恢复确认信息以及公司内部和公司间的极具价值的数据. 电子邮件也是发起有针对性的网络攻击的首选渠道, 一半以上的电子邮件(53%)属于垃圾邮件, 越来越多的垃圾邮件包含恶意软件, 其比例在2016年显著上升, 电子邮件已经一跃成为恶意软件传播的主要媒介^[1]. 当今, 伴随着垃圾邮件的泛滥以及社会工程手段的加强, 很难判断一封电子邮件是否具有欺诈性.

电子邮件系统的基础是简单邮件传输协议(Simple Mail Transfer Protocol, SMTP), SMTP是发送和中继电子邮件的互联网标准^[2,3]. 但是, 正如1981年最初设想的, SMTP不支持邮件加密、完整性校验和验证发件人身份. 由于这些缺陷, 发送方电子邮件信息可能会被网络传输中的监听者截取流量读取消息内容导致隐私泄漏, 也可能遭受中间人攻击(Man-in-the-Middle attack, MitM)导致邮件消息篡改, 带来网络钓鱼攻击. 为了解决这些安全问题应对日益复杂的网络环境, 邮件社区开发了诸多电子邮件的扩展协议, 例如STARTTLS, S/MIME, SPF, DKIM和DMARC等协议. 当前的邮件服务厂商大都也是采用以上扩展协议的一种或几种组合, 辅以应用防火墙、贝叶斯垃圾邮件过滤器等技术, 来弥补电子邮件存在的安全缺陷.

但是需要注意的是, 以上邮件协议本身仍存在安全及部署问题, 这有但不限于缺乏针对终端用户的全球可扩展的密钥分发和撤销机制、当前邮件安全解决方案过于复杂以及自动化部署执行方案缺失等原因. 比如, 互联网工程任务组IETF在1999年就已经发布了针对终端用户安全的S/MIME协议, 但是直到2017年, 该协议也未能在全球邮件服务器中大规模部署.

为了解决当前邮件系统中存在的安全及部署问题, IETF在近年发布了基于域名系统的域名实体认证协议(DNS-based Authentication of Named Entities, DANE)及基于DANE的诸多扩展协议来提升电子邮件的机密性及安全性^[4–6]. 简而言之, 这些通过DANE改进的协议基于域名系统(Domain Name System, DNS)和域名系统安全扩展(DNS Security Extensions, DNSSEC)的现有基础架构, 创建终端用户使用的X.509证书的安全全局存储库以及验证电子邮件服务器的加密凭据, 弥补了当前电子邮件系统中存在的诸多不足.

截至目前, 国内对电子邮件系统及其协议的研究较少, 本文创新性地从邮件加密和验证两个方面系统地梳理了当前电子邮件系统所使用的协议及其架构演进, 分析了DANE及基于DANE对当前普遍采用的邮件协议的改进, 最后展望了未来基于DANE的电子邮件系统发展, 以期为未来研究提供有益的启发和借鉴.

本文剩余部分的组织结构如下: 第1节和第2节分别从电子邮件加密和验证角度介绍当前电子邮件系统的加密和验证机制. 第3节阐述IETF近年提出的DANE、其对当前邮件加密和验证协议的改进和不足以及基于DANE的安全邮件系统架构. 第4节总结和展望.

1 电子邮件的机密性

为了保证电子邮件的机密性防止数据监听后明文读取, 通常是从邮件传输通道和邮件消息两个角度考虑数据加密.

1.1 邮件在传输过程中的机密性

为了保证邮件在传输过程中的机密性, IETF在1999年发布了通过传输层安全协议(Transport Layer Security, TLS)来提升SMTP安全性的互联网标准^[7]. 但是, 原始的SMTP协议并不兼容TLS协议, 为了解决这个问题, 一个新的命令(STARTTLS)被添加到协议中, STARTTLS通过TLS/SSL将SMTP明文通信连接升级为加密连接. 在一个经典的STARTTLS会话中, 客户端首先与邮件中继服务器协商进行SMTP连接; 然后客户端发送STARTTLS命令, 该命令启动标准TLS握手; 最后, 客户端通过此加密保护信道来发送邮件内容、附件和任何相关联的数据. 图1为添加STARTTLS命令后的邮件传输的简化场景图.

STARTTLS旨在保护与SMTP服务器之间邮件信息地发送, 主要是通过TLS加密的方式来防止电子邮件在传输过程中信息泄漏. 但是, STARTTLS提供的是随机加密(opportunistic encryption), 这与HTTPS客户端的行为不同, HTTPS客户端严格要求通信双方都使用TLS协议. 而如果邮件中继服务器不支持或拒绝STARTTLS命令, 那么邮件将会以明文继续传输(587端口). 使用STARTTLS加密信道虽然防止了邮件在传输过程中被监听读取, 却不能阻止攻击者利用STARTTLS的这一特性发动降级的中间人攻击(MitM Downgrade Attack)^[8].

此外, 即使双方服务器协商使用TLS加密, 发送方也无法保证收件人邮件服务器的真实性. 在RFC 3207中并没有定义接收方如何验证接收到的加密证书, 而在几乎所有情况下, 接收方不会验证接收的证书, 这也是一个潜在的威胁.

针对以上问题, 当前IETF工作组提出了保护邮件通信安全的一个草案SMTP-STS^[9]. 该草案与HSTS(RFC 6797)标准类似, 在HTTPS协议中, 用户能够选择不允许通过不安全的信道, HSTS则允许站点指示给用户之后的连接必须使用HTTPS. SMTP-STS的原理是让接收域在其DNS中发布资源纪录, 以明确的URL来发布其安全策略, 发件人则使用HTTPS进行访问. 该草案的优点在于它在解决STARTTLS以上两个问题的同时, 定义了规则、反馈机制及在TLS协商失败后采取对应的措施, 而且该草案并未规定使用DNSSEC. 但是, 该草案也有其缺点, 它要求发送方邮件中继服务器(Mail Transfer Agent, MTA)必须使用HTTPS来确保安全信道存在, 还可能存在DNS欺骗或者分布式拒绝服务攻击, 阻止客户端查询这些策略.

SMTP-STS虽然在一定程度上解决了STARTTLS中存在的问题, 但是该协议仍然是一个针对MTA之间通信的信任机制, 它对端到端的邮件加密和电子签名没有任何作用.

1.2 邮件端到端的加密

电子邮件协议在设计之初, 仅支持纯文本消息的数据传输(RFC 822). 为了满足不同类型消息的发送, IETF在1996年发布了多用途互联网邮件扩展协议(Multipurpose Internet Mail Extensions, MIME)^[10–12], MIME协议的发布扩展了SMTP协议, 使得电子邮件可以支持格式化文本、附加文件、HTML音视频、应用程序和图片等多种数据格式.

为了保证MIME数据的机密性、完整性以及来源验证, IETF在1996年和1999年分别发布了基于MIME协议的扩展协议OpenPGP^[13]和S/MIME^[14], S/MIME和OpenPGP都使用了公开密钥加密机制实现电子邮件的数字签名和加密. 由于信任链以及密钥管理等方式的不同, S/MIME相对来说具有更广泛的应用场景.

公钥加密机制为电子邮件用户提供了一种产生公钥/私钥对的方式, 密钥通常需要被证书签发机构(Certificate Authority, CA)签名或者编码为自签名证书. 公钥数字证书旨在提供给全球的任何个人、组织和机构, 以便他们可以使用S/MIME来加密要发送的电子邮件. 在公钥密码体制中, 公钥加密的电子邮件只能被持有该公钥对应的私钥的接收者解密. 此外, 私钥还可用于电子邮件的数字签名, 因为只有发件人拥有某一公钥对应的私钥, 所以该机制能够确保电子邮件发件人的真实性及数据完整性.

然而, 一个不幸的事实是, 虽然S/MIME协议采用的信任机制很好, 但是, S/MIME的部署过程过于复杂.

首先, 生成和安装S/MIME所使用的加密/签名密钥的手动操作步骤非常困难和耗时, 需要通信双方对公钥加密体制等密码学原理有所了解. 同时, 用户需要自行保管私钥. 考虑普通用户通常会有多个终端设备和多个电子邮件账号, 将私钥从一个终端设备传输到另一个设备, 这对大多数用户来说是不可能的. 因此, 大多数用户根本不会使用S/MIME.

其次, 假设用户掌握了密钥安装和管理的技术, 下一步是关于分发和管理公钥数字证书. 到目前为止, 没有一个可以用于发布和检索个人公钥的全局密钥存储库. 相反, 通常是使用S/MIME加密的用户通过向收件人发送带有数字签名的电子邮件或者通过电话等方式手动分发密钥到收件人. OpenPGP是通过“密钥交换方”和一组有限的密钥交换服务器使用信赖网络(Web of Trust, WoT)分发密钥. S/MIME和OpenPGP都不具有很好的扩展性, 邮件服务器厂商无法向密钥未知的客户发送加密电子邮件, 这限制了用户对该加密协议的使用.

另一个操作问题是伪造数字证书. 某些可信任的权威CA可能会由于失误或者其它原因签发伪造的签名证书, 而通常情况下, 收件人又不会检查电子邮件证书的正确性, 只要证书存在, 通常会认为它是有效的. 与假冒证书相关的问题是类似域名中存在的“变体域名”问题, 也就是注册高度相似的极具欺骗性的域名, 比如域名“icbc.cn”和“1cbc.cn”. 在电子邮件系统的中, 当这些变体域名申请了伪造的数字签名后, 由于普通用户通常不具备足够的鉴别能力, 可能导致被欺骗. 比如来自“alice@examp1e.cn”(‘1’为数字1)的欺诈邮件可能会被误认为合法的“alice.example.cn”. 而此时如果能够有一个全局管理证书的存储库, 如DNS, 通过向该存储库查询则可以鉴别真伪, 从而避免使用到恶意证书.

同时, S/MIME协议本身是没有制定规则和反馈机制的, 当由于一些未知原因导致拒绝接受S/MIME加密或签名的电子邮件时, 无法提供故障反馈.

2 邮件身份验证

虽然STARTTLS和SMTP-STS保证了邮件在传输过程中的加密, 防止遭受窃听读取, 但是其仍无法解决发件方身份伪造、消息篡改等问题. 当前的电子邮件系统主要是通过三种基于DNS来发布和检索资源记录的方式解决这些问题.

2.1 SPF和DKIM

发件人策略框架(Sender Policy Framework, SPF)是一种以IP地址认证电子邮件发件人身份的检测电子邮件欺诈的技术, 是非常高效的垃圾邮件解决方案^[15,16]. SPF允许组织授权一系列为其域发送邮件的主机, 而存储在DNS中的SPF记录则是一种TXT资源记录, 用以识别哪些邮件服务器获允代表本网域发送电子邮件. SPF阻止垃圾邮件发件人发送假冒本网域中的“发件人”地址的电子邮件, 收件人通过检查域名的SPF记录来确定号称来自该网域的邮件是否来自授权的邮件服务器. 如果是, 就认为是一封正常的邮件, 否则会被认为是一封伪造的邮件而进行退回. SPF还允许组织将其部分或全部SPF策略委托给另一个组织, 通常是将SPF设置委托给云提供商.

DKIM域名密钥识别邮件标准(Domain Keys Identified Mail)是一种通过检查来自某域签名的邮件标头来判断消息是否存在欺骗或篡改的检测电子邮件欺诈技术^[17]. DKIM是利用加密签名和验证的原理, 在发件人发送邮件时候, 将与域名相关的私钥加密的签名字段插入到消息头, 收件人收到邮件后通过DNS检索发件人的公钥(DNS TXT记录), 就可以对签名进行验证, 判断发件人地址及消息的真实性. 需要注意的是, DKIM只能验证发件人地址来源的真伪, 无法辨识邮件内容的真实性. 同时, 如果接收到无效或缺少加密签名的消息, DKIM无法指定收件人采取什么措施. 此外, 私钥签名是对本域所有外发邮件进行普遍的签名, 是邮件中继服务器对邮件进行DKIM签名而不是真正的邮件发送人, 这意味着, DKIM并不提供真正的端对端的电子签名认证.

SPF和DKIM中共同存在的问题是缺少有效的策略和反馈机制, 这两个协议并未定义如何处理来自声称为某域的未经身份验证的电子邮件, 如何处理第三方声称托管的某域的未经身份验证的邮件, 如何反馈和统计声称是某域的身份认证成功或失败的电子邮件.

2.2 DMARC

DMARC以域名为基础的邮件认证、报告和一致性标准(Domain-based Message Authentication, Reporting, and Conformance)就是用来解决SPF和DKIM中存在的这些问题^[18], DMARC的主要用途在于设置“策略”, 这个策略包含接收到来自某个域未通过身份验证的邮件时应执行什么操作、该域授权的第三方提供商发送了未经身份验证的邮件时该如何处理. DMARC还会让ISP发送有关某个域身份验证成功或失败的报告, 这些报告将发送至“rua”(汇总报告)和“ruf”(取证报告)中定义的地址中. 同时, DMARC依靠出站邮件流配置的SPF记录和DKIM密钥来确保邮件来源及签名的完整性, 当未通过SPF或DKIM检查的邮件时便会触发DMARC策略. 图2为基于SPF、DKIM和DAMRC的邮件验证简化场景图.

3 基于DNS的域名实体认证协议DANE

DANE一种将X.509证书绑定到DNS中的机制, 可用于存储自签名证书或者从CA签发的特定X.509证书, 其中, 证书作为DNS资源记录通过DNSSEC来实现其来源验证和完整性保护^[19–21]. 根据证书用途的不同, 基于DANE的DNS资源记录也有所不同: 资源记录TLSA用于发布使用TLS加密的证书, 资源记录OPENPGPKEY和SMIMEA分别用来发布OpenPGP和S/MIME协议中使用的证书.

保护公开密钥防止被篡改是实际公钥应用中一大难题, 公钥基础设施PKI的主要目的就是用来安全、便捷、高效地获得公钥, 而IETF发布DANE协议的动机之一是解决现有的基于X.509的PKI的问题. 例如, DANE在应对欺诈证书、处理证书撤销、创建可全球发布和检索证书的管理机制并允许自签名证书授权等方面提供了很好的解决方式.

DNS的层级架构创建了授权机制, DANE基于DNS的授权机制来实现以上目标. 在DNS中只有授权的域所有者才能够在其DNS域中放置相应的资源记录, 其他未授权的人都没有权限这样做. 例如, 只有拥有“example.com”域名的公司才可以在该域名的DNS名称空间中放置资源记录.

DANE协议的第一个应用是针对Web服务器中使用的TLS证书的身份验证, 而目前其在邮箱中的应用主要针对以上TLS、S/MIME、OpenPGP和DMARC协议的改进.

3.1 基于DANE的TLS

在2.1节中已经阐述了SMTP服务器在使用STARTTL命令开启TLS加密传输中存在降级的中间人攻击潜在风险, 而基于DANE的随机TLS加密则可以很好的解决这个问题^[5]. 其大致流程图如图3所示.

在发出STARTTLS命令之前, 邮件服务器先发出DNS查询请求, 查看接收方服务器是否存在相关的DANE TLSA记录. 如果记录存在, 那么使用加密传输的STARTTLS命令就一定会发出, 这时如果由于中间人等原因, 导致接收方服务器拒绝STARTTLS请求或者接收到的证书与DANE TLSA纪录不匹配, 邮件服务器就会中止通信, 并在稍后重新发送加密传输请求. 如果接收方DNS服务器中未部署DANE TLSA, 则继续使用随机TLS加密.

因此, DANE在保证邮件服务器加密传输的同时, 又能验证接收到的证书的真实性. 同时, 由于TLSA纪录存在与否并不影响当前邮件系统采用降级的TLS的加密传输策略, 所以可以增量部署DANE安全机制.

3.2 基于DANE的S/MIME

尽管基于DANE的随机TLS加密提供了一种保证数据在邮件中继服务器之间加密传输的机制, 在邮件终端用户端到端的安全和验证方面却没有任何保障: 无法获取终端用户的数字签名, 无法对终端接收方身份验证以及无法保证电子邮件在到达接收方邮件服务器之后仍然加密存储. 在1.2小节中阐述了S/MIME协议可以用来解决这些问题及其自身存在的密钥管理和分发问题, 而基于DNSSEC的DANE则可以解决S/MIME的这些问题.

2017年5月31日正式发布的RFC 8162通过定义SMIMEA资源记录来扩展DANE协议. SMIMEA纪录与TLSA记录遵循相同的协议格式, 但是可以用来存储单个用户的证书数据. 该协议采用哈希算法将电子邮件地址存储在SMIMEA资源记录中, 保证发送方查询收件人证书的同时, 提供隐私保护. 该协议通过使用由DNSSEC保护的DNS系统, 利用DNS作为可信任的存储库, 实现终端用户电子邮件证书的身份验证.

3.3 DANE对DMARC的补充

DMARC为SPF和DKIM定义了一些策略, 提供反馈机制来报告所采取的行为, 旨在防止攻击者伪造电子邮件的发件域发送欺诈邮件, 防止重放攻击, 确保收件人收到的邮件确实来自声称域; 而DANE则可以确保双方通信信道安全, 能够让发件方确定确实是在与指定的收件人通信, 保证数据加密传输给特定收件人.

从两者功能考虑, DMARC和DANE互为补充, 谁也不能取代谁. 为此, IETF为DANE提出了DMRAC的扩展草案^[22].

3.4 DANE的不足

当然, DANE也有其“先天不足”之处. 基于DANE的邮件系统最为外界所诟病的是其需要依靠DNSSEC来对接收到的DNS资源记录来源进行认证, 验证其存在性和数据完整性. 毕竟当前DNSSEC还未在全网广泛部署^[23], 因此, 会阻碍DANE在全球范围内的部署.

同时, DNSSEC本身也存在一些安全及部署问题^[24]. 如果攻击者想要对基于DANE的邮件系统发动攻击, 此时, 可以针对DNSSEC的安全问题发送攻击, 一旦攻击导致DNSSEC无法正常运作, DANE因此也会受到牵连, 从而导致基于DANE的邮件系统瘫痪.

最后, 由于域所有者需要对新添加的SMIMEA资源记录进行管理, 因此可能存在一些管理上的问题, 这加大了管理者管理难度^[25].

3.5 基于DANE的邮件系统架构

根据当前IETF提出的DANE及其对当前邮件协议的改进, 本文提出了基于DANE的邮件系统架构. 图4 展示了基于DANE的邮件系统如何实现端到端的邮件加密、消息完整性鉴定和来源验证. 其具体流程如下文.

假设分别位于两个不同域的Alice和Bob需要使用加密和认证的电子邮件进行通信, 他们均已经获得了X.509证书. 此时, 如果没有针对电子邮件证书的全球公共存储库, Alice和Bob如何获得对方所在域的证书？如果针对电子邮件单独建立一个全球公共存储卡, 则无论是从管理还是花销上, 其代价都是巨大的. 而DANE通过在DNS中发布资源记录则可以相对“轻松”地提供这样的功能.

Alice使用私钥对要发送给Bob的邮件消息进行数字签名, 这可以直接在其本地终端设备上使用S/MIME协议的电子邮件客户端中完成. 接下来, 为了加密消息, 本地客户的向DNS进行查询以检索收件人Bob的公钥证书, 使用公钥证书确保只有Bob可以解密邮件, 同时此证书由用户缓存以备将来再次使用. 签名和加密的消息之后发送给Alice所在域的邮件服务器, 邮件服务器在发出邮件之前, 继续使用基于DANE的STARTTLS进行协商加密, 保证邮件中继服务器之间的加密传输. 在最终Bob所在域的邮件服务器接收邮件之前, receiver域还需要使用DMARC等协议来确保邮件来源的真实性以及邮件的完整性.

当Bob从邮件服务器接收消息后, 将通过他的私钥对邮件进行解密, 在Bob的终端设备中执行解密操作可确保数据在到达服务器之后的机密性. 之后Bob需要验证此消息, 确定该邮件真的是来自sender域的发件人Alice还是欺诈邮件. 为了确认真实性, 邮件客户端必须检查数字签名的真实性, 此时需要Bob通过执行发送DNS查询检索Alice的公钥证书, 用于解密数字签名并执行数据完整性检查. 如果签名验证正确, 则该消息是真实的, 同时确定该邮件在传输过程中没有改变.

4 总结与展望

当前业界采用的STARTTLS保证邮件传输过程中的机密性, SPF、DKIM和DMARC保证邮件来源验证及完整性鉴别的方式, 在一定程度上解决了电子邮件中的诸多安全问题, 但是面对当下垃圾邮件肆虐、网络钓鱼横行的网络环境, 这些措施仍旧显得力不从心.

DANE的出现为解决当前电子邮件中加密传输存在的降级攻击、邮件端到端加密等问题提供了一个可行的思路. DANE基于DNS的特性保证了其可以建立一个全球范围的可扩展的电子邮件证书分发和管理机制, 为建立全球可信的电子邮件网络打下坚实的基础.

当前国内外基于DANE的研究及部署尚在初期阶段, 本文梳理了基于DANE的邮件扩展协议, 提出了一套以DANE为基础的邮箱系统架构, 以期为未来研究及建立一套全球范围更加安全的的邮件系统提供有益的启发和借鉴.