历经4年，28次易稿之后，互联网安全急需的协议更新终于获得互联网工程任务组(IETF)通过。尽管最后仍有人担心会导致联网噩梦，齐聚伦敦互联网工程师大会的专家们还是通过了TLS 1.3协议。
TLS 1.3获得了一致认可(虽然有一票“不反对”票)，为其在各类软件及产品中的广泛应用铺平了道路。此后，从Oracle的Java到谷歌的Chrome浏览器都将应用该正向加密协议保护用户通信安全。
新协议旨在全面挫败美国国家安全局(NSA)等机构或黑客组织对所截获HTTPS连接和其他加密网络数据包的解密尝试。因其简洁流畅的方式，TLS 1.3 还应能够加速安全通信的实现与推广。
不过，因为该协议太过重要，其进展也就相对缓慢，有时候还伴随着争议与反复。去年这个时候，谷歌暂停了其在Chrome中支持此新协议的计划——因为马里兰州一所IT学校管理员报告称，其管理的5万台Chromebook中有1/3都在进行了相关更新后死机了。
最近，银行和公司企业抱怨称，因为新协议的安全实现方式，他们将无法检查分析流经自身网络的 TLS 1.3 加密流量，这会导致面临更大的攻击风险。
然而不幸的是，解密自身网络中安全流量的能力，也可被第三方用于抓取并解密通信。
向该协议中植入后门的想法遭到了互联网工程师们的鄙视和唾弃，很多互联网工程师指出，这将会引入监视和分析内部网络流量的中间件。
向后门说不
后门提案没有获得通过，意味着整个互联网将变得更加安全快捷，不过银行和类似机构可能就得做些额外的工作来截获并检查 TLS 1.3 连接了。
协议更新与遭到抱怨的重点在两个关键方面：正向加密和瞬时密钥。
TLS即传输层安全，其工作原理是在客户端和服务器之间创建安全连接，比如用户笔记本电脑和公司网站之间。所有这一切都在真实信息共享发生之前完成，比如在信用卡信息或个人隐私信息被传输之前就建立其安全连接。
TSL 1.2 协议之下，这是一个相当冗长的过程，几乎要耗掉半秒钟才可完成：
客户端向服务器发出握手请求，提供一系列自己支持的强加密系统；
服务器回应握手请求，说明自己将使用哪种加密系统，并发来加密密钥；
客户端用该密钥加密，并发回一串随机字符；
服务器与客户端凭此交互创建2个新密钥：一个主密钥和一个会话密钥，主密钥更强，而会话密钥较弱；
然后客户端选定其计划应用较弱会话密钥的加密系统——因为处理过程不甚复杂，用较弱会话密钥会让数据传输更快捷；
服务器接受该选定加密系统，然后客户端和服务器开始真正的信息共享过程。
TLS 1.3 则通过合并其中几步来加速整个过程：
客户端直接在握手请求中指明将使用的加密系统；
服务器回复同意并提供密钥；
客户端回以会话密钥，表示已准备好开始加密会话过程；
除了更快，TLS 1.3 还更加安全，因为它抛弃了 TLS 1.2 支持的多种带漏洞的老旧加密算法。黑客可从这些老旧算法中导出之前用过的密钥（所谓“非正向加密”），解密之前的会话内容。
少点过程多点安全
比如说，骗子在 TLS 1.2 协议下就可以强制交互过程使用他们知道如何破解的更老更脆弱的加密算法。
使用 TLS 1.3 的人就只能采用更难以破解的新加密系统，至少目前难以破解。任何意图采用弱 1.2 体制的交互都会被检测并标记为安全问题。
TLS 1.3 的另一个非常重要的优势（同时也是有些安全专家的顾虑所在），就是所谓的“零往返时延会话恢复( 0-RTT Resumption )”，该功能可使客户端和服务器记住是否曾经交互过，如果曾建立过连接，就可省去所有核查，直接采用之前的密钥立即展开对话。
这必然会加速连接过程，但如果某人能够获得该“ 0-RTT Resumption ”信息，那么会话参与方被冒充的可能性也是存在的。不过，相比 TLS 1.2 可致对话被劫持和窃听，互联网工程师们对1.3的这一安全风险倒不是太在意了——毕竟这需要能够接触到会话方的其中一台机器。
总之，只要能够多加努力令 TLS 1.3 能恰当运行，互联网信息安全就会迎来双赢局面。
最大的输家只会是网络罪犯和情报机构，他们将不能再行安全通信窃听或劫持动作，至少在他们没找出破解 TLS 1.3 的方法之前不行。而到了那个时候，IETF就将开始 TLS 1.4 征程了。
声明：本文来自安全牛，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
