如果还没升级到 TLS 1.2，准备好直接跨越式升级吧。
迟迟不愿在网站上应用 TLS 1.2 的公司企业，现在有借口可以再推迟一些时候了：TLS 1.3 加密协议将于今年晚些时候最终定版，其早期部署也已展开。
作为SSL的继任者，TLS被用于与Web或邮件服务器交涉安全连接，在传输过程中对数据加密。
长达6年的酝酿过程中，TLS 1.2 加入了新的更强的加密选项，但在向下兼容的名义下，也保留了所有老旧脆弱的加密方案。很不幸，这意味着中间人攻击往往能在用户不知情的情况下，将连接降级到更弱的加密系统。
其他一系列攻击，比如DROWN、SLOTH和POODLE，也能对SSL下手。
系统和密码学工程师菲利波·瓦尔索达在内容交付网络Cloudflare上部署了 TLS 1.3 系统。他认为，上述攻击就是升级到 TLS 1.3 的绝佳理由。
6月中旬的“消息、恶意软件和移动反滥用工作组(M3AAWG)”会议上，他说：“过去2年出现的影响 TLS 1.2 的漏洞，将不会影响到 TLS 1.3，因为该协议改变了很多。”
TLS 1.3 的设计者们选择抛弃引发诸多安全问题的遗留加密系统，仅保留那些最健壮的。该简洁性或许就是其设计周期比 TLS 1.2 缩短一半的原因之一。
如果其中一端没有实现 TLS 1.3，连接也将会落回到 TLS 1.2；但如果中间人攻击者试图强制降级，在 TLS 1.3 实现下将会被检测出来。
今年1月，Alexa榜单上排名前100万的网站中，有93%支持的都是 TLS 1.2，再往前半年，该比例是89%。但剩下的这7%，意味着还有很多网站实现的是更古早更不安全的协议。
这些落后者中有一些是你希望安全度最高的：执行在线支付的那些。支付卡行业安全标准委员会设置了2018年6月30日，是在线支付网站升级至TLS安全版本的最后期限。
所以，如果还对从SSL或更早版本的TLS升级至最新版摇摆不定，不如直接一步到位，上 TLS 1.3。
真没什么其他理由不那么做。
“现在真的非常适合部署 TLS 1.3。”
去年9月，Cloudflare称其内容交付网络将用 TLS 1.3 协议访问。
如今，所有选择了免费套餐的Cloudflare客户，都默认启用了 TLS 1.3，目前尚未观察到出了任何问题。
Cloudflare倾向于向免费用户自动开启此类测试版功能，而让付费用户有更大或更复杂的网络可以选择。截至目前，除Cloudflare默认开启的以外，还有3000个域名选择了转向 TLS 1.3。
Cloudflare确实遭遇到一些小故障，但都不是服务器端，而是客户端引发的。
一些企业使用安全设备监测其用户的网页浏览习惯，发现通过 TLS 1.3 到服务器的连接，会在无任何警告的情况下被抛弃，让站点无法被访问。
该问题仅发生在被动监测而不试图插入连接的设备中。只要听到自己不理解的交换，比如 TLS 1.3 连接谈判，这些设备就会简单粗暴地切断了事。有这种问题的两三个型号已经由制造商发布了补丁。
测试此类小故障的过程基本上是人工进行。运行此类设备的公司需要采用兼容 TLS 1.3 的谷歌Chrome浏览器，在不那么用户友好的设置中启用 TLS 1.3，然后尝试连接启用了 TLS 1.3 的网站，比如。Cloudflare.com。
“或许我们应该想出让企业更方便测试的方法。”
如果你确实决定要升级到 TLS 1.3 了，你能得到什么呢？
除了相比前版的攻击免疫力，TLS 1.3 在连接建立时间上还表现出了卓越的性能优势。
这是因为在 TLS 1.3 中，初始加密连接的谈判过程只需要在客户端和服务器间来回一次即可，比 TLS 1.2 的来回2趟省了一半。这在移动互联网连接中就是数百毫秒的时间差，都够缩短某些图片一半的下载时间了。
而且，TLS 1.3 里还有被称为 0-RTT (零来回时间)的选项，可以不用再次加密谈判就恢复最近使用的连接，让连接速度进一步加快。
目前甚少有Web服务器和CDN(内容交付网络)服务支持 TLS 1.3，提供 0-RTT 的就更少了。
SSL 和 TLS 不仅仅用于Web服务器，还可用于加密到邮件服务器的连接。
M3AAWG小组致力于防止通信被广泛监视，其联合主席詹尼特·琼斯，就将 TLS 1.3 视为反窃听安全电子邮件的关键。
“从安全角度书法，有些行业会超级爱它。”
另一方面，推广使用 TLS 1.3 可能会惹想进行监视的政府不太高兴，需要合规以防止交易方勾结的银行估计也不太喜欢它。
不过，这都不是拖住 TLS 1.3 部署的理由。
“在发布，乃至预发布的时候，我希望看到更多成员部署 TLS 1.3。”
还没有评论，来说两句吧...