下面的表格提供了一个邮件生态系统的简单概述。邮件服务提供方之间的交流都是使用SMTP协议，服务提供方使用MTAs(邮件传送代理)来发送和接收来自其他服务提供方的邮件。MTAs使用SMTP协议进行交流，使用STARTTLS给邮件在传输中加密。为了发送一个邮件，发送方(MTA 输出)从DNS解析一条接受方域的邮件交换信息记录(MX)。邮件交换信息记录包含接收方(MTAs 输入)的服务器名字。一旦接收方的服务器名字被解析成功，发送方就会连接上相应的服务器并发送邮件。

图表1：邮件生态系统的高层次概述

在近年来，STARTTLS受到了高度的关注。在2015年，大约半数的相关研究论文被发布和提出(见附录)，所有的论文都强调安全邮件发送的基础设施在对抗大众监督和网络窃听方面的重要性。由于邮件是一个开放性的系统，为了邮件通信的安全，行业集体的共同努力是很关键的。

什么是STARTTLS ？

STARTTLS是一种扩展，它可以使支持STARTTLS的客户端和服务端之间纯文本通信随机升级为加密通信。下面的图表演示了客户端和服务端之间的一个SMTP会话。当服务端想要通过TLS接收邮件，它会在接收客户端EHLO请求后回复一个250 STARTTLS代码。如果客户端支持TLS协议，它会发起一个TLS握手协议，一旦TLS会话建立成功，邮件就会在一个加密的通道上传输。

图表2：客户端和服务端之间的SMTP STARTTLS会话

STARTTLS提供了对抗消极攻击的防护功能，实际上，STARTTLS的随机特性使在SMTP协议中TLS的广泛使用率。同时，随机性的加密也意味着STARTTLS在对抗MITM(主动)攻击是无效的。原因：(1)STARTTLS降级攻击 -通过从活动的SMTP会话中剥离STARTTLS协议，强制使邮件通过明文发送，(2) DNS MX欺骗攻击的可能性，一个受到危害的域名服务器返回了一条目标主机或者IP地址受到篡改的邮件交换信息记录，转移流量到攻击者的邮件服务器。

研究方法

为了这个研究，我们从2016年1月份30天内的邮件发送日志中收集了12M个不同的域的数据。在我们浏览的12M个域中，我们统计收集了9M个域的数据和3.7M的不同MX主机和大约1M的不同IP地址。对收集的数据进行汇总，并用多种方式呈现 - 不同的域，邮件交换信息记录，IP地址等等。数据也和我们以前在2015年5月(M3AAWG 34届会员大会上展示在爱尔兰的都柏林)做的一个研究(slides) 进行对比。

注意事项

这个Go语言的TLS实现有密码支持的局限性：尤其是，它不支持过期的/低安全性的密码。它也不支持SSLv3的客户端。这个研究基于我们从雅虎收集到的域信息，而且我们只考虑那些在收集期间发送过三封或者三封以上邮件的域。

研究结果

我们的研究结果被组织和呈现在不同的柱状图里，根据:

• 域 - 不同的域(9M)
• 邮件交换信息记录 - 不同主机的邮件交换信息记录(3.7M)
• IP地址 - 不同的IP地址(1M)
• 有效证书 - 有有效CA签名的证书的不同邮件交换信息记录(1.8M)
• 严格的证书 - 主机名匹配的有效证书(双向认证) (626K)

注意这些9M的域被包括于3.7M的MX信息，而3.7M的MX信息对应于1M的不同的IP地址。很多的域共用相同的MX，很多的MX共用相同的IP地址。

STARTTLS 的使用率

我们扫描的MX信息大约有80%支持STARTTLS。当和去年我们做的一个相似的调查进行对比，发现STARTTLS的使用率变化非常平缓，可以预见在近来不会有明显的增长。不同IP地址的柱状图使用率低于其他两个柱状图。

图表 3: STARTTLS 的使用  (*的数据来自2015年)

TLS X.509 证书
 

公钥大小

