英文原文：
A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)
过去5年来，国际互联网工程任务组(IETF)一直致力于标准化传输层安全协议(TLS)的最新版本，这个协议是任务组旗下最重要的安全协议之一，而IETF是定义互联网协议的标准机构。TLS用于保护web(还有更多!)，提供加密并确保每个HTTPS网站和API的真实性。TLS的最新版本TLS 1.3 (RFC 8446)今天发布。这是该协议的首次重大修订，带来了重大的安全和性能改进。本文将深入探讨TLS 1.3中引入的更改及其对internet安全的未来的影响。
An evolution
Cloudflare所提供安全性的一个主要方式是在网站和API等Web服务上支持HTTPS。使用HTTPS（“S”代表安全的），你的浏览器和服务器之间的通信将通过加密和经过身份验证的通道传输。 通过HTTPS而不是HTTP提供内容可以让访问者确信他们所看到的内容是由合法内容所有者给出的，并且通信是安全的，不会被窃听。在这个世界里，在线隐私比以往任何时候都更加重要，这确实是一件大事情。
使HTTPS安全的后台机制是一种称为TLS的协议。它源于九十年代中期在Netscape上开发的称为安全套接字层（SSL）的协议。 到20世纪90年代末，Netscape将SSL移交给IETF，IETF将其重命名为TLS，并从此成为该协议的管理者。许多人仍将Web加密称作SSL，即使绝大多数服务已切换到仅支持TLS。SSL这个术语继续受到人们的欢迎，而Cloudflare通过Keyless SSL和Universal SSL等产品名称使这个术语保持着活力。
在IETF中，协议被称为RFC。TLS 1.0是RFC 2246，TLS 1.1是RFC 4346，TLS 1.2是RFC 5246。现在，TLS 1.3将发布为RFC 8446.。RFC通常按顺序发布，保留46作为RFC编号的一部分是一个很好的体验。
TLS 1.2穿着降落伞裤和垫肩
在过去的几年里，TLS遇到了很多问题。首先，实现TLS协议的项目代码问题蛮多，包括Heartbleed、BERserk、goto fail等。这些问题大部分不能归因于协议的逻辑基础，往往由于项目本身缺乏测试。TLS Attacker和Project Wycheproof等工具帮助提高了TLS实现的健壮性，但TLS面临的更具挑战性的问题必须靠协议本身来解决。
TLS是由工程师使用数学工具设计出来的。很多SSL时代的早期的设计决策都基于启发式方法，而且在不完全理解如何设计健壮的安全协议的情况下。也就是说，这不是协议设计者的错（Paul Kocher， Phil Karlton， Alan Freier， Tim Dierks， Christopher Allen 等人），由于整个行业都还在学习如何正确地做到这一点。在设计TLS的时候，关于如何设计安全身份验证协议的正式论文，如Hugo Krawczyk 的里程碑式的SIGMA论文的出现，还是许多年后的事了。TLS是90年代的加密技术：在当时它是很出色的，而且看起来很酷，但是现代加密技术的设计风格已经发生了变化。
很多设计缺陷都是使用形式验证（formal verification）发现的。学者们尝试证明TLS的完全安全特性，反而却发现了一些反例，变成了真正的漏洞。这些缺陷遍布了纯理论的漏洞（SLOTH 和 CurveSwap），到资源丰富的攻击者的可行漏洞（WeakDH, LogJam, FREAK, SWEET32），再到可实现的重大危险漏洞（POODLE, ROBOT）。
TLS1.2有点慢
加密在网络上一直都很重要，但是历史上它仅用于像登录或者发送信用卡信息之类的数据，而大多数其他数据都是明文暴露的。近年来，对网络上所有的通信都使用HTTPS已经成为了主流趋势。这对保护我们在网络上更多的数据避免窃听和注入攻击有积极影响，但是缺点就是这种新连接有点慢。
为了让浏览器和web服务器协商秘钥，他们需要交换密码数据。这个交换，在TLS中称为“握手”，这个过程从1999年TLS标准化以来一直保持不变。在加密数据发送之前（或者重新开始之前的连接的时候），握手在浏览器和服务器之间需要两次额外的往返交互。与单独使用HTTP通信相比，HTTPS中的TLS握手产生的额外代价会对延迟产生明显的影响。这种额外的延迟会对以性能为主的应用产生负面影响。
其它翻译版本 (1)
加载中
定义TLS1.3
由于对TLS 1.2过时设计和经常性的两次往返开销的不满，IETF开始定义一个TLS的新版本。在2013年8月，Eric Rescorla 为新协议列出了一个特性愿望清单：https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf
经过一些讨论，决定这个TLS的新版本称为TLS 1.3。驱使TLS 1.3的设计的主要问题与5年前的基本相同：
减少握手等待时间
加密更多的握手
改善跨协议攻击的弹性
删除遗留特性
该规范是由志愿者通过开放式设计过程形成的，经过4年的辛勤工作和激烈的辩论，已经形成了TLS 1.3的最终格式：RFC 8446。随着越来越多的使用，新协议将使互联网更快、更安全。
在这篇文章中，我将重点介绍与之前版本相比TLS 1.3的两个主要优点：安全性和性能。
修枝剪叶
在过去的二十年中，我们作为一个社会已经学到了很多关于如何编写安全加密协议的知识。从POODLE到Lucky13到SLOTH到LogJam的巧妙命名攻击的出现表明，即使是TLS 1.2也包含了加密学设计早期的陈旧观点。TLS 1.3的设计目标之一是通过移除潜在危险的设计元素来纠正之前的错误。
固定秘钥交换
TLS是一种所谓的“混合式”加密系统。也就是说它既使用了对称秘钥加密（加解密的秘钥相同），还使用了公钥秘钥加密（加解密秘钥不同）。混合体系是在互联网上加密的主要形式，用于 SSH, IPsec, Signal, WireGuard 和其他协议。在混合加密系统中，公钥加密用于在两端之间建立一个共享秘钥，然后使用共享秘钥创建对称秘钥，然后它就可以用于加密交换的数据。
一般来说，公钥加密不仅慢开销还大（每个操作微秒到毫秒级），而对称秘钥加密快且开销小（每个操作纳秒级）。由于混合加密体系对开销大的操作只做一次，因此它可以让你在极小的开销下发送大量加密数据。在TLS 1.3中大量工作都是关于改善握手部分，而使用公钥建立对称秘钥就处于这个阶段。
RSA秘钥交换
TLS的公钥部分的作用就是建立一个共享秘钥。通过公钥有两种主要方式可以达成这个目的。简单点的方法是使用公钥加密：一方使用另一方的公钥加密共享秘钥然后直接将其发送出去。然后另一方使用它的私钥解出共享秘钥然后…瞧！他们都有了相同的秘钥。这个技术是Rivest，Shamir和Adelman在1977年发现的，因此称其为RSA秘钥交换。在TLS的RSA秘钥交换中，共享秘钥由客户端来决定，然后将其使用服务端的公钥（从证书导出的）加密，然后发送给服务器。
TLS中使用的其他秘钥交换的形式是基于另一种公钥加密的形式，它是由Diffie和Hellman在1976年发明的，因此成为Diffie-Hellman秘钥协议。在Diffie-Hellman协议中，客户端和服务器都会创建一个公私钥对，由此作为开始。然后他们将公钥部分发送给另一方。当每一方都收到了对方的公钥，他们使用各自的私钥将其组合，并以相同的值作为结尾：即 pre-master secret。然后服务器使用数字签名来保证交换的数据没有被篡改。如果客户端和服务器在每一个数据交互中都选择一个新的秘钥对，这种秘钥交换则称为“临时秘钥（ephemeral）”。
本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。
2KB翻译工作遵照
CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。
2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务
