拖延在网站上推出TLS 1.2的企业可能有借口再拖延一段时间了:TLS(传输层安全)1.3版加密协议将在今年晚些时候完成，它的早期部署已经在进行中。
TLS，继任者SSL，用于协商到网络或邮件服务器的安全连接，在移动中的数据进行加密。
六年的酝酿，TLS 1.2增加了新的，更强大的加密选项 - 但保留所有的老，弱加密是曾在向后兼容的名义去之前计划。不幸的是，这意味着有人能够执行中间人攻击往往可以降级到较弱的加密系统连接，无需用户知晓。
这样的攻击是升级到TLS 1.3系统和密码学工程师Filippo Valsorda在内容分发网络Cloudflare部署了TLS 1.3系统。
6月中旬，他在消息传递、恶意软件和移动反滥用工作组(M3AAWG)的一次会议上说:“由于协议的改变，过去两年出现的一些影响TLS 1.2的漏洞不会影响到TLS 1.3。”
TLS 1.3的设计者放弃了导致安全问题的遗留加密系统，只保留了最健壮的加密系统。这种简洁性或许是它能在设计前身的一半时间内完成的原因之一。
Valsorda说，如果一端不支持TLS 1.3，连接仍然会退回到TLS 1.2，但如果MITM攻击者试图强制这样的退回，在TLS 1.3下就会被检测到。
根据Hubert Kario的安全陷阱博客的一项调查，截至今年1月，Alexa的前100万个网站中几乎有93%支持TLS 1.2，而六个月前只有89%。但是100万的7%意味着很多网站仍然在运行更早更不安全的协议。
在这些落后一些网站，你会希望能在安全的顶部：服用在线支付。付款处理器使用的是他们的服务进行升级，以确保TLS版本还敦促网站2018年6月30日前这是支付卡行业安全标准委员会规定的最后期限。
所以，如果你仍然在抖动从SSL升级或早期版本的TLS到最新的东西，为什么不直接去TLS 1.3？
有没有真正的理由不，根据Valsorda。
“我认为这是可行的，现在做的TLS 1.3的部署，”他说。
CloudFlare的去年九月表示，它将提供其内容分发网络的用户TLS 1.3的早期访问。
现在，Valsorda说，“所有免费计划的Cloudflare用户都默认启用了TLS 1.3，我们没有发现任何问题。”
CloudFlare的趋向，使测试，因为这会自动对非付费用户等功能，允许付费用户具有更大或更复杂的网络，以在选择的时候都准备好了。迄今为止，3000个域都选择打开TLS 1.3，除了那些对他们的CloudFlare把它在默认情况下。
在一些小问题的CloudFlare没有遇到原来不被在服务器端，但在客户端。
使用安全设备来监控其用户的网络浏览习惯，结果发现到运行TLS 1.3服务器的连接数组织被撤销，而不警告，阻止访问相关网站。
只发生在被动监视的连接，而不试图将自己插入到连接设备这个问题，Valsorda说。当他们听到一个交流他们不明白 - 如TLS 1.3连接的谈判 - 他们仅仅是把它割下来。有关这两种或三种模式现在已经被他们制造商修补，他说。
测试这种故障的过程仍然主要由人工操作，Valsora说：在运行这种设备的组织需要采取谷歌Chrome浏览器的TLS 1.3兼容的版本，启用TLS 1.3在设置（他描述为“不超过程用户友好“），然后尝试进行连接到支持1.3-TLS网站，如Cloudflare.com。
他补充说:“也许我们应该致力于如何让企业进行更好的测试。”
所以，如果您决定升级到TLS 1.3，它有什么好处呢?
除了自身免疫力在早期版本的攻击，“TLS 1.3具有在连接建立时间方面巨大的性能优势，” Valsorda说。
这是因为谈判的初始加密连接发生在TLS 1.3客户端和服务器之间只有一个往返，相比TLS 1.2两回合人次。这可以节省移动互联网连接在几百毫秒，可能减半下载一些图片的时候，他说。
还有在TLS 1.3被称为0-RTT（零往返时间）恢复不重新协商加密最近使用的连接选项，超速的事情，甚至更多。
很少有web服务器和CDN服务支持TLS 1.3，更少的是0-RTT选项。该网站TLS快了吗?有一个列表。（它的答案，顺便说一句，是“是”。）
SSL和TLS不仅用于web服务器，还用于加密到邮件服务器的连接。
珍妮特·琼斯M3AAWG组旨在防止通信的普遍监测的联合主席，认为TLS 1.3为关键，确保电子邮件对拦截。
“从安全的角度来看，一些行业会喜欢它，”她说。
在另一方面，TLS 1.3的广泛使用是不会讨好政府希望进行监视，或银行需要遵守规章，以防止交易商之间串通。“他们不会有解决方案，看交通，监视它，”她说。
不过，她说，这是没有理由忍住TLS 1.3的部署。
“我希望看到更多我们在进行部署时这个被释放，甚至抢鲜”。