[转帖]传输层安全协议真（TLS）的安全吗？

https://zhuanlan.zhihu.com/p/305161227

随着数字通信，计算机网络，公钥密码体制等技术的迅速发展，安全网络通信已经成为了人们的日常需求。TLS 作为目前被广泛应用的安全通信协议之一，被广泛使用于日常生活中，如HTTPS，DNS over TLS等等。

但是作为加密应用HTTPS和DO*的底座，TLS真的安全吗？他能有效的保护我们的隐私吗？

TLS基础

TLS是什么？

传输层安全协议（Transport Layer Security，TLS）：TLS标准由互联网工程任务组（IETF）TLS工作组制定和维护。TLS在TCP/IP协议栈上运行，用于保护web流量（使用HTTPS）、文件传输、电子邮件传输和许多其他应用程序。

很多人最为熟悉的TLS使用场景是用于保护通过超文本传输协议（HTTP）传输的web流量。在HTTPS中，建立SSL/TLS连接（通常在TCP端口443上，与不安全网站的端口80不同），然后HTTP数据通过安全连接传输。
TLS还可用于保护电子邮件传输协议（IMAP和POP，用于客户端从邮件服务器下载邮件，SMTP用于发送邮件），以及文件传输（FTP）。

在这些场景中，不安全连接通过TLS被“升级”为安全连接，用于保护人们的隐私和通信数据安全。

迄今为止，已有两个版本的SSL（SSL v2和SSL v3）和三个版本的TLS（TLS 1.0、TLS 1.1和TLS 1.2）；当前推荐版本TLS 1.3已于2018年8月发布。

TLS历史

TLS的前身是SSL。

SSL协议由Netscape公司开发，历史可以追溯到Netscape Navigator浏览器统治互联网的时代，大约是20世纪90年代。协议的第一个版本从未发布过，

第二版则于1994年11月发布。第一次部署是于1995年3月发行在Netscape Navigator 1.1浏览器上。SSLv2的开发基本上没有与Netscape以外的安全专家进行过商讨，所以有严重的弱点，被认为是失败的协议，最终退出了历史的舞台。

这次失败使Netscape公司专注于SSLv3，并于1995年年底发布。虽然名称与早先的协议版本相同，但SSLv3是完全重新设计的协议。该设计一直沿用到今天。

1996年5月，TLS工作组成立，开始将SSL从Netscape迁移至IETF。由于Microsoft和Netscape当时正在为Web的统治权争得不可开交，

明说网络：互联网发展简史(5)第一次浏览器大战0 赞同 · 0 评论文章

整个迁移过程进行得非常缓慢、艰难。最终，TLSv1.0于1999年1月问世，见RFC 2246。尽管与SSLv3相比，TLSv1.0版本修改并不大，但是为了取悦Microsoft，协议还是进行了更名。

直到2006年4月，下一个版本TLS 1.1才问世，仅仅修复了一些关键的安全问题。然而，协议的重要更改是作为TLS扩展于2003年6月发布的，并被集成到了协议中，这比大家的预期早了好几年。

2008年8月，TLS 1.2发布。该版本添加了对已验证加密的支持，并且基本上删除了协议说明中所有硬编码的安全基元，使协议完全弹性化。

当前最新版本的TLS协议是，2018年由IETF正式发布TLSv1.3。

协议
--------	-----------	------------------------------------------------------------
SSL 1.0	Unpublished	Unpublished
SSL 2.0	1995	Deprecated in 2011
SSL 3.0	1996	Deprecated in 2015
TLS 1.0	1999	Deprecated in 2020
TLS 1.1	2006	Deprecated in 2020, in 2021 Chrome will not load websites with TLS 1.0 or 1.1.
TLS 1.2	2008
TLS 1.3	2018

TLS组成协议

TLS的主规格说明书定义了四个核心子协议：

握手协议（handshake protocol）
密钥规格变更协议（change cipher spec protocol）
应用数据协议（application data protocol）
警报协议（alert protocol）。

出于加密目的，两个最重要的子协议是握手协议和记录层协议。

SSL握手协议

握手是TLS协议中最精密复杂的部分。在握手协议中，客户机和服务器商定一组称为密码套件的加密参数，交换身份验证凭据，建立共享机密，执行显式身份验证，并派生用于批量加密和消息验证的密钥。

Figure 1.3.1: 握手协议

