年初，在一份关于2018-2019年互联网问题和可达性的报告中 TLS 1.3 的传播是不可避免的。 前段时间，我们自己部署了传输层安全协议1.3版本，在收集和分析数据之后，我们终于准备好谈论这个过渡的特点。
IETF TLS 工作组主席 :
“简而言之，TLS 1.3 应该为未来 20 年更安全、更高效的互联网奠定基础。”
进入菜单 花了10年的时间。 我们 Qrator Labs 以及业界其他公司从最初的草案开始就密切关注协议创建过程。 在此期间，需要连续编写28个版本的草案，才能最终在2019年看到一个平衡且易于部署的协议。 市场对 TLS 1.3 的积极支持已经显而易见：实施经过验证且可靠的安全协议满足了时代的需求。
Eric Rescorla（Firefox 首席技术官兼 TLS 1.3 的唯一作者）表示 :
“这是 TLS 1.2 的完全替代，使用相同的密钥和证书，因此客户端和服务器如果都支持 TLS 1.3，就可以自动通过 TLS 1.3 进行通信，”他说。 “库级别已经有了很好的支持，Chrome 和 Firefox 默认启用 TLS XNUMX。”
与此同时，IETF 工作组中的 TLS 也即将结束 ，声明旧版本的 TLS（仅不包括 TLS 1.2）已过时且无法使用。 最终的 RFC 最有可能在夏末之前发布。 这是向IT行业发出的又一个信号：加密协议的更新刻不容缓。
Github 上提供了当前 TLS 1.3 实现的列表，供任何寻找最合适库的人使用： 。 显然，对更新协议的采用和支持将会而且已经在迅速进展。 对现代世界中基本加密的理解已经广泛传播。
自 TLS 1.2 以来发生了哪些变化？
的 :
“TLS 1.3 如何让世界变得更美好？
TLS 1.3 包含某些技术优势（例如建立安全连接的简化握手过程），并且还允许客户端更快地恢复与服务器的会话。 这些措施旨在减少弱链接上的连接设置延迟和连接失败，这通常被用作仅提供未加密的 HTTP 连接的理由。
同样重要的是，它取消了对几种旧版且不安全的加密和哈希算法的支持，这些算法仍然允许（尽管不推荐）与早期版本的 TLS 一起使用，包括 SHA-1、MD5、DES、3DES 和 AES-CBC。添加对新密码套件的支持。 其他改进包括对握手的更多加密元素（例如，证书信息的交换现在已加密），以减少潜在流量窃听者的线索数量，以及在使用某些密钥交换模式时改进前向保密性，以便通信即使用于加密的算法将来受到损害，也必须始终保持安全。”
现代协议和 DDoS 的开发
正如您可能已经读到的，在协议的开发过程中 ，在 IETF TLS 工作组中 。 现在很明显，各个企业（包括金融机构）必须改变他们保护自己网络的方式，以适应该协议现在内置的 .
文件中列出了可能需要这样做的原因， 。 这份长达 20 页的论文提到了几个示例，其中企业可能希望解密带外流量（PFS 不允许），以实现监控、合规性或应用层 (L7) DDoS 保护目的。
虽然我们当然不准备猜测监管要求，但我们专有的 DDoS 缓解产品（包括解决方案） 敏感和/或机密信息）是在 2012 年创建时考虑到 PFS 的，因此我们的客户和合作伙伴在服务器端更新 TLS 版本后无需对其基础设施进行任何更改。
此外，自实施以来，尚未发现与传输加密相关的问题。 官方消息：TLS 1.3 已准备好投入生产。
然而，下一代协议的开发仍然存在一个问题。 问题在于，IETF 中的协议进展通常严重依赖于学术研究，而缓解分布式拒绝服务攻击领域的学术研究状况却很惨淡。
所以，一个很好的例子是 IETF 草案“QUIC 可管理性”是即将推出的 QUIC 协议套件的一部分，其中指出“检测和缓解 [DDoS 攻击] 的现代方法通常涉及使用网络流数据的被动测量。”
事实上，后者在真实的企业环境中非常罕见（并且仅部分适用于 ISP），并且无论如何都不太可能成为现实世界中的“一般情况” - 但经常出现在科学出版物中，通常不受支持通过测试所有潜在的 DDoS 攻击，包括应用程序级攻击。 后者，至少由于 TLS 的全球部署，显然无法通过网络数据包和流量的被动测量来检测。
同样，我们还不知道 DDoS 缓解硬件供应商将如何适应 TLS 1.3 的现实。 由于支持带外协议的技术复杂性，升级可能需要一些时间。
设定正确的目标来指导研究是 DDoS 缓解服务提供商面临的主要挑战。 可以开始开发的一个领域是 在 IRTF，研究人员可以与业界合作，完善自己对具有挑战性的行业的知识，并探索新的研究途径。 我们还热烈欢迎所有研究人员，如有任何与 DDoS 研究或 SMART 研究小组相关的问题或建议，请联系我们：
来源： habr.com