公钥大小是指服务器使用的RSA(或者ECDSA)密钥的长度。密钥长度小于2048被认为是弱密钥。但是我们发现大约14%的MXs仍然使用1024位的弱RSA公钥。有趣的是，发现在最后两个柱状图中的密钥长度比其他的柱状图更符合规范。考虑到这些主机都有有效的CA签名证书，这也是预料之中的。我们也发现了5个有效的ECDSA证书。

图表4：公钥长度分布图

签名算法

签名算法是指认证中心用来签名TLS证书的哈希加密算法。基于SHA1算法的证书已经过时了而且现在正在被初步淘汰。在2015年，我们发现颁发了少许基于RSA-SHA1算法的证书，但是在2016年（到2016年1月31号）没有发现RSA-SHA1的证书被颁发。但是进入2016年，有相当数量的SHA1证书仍然有效的运用着。这是一个令人担心的事情。几乎所有的浏览器厂商(在HTTPS方面)决定标记SHA1签名的证书为“不可信”，如果他们在2017年1月以后遇到SHA1签名的证书。当和2015年的数据进行对比，我们发现基于SHA256的证书有一个明显的增长，这也是期望的事情。你也许也发现了有一小部分基于MD5算法的证书，尤其是在域，MX和IP地址的柱状图。需要指出几乎所有的都是过期的或者自签名的。

图表5：签名算法分布图

证书验证

这个图表分三组来展示证书的分布: (1) 不可信的, (2) 有效证书, 和(3) 严格的有效证书。有效证书组代表连接了可信根CA的证书，严格的有效证书组表示有对等验证的有效证书。需要注意这里的对等验证是针对MX的主机名而言，而不是针对邮件的域。不同域的柱状图有更多的有效证书，而且严格的有效证书比其他的两个柱状图的对等验证部分多于50%。这个差距很大，因为大型的邮件服务提供商代理了数百万的第三方的域，这些第三方的域大都使用了STARTTLS的有效证书。至于不同的IP地址组，我们发现有很大百分比的不可信证书。

图表6：证书验证

证书验证 - 错误类型分布

这个图表展示了证书验证错误类型的分布情况。在域和MX的柱状图中，主机名不匹配(对等验证失败)比自签名/过期证书的错误更普遍。这个错误很多是因为大型的邮件服务提供商更偏向使用CA签名的证书而不是自签名的证书。有趣的是，即使大型邮件服务提供商受主机名不匹配问题的困扰，然而在IP地址的柱状图中，自签名和过期的证书仍然更普遍。

图表7：证书验证错误类型分布

证书链深度 

链深度为0主要表示的是自签名的证书(用红色表示)，在前三个柱状图中更普遍。然而，在有效的和严格有效的柱状图中，链的深度或者是2或者是3。这是符合预期的。

图表 8: X509 证书链的深度分布

TLS 会话
 

TLS 协议的版本

自去年以来，1.2版本的TLS使用率有所增加。它的使用率在有效的证书和严格有效的证书的柱状图中更高一些。TLS1.1的使用率没有显著变化。

图表 9: TLS协议版本

协商的密码 

这个图标展示的数据或许不是100%准确。因为我们的扫描器使用Go语言写的，Go语言的TLS实现对密码的支持有局限性。特别是，这个Go语言的TLS实现不支持过期的/不安全的密码和DHE密码套件，也不支持SSLv3的客户端。

                        
图表 10: TLS 会话的密码情况分布

部署的质量 - 邮件服务提供方的关注点
 

尽管STARTTLS可以防护被动的网络窃听，但是以当前的形式，不能有效的防护活跃的MITM攻击。为了强化邮件传送的基础设施和最终可以防护活跃的MITM攻击的目标，从而保护用户隐私， 行业集体的共同努力 是非常重要的。下面是几个可以极大增强STARRTTLS部署质量的建议。但是仅仅是这些步骤不能完全防护主动攻击，通过部署这些变化，邮件服务提供方可以满足防护普遍的的监控攻击的基准需求，而且可以增加主动攻击的难度。

服务端