握手过程分为4个阶段：

初始化逻辑连接，客户方先发出ClientHello消息，服务器方也应返回一个ServerHello消息，这两个消息用来协商双方的安全能力，包括协议版本、随机参数、会话ID、交换密钥算法、对称加密算法、压缩算法等。

clienthello消息示例

密码套件名称构成

服务器方应发送服务器证书Certificate（包含了服务器的公钥等）和服务端会话密钥(Server key exchange)，如果服务器要求验证客户方，则要发送Certificate Request消息。最后服务器方发送Server Hello Done消息，表示hello阶段结束，服务器等待客户方的响应。
如果服务器要求验证客户方，则客户方先发送客户端证书Certificate消息，然后产生客户端会话密钥，并用服务器的公钥加密，封装在Client Key Exchange消息中，如果客户方发送了自己的证书，则再发送一个数字签名Certificate Verify来对证书进行校验。
客户方发送一个Change Cipher Spec消息，通知服务器以后发送的消息将采用先前协商好的安全参数加密，最后再发送一个加密后的Finished消息。服务器在收到上述两个消息后，也发送自己的Change Cipher Spec消息和Finished消息。至此，握手全部完成，双方可以开始传输应用数据。

会话恢复

完整的握手协议非常复杂，需要很多握手消息和两次网络往返才能开始发送客户端应用数据。此外，握手执行的密钥学操作通常需要密集的CPU处理。因此建立一次握手的代价很昂贵，于是短时间中断的连接可以使用会话恢复快速恢复。

最初的会话恢复机制是，在一次完整协商的连接断开时，客户端和服务器都会将会话的安全参数保存一段时间。希望使用会话恢复的服务器为会话指定唯一的标识，称为会话ID。服务器在ServerHello消息中将会话ID发回客户端。希望恢复早先会话的客户端将适当的会话ID放入ClientHello消息，然后提交。服务器如果愿意恢复会话，就将相同的会话ID放入ServerHello消息返回，接着使用之前协商的主密钥生成一套新的密钥，再切换到加密模式，发送Finished消息。客户端收到会话已恢复的消息以后，也进行相同的操作。这样的结果是握手只需要一次网络往返。

简短握手，用于恢复已经建立的会话

TLS中的密码交换算法

使用哪一种密钥交换由协商的套件所决定。

记录层协议

记录层协议提供TLS中所有消息的传递，包括握手协议消息和应用程序数据，但特别是记录层协议可以选择使用身份验证和加密来保护消息。

SSL记录协议从高层接收到数据后要经过分段、压缩和加密处理，最后由传输层发送出去。在SSL协议中，所有的传输数据都被封装在记录中，SSL记录协议规定了记录头和记录数据的格式。

总之，经过上述两个协议，客户端和服务器通过公钥密码体制协商通信时使用的对称加密体制秘钥，然后使用对称加密体制对通信数据进行加密处理。这样，通信数据就可以“安全”的在网络中进行传输。

其他协议

当然了，除了上述最重要的两个协议之外，还有一些其他的协议，例如警告协议，心跳协议等等。

警报的目的是以简单的通知机制告知对端通信出现异常状况。发送警告通知的一端不会主动终止连接，而是交由接收端通过发送它自己的严重警报对该警告自行作出反应。

心跳（Heartbeat）是一个协议扩展，添加了支持连接保活的功能（检查对端是否仍然可用），以及为TLS和DTLS发现路径最大传输单元（path maximum transmission unit, PMTU）

SSL/TLS安全吗？

TLS 的发展有 20 多年的历史，在之前的版本中，TLS 1.2 是高度可配置的，为了更好的兼容旧版本的浏览器，这意味着那些易受攻击的站点始终在运行着旧的安全协议及不安全的加密算法，这让黑客有可乘之机。

协议漏洞

经典攻击

以下是TLS/SSL协议中的主要漏洞。它们都会影响协议的旧版本（TLSv1.2及更早版本）。

POODLE（Padding Oracle On Downgraded Legacy Encryption）,(CVE-2014-3566)
BEAST（Browser Exploit Against SSL/TLS ）(CVE-2011-3389)
CRIME (Compression Ratio Info-leak Made Easy) (CVE-2012-4929)
BREACH（Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext） (CVE-2013-3587.)
Heartbleed (CVE-2014-0160.)

详细的一些介绍看这里[这里[1]]:

Examples of TLS/SSL Vulnerabilities TLS Security 6: | Acunetixwww.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/

不安全因素

这些主要漏洞中，的一些不安全的因素：

RSA 密钥传输 —— 不支持前向安全性
CBC 模式密码 —— 易受 BEAST 和 Lucky 13 攻击
RC4 流密码 —— 在 HTTPS 中使用并不安全
SHA-1 哈希函数 —— 建议以 SHA-2 取而代之
任意 Diffie-Hellman 组—— CVE-2016-0701 漏洞
输出密码 —— 易受 FREAK 和 LogJam 攻击

部署安全

虽然SSL/TLS协议用于保护数据传输，但配置不当的服务器可能会暴露数据而不是保护数据。

中间人攻击：如middlebox（如部分杀毒软件会作为中间人，解密用户数据，进行恶意审查；不安全的CA及不可验证的数字证书链等）的广泛部署
误配置：如使用已经被证明不安全的协议（TLSv1.1之前的版本），支持不安全的密码套件（RC4，MD5等）等。

根据SSL Labs的统计信息，如下图所示，即使许多的SSL/TLS已经被证明不安全，但是由于各种原因，例如管理员疏忽、配置错误、机器升级障碍等问题，目前仍然存在大量不安全的SSL/TLS协议在使用当中。

Figure 2.2.1: SSL Labs统计信息

信息泄露

经典的公钥基础设施PKI(public key infrastructure)设计，认为一个服务器只提供一个服务从而也就只使用一个证书。但随着HTTP 服务器开启虚拟主机支持后，一台服务器(同一个IP)通常提供多个域名服务。

如下图所示，当需要与部署多个站点的服务器通信时，握手时并不知道选择哪个站点的证书。

为此，TLS1.2中添加了一个字段 SNI (Server Name Indication)，用于标识访问一个服务器上哪个域名提供服务，详细信息可以参考：

SNI(Server Name Indication)blog.csdn.net/makenothing/article/details/53292335

Server Name Indication(SNI)www.cnblogs.com/talenth/p/5820136.html

但是TLS1.2中的SNI字段是不加密的，这就泄露了想要访问的网站的域名信息。因此在TLS1.3中，加密了这个字段。

TLS1.3提供了一个可选项，允许客户端加密SNI(ESNI)，但是这种方法并没有被广泛采用，使用加密SNI的用户本身就比较可疑。正由于这个原因，审查者发现含有ESNI的TLS握手包，直接丢弃即可。

防御方法

在大多数情况下，保护自己免受SSL/TLS相关攻击的最佳方法是禁用旧的协议版本。这甚至是一些行业的标准要求。例如看看下面几个业界的动态就知道低版本 TLS 的现状了。

GitHub 于 2018 年 2 月 1 日起，禁用 TLSv1 和 TLSv1.1。
Salesforce 于 2018 年 3 月逐步禁用 TLSv1。
微信小程序要求的 TLS 版本必须大于等于 1.2。
为了符合支付卡行业数据安全标准（PCI DSS）并符合行业最佳实践，GlobalSign 将在 2018 年 6 月 21 日禁用 TLS 1 和 TLS 1.1 。

选择的协议级别越高，相应的也就更安全。

同时，将目前计算机上部署的TLS版本更新到最新，可有效防止此类问题，目前安全的版本为TLSv1.3。

TLSv1.3

下图是TLS完整的握手过程

Figure 3.1: SSL Labs统计信息

与TLSv1.2主要的不同，TLSv1.3进行了很多改进，改进力度还是比较大。如上图所示，握手过程明显比TLS之前版本更少的握手次数，，甚至是0次（zero round trip time (0-RTT)）可以更快的建联，简化了握手机制。

同时，不再兼容一些不安全的密码算法，甚至是不安全的前向兼容.

总结

总的来说，当前TLS是广泛使用的安全通信协议，安全性在整个互联网界的共同努力下，逐步提升，可以保证用户数据和隐私的安全。但是由于其历史、兼容性、实现以及部署等原因，在实际使用过程中产生了一些安全的问题，但是很快就会被打上补丁。因此，只要能够及时打上TLS的补丁，升级支持最新版的协议，禁用旧的版本，就能够有效地保护数据隐私和通信安全。

参考资料

《HTTPS权威指南：在服务器和Web应用上部署SSL/TLS和PKI》