新版TLS 1.3协议的工作即将完成。 经过2018年3月的四年讨论，IETF批准了
草案的
第28版作为拟议标准，因此这应该是采用最终规范之前的最后版本。
TLS 1.3通过结合几个步骤，将建立安全连接的过程加快了大约一半。 此外，它通过临时密钥（EC）DH实现了完美的直接保密机制。 即使在长期密钥受到损害的情况下，此模式也可以确保会话密钥的保护。
还实现了许多其他改进，包括支持ChaCha20流密码，数字签名算法Ed25519和Ed448，密钥交换协议x25519和x448等。删除了对过时的哈希函数MD5和SHA-224，弱且很少使用的椭圆曲线的支持
但是，最有趣的是
IETF正在
讨论的新想法。 Google专家建议定期进行一些细微更改，以随机生成新版本的TLS协议。 这个想法是，频繁的更新将是危险的僵化的解药。
这是什么问题
所谓的“僵化”是指协议开发人员突然意识到由于旧版本的广泛分发而很难进行任何改进，出于某种原因，这种改进适合用户。 实际上，旧版本不再满足现代安全性要求和新规范，但实际上无法实现。
可以
相信 ，所谓的中间节点，即“安全”领域的解决方案供应商，特别是在TLS 1.3的实施中，成为了主要的“刹车”。 他们建议客户在与TLS握手时，使用证书扫描规定
特定的防火墙规则 。 在标准的新版本中，
SSL证书被加密，因此中间人将不再能够对其进行扫描。
持续更新将如何解决协议僵化的问题？
Chrome浏览器熟悉的模式是每六周进行一次连续更新。 在这种情况下，“执行者”
被迫遵守规范，因为不兼容的实现对大部分用户不起作用。
在IETF邮件列表中，Chromium项目的David Benjamin
提出了这个想法。 他写道TLS 1.3是可扩展协议，它与TLS 1.2向后兼容。 它可以逐步滚动，更新TLS 1.2的当前实现。 这里有问题。 许多不兼容的服务器将无法在TLS 1.3 ClientHello阶段建立连接，因此您将不得不回滚以使用支持的协议版本建立连接。
David Benjamin提出了将来如何避免此问题的想法。 在讨论预防措施时，他提到了规范第9.3节中列出的
协议不变式 。 所有端点和中间节点
必须遵守所描述的不变式。 特别是，新客户端和新服务器无权将参数级别降低到旧版本。 同样，当在更新的客户端和服务器之间传输连接时，中间节点无权执行此操作，并且不会影响握手。 但是，鉴于更新速度不均衡，更新后的客户端和服务器可以支持使用旧协议建立通信，但只能以第9.3节中所述的正确方式进行。
但是实践表明，仅在规范中描述所需的行为还不够。 如何
强制中间节点满足ClientHello处理的关键规则-忽略无法识别的参数？ 为此，提出了
GREASE方法。
油脂：抗僵化剂
GREASE（生成随机扩展和可持续扩展性）是一种生成TLS
随机扩展并不断发布协议新版本的方法。 大卫·本杰明（David Benjamin）建议建立一个标准的六周发布周期，该周期将与Chrome新版本的发布相吻合。
大量释放此类“垃圾”将迫使服务器遵守ClientHello处理的关键规则，从而忽略无法识别的参数。 它也将传播到中间节点。 为了使它们不会干扰客户端与服务器之间的通信，它们的关键规则是：如果您未发送ClientHello请求，则您无权处理响应。 同样，生态系统应充满大量此类响应。
“简而言之，我们计划定期标记TLS的新版本（以及可能的其他敏感参数，例如扩展名），”本杰明说，显然表达了Google的观点。 -根据Chrome发布时间表，大约每六周一次。 然后，Chrome，Google的服务器以及所有想参与的人都将支持TLS 1.3的两个（或更多）版本：标准稳定版0x0304和临时替代版本。 每六周，我们会随机选择一个新的代码点。 在所有其他方面，这些版本与1.3相同，唯一可能的例外是用于分隔键和进行允许的语法更改的次要细节。 目的是通过模仿它们来为将来的TLS版本铺平道路（草稿为负数）。”
这种方案具有一定的风险，包括代码点冲突。 另外，应制定预防措施，因为任务是维护和维护TLS的可扩展性，并且不干扰协议的开发。 通过预防措施：
- 所有代码点的详细文档（一个月半的时间里计算出一个点，就可以使用7000多年了）。
- 主动避免冲突：拒绝IETF可能选择的号码。
- 默认情况下，BoringSSL不会启用此选项。 仅在服务器和浏览器中可以禁用的地方启用它。 实际上，很可能在每个时间点仅使用最后几个代码点。 由于它们的变化迅速，因此不应将生态系统附加到任何此类临时扩展上，并且实现方案将彼此保持兼容。
- 如果由于某种原因该方法不起作用，则可以随时停止实验。
这个想法很有趣，如果Google开始以这种方式采取行动，由于“安全”和其他特定公司系统领域的解决方案供应商，它确实可以使生态系统免受危险的“僵化”。 Cloudflare的代表
支持该提议。 他说，无论如何，至少需要做一些事情来避免我们在尝试实现TLS 1.3时遇到的问题。 IETF工作组的另一位成员
称其为“奇妙的想法”，并建议Google创建一个Wiki页面，描述其将来使用或计划使用的代码点。