• 清除自签名和过期的证书. 有一些提供免费认证的认证中心, 其中有Let’s Encrypt. Let’s Encrypt 是一个新的证书颁发机构，它提供可以自动更新证书的免费的TLS证书，自动更新证书可以解决证书过期的问题。  基于DNS的命名实体认证 (DANE) 是另一种认证STARTTLS服务实体的方式，这种方式不需要认证中心。DANE依赖于域名系统安全扩展(DNSSEC)来保证安全, 但挑战是DNSSEC没有被广泛的部署，他的采用率仍然很低。DANE不需要认证中心来颁发证书。

• 升级有效证书以遵循严格认证 (对等验证). 操作人必须确定他们的证书不仅是有效的，而且还和他们的主机名匹配。 我们观察到了大量的主机名不匹配的有效证书，有一些还是来自大型的邮件服务提供商。

• 用基于SHA256的证书替换基于SHA1的证书. SHA1加密哈希算法被认为是弱加密，业界推荐尽快从SHA1签署的证书迁移到SHA256签署的证书。

• 使用强壮的密码和TLS协议版本 

  • 禁用 SSLv2 和 SSLv3 协议版本

  • 启用完全正向保密 (PFS) 算法 (ECDHE, DHE (dhparam > 2048))

  • 跟踪漏洞和及时给TLS库(例如OpenSSL)打补丁

参考 Mozilla的服务端TLS 配置 和 https://cipherli.st/ 来寻找优秀的TLS配置实例。

客户端/发送者

• 严格的证书认证。验证邮件交换证书的有效性并且通过服务器呈现的证书中的名字来认证服务器的主机名。在初始化时建议使用一个弱认证方法，这对于登录和监控是十分有用的。（见下文）

• 登录&监控。当连接到一个收据服务器时，它的认证失败的数据会帮助检测是否有网络上的主动攻击。像STARTTLS=false， 邮件交换记录不匹配，和证书认证失败这些登录事件可以用来来达到这个目的

• 时刻通过和根CA证书列表交流来进行数据更新。SMTP客户端，不像浏览器，没有一个标准的机智来更新CA列表。在近几年中，Microsoft和Mozilla修剪了他们的CA列表并且移除了很多过时的根证书。我们的建议是时刻保持CA列表的更新，不管你信任的CA根证书到底是谁

• 证书撤销支持（CRL，OCSP，OCSP封套）。考虑到目前SMTP配置的机会属性，知道现在还没有令人信服的理由去检查服务器呈现的证书是否被撤销。但是这个特性在接下来的几年中也许会变得越来越重要

STARTTLS的使用是非常广泛和普遍的；然而，它近几年的增长放缓了脚步。通过我们的研究，我们发现有着好的/有效的证书的提供者相较其他提供者而言有更好的TLS设置。对于STARTTLS来说，有一个迫切且基本的来保护消息（因此来保护用户）不受到网络上主动攻击侵害的需求。作为需求的基本底线，邮件服务提供者应该努力消除自签名，过期证书的情况并且在SMTP服务器的PFS上使用优秀的加密机制。发送者应该认证证书的有效性和登录认证失败记录，因为失败登录可以提供宝贵的观察并以之来做有效的报告

附录

TLS in the wild: An Internet-wide analysis of TLS-based protocols for electronic communication http://arxiv.org/pdf/1511.00341v2.pdf

No Need for Black Chambers: Testing TLS in the E-mail Ecosystem at Large http://arxiv.org/pdf/1510.08646v2.pdf

Neither Snow Nor Rain Nor MITM… An Empirical Analysis of Email Delivery Security http://conferences2.sigcomm.org/imc/2015/papers/p27.pdf

Analysis of TLS in SMTP World http://www.slideshare.net/BinuRamakrishnan/analysis-of-tls-in-smtp-world

The Current State of SMTP STARTTLS Deployment (2014) https://www.facebook.com/notes/protect-the-graph/the-current-state-of-smtp-starttls-deployment/1453015901605223/

Yep! We Poked all your mail daemons http://www.slideshare.net/SBAResearch/yep-we-poked-all-your-mail-daemons

STARTTLS Everywhere (2014) https://github.com/EFForg/starttls-everywhere

声明：感谢Mike Shema, Elizabeth Zwicky, Suzanne Philion和来自雅虎邮箱（Yahoo Mail Delivery and Paranoids teams）团队的同事们的帮助和贡献