修复POODLE并删除不安全的降级
POODLE的修复程序是：
1、禁用客户端或服务器上的SSLv3
2、启用SCSV新的TLS功能。
SCSV是Bodo Moller和Adam Langley在POODLE之前的几个月提出。简而言之，由于网络错误而重试，客户端通过SCSV将名为“ downgrade canary”的指标添加到客户端hello消息中。如果服务器支持新版本，而不是在客户端所宣传的hello，并且能看到downgrade canary，它可以假定降级攻击发生并关闭连接。这是一个很好的功能，但它是可选的，需要对客户机和服务器都进行更新，从而使许多Web用户暴露。
浏览器立即删除了对SSLv3的支持，除了打破一些只有SSLv3的网站之外，几乎没有什么影响。使用旧版浏览器的用户必须依赖禁用SSLv3的Web服务器。有些站点已经做到了这一点，但到2017年年底目前为止，通过SSL测量的10%站点仍然支持SSLv3。
关闭SSLv3对于POODLE来说是一个可行的解决方案，因为SSLv3对于Internet来说并不重要。但会有一个问题：如果TLS 1.0存在严重的漏洞，会发生什么？目前TLS 1.0仍被广泛使用，在浏览器关闭它将锁定约10%的用户。而且，尽管不安全的scsv降级个好的解决方案，许多服务器不支持。确保用户对TLS 1.0未来的安全问题，唯一选择是禁用不安全的后备。
由于客户端不得不重新连接多次，经过多年的不良表现，大部分没有实现版本协商的网站都正确地固定了服务器。这使得一些浏览器可以消除这种不安全的后备：
2015年的Firefox和2016年的Chrome。因此，如果发生新的TLS 1.0漏洞，Chrome和Firefox用户现在处于更安全的位置。
由于客户需要多次重新连接，经过多年的不良表现，大多数没有实现版本协商的网站都正确地修复了他们的服务器。这使得一些浏览器可以消除这种不安全的后备:
2015年的Firefox和2016年的Chrome浏览器。因为新的TLS 1.0漏洞，Chrome和Firefox的用户现在处于更安全的位置。
引入新版本
设计一个未来兼容性的协议是很困难的，如果没有反馈机制，很容易出错。这是TLS版本协商的情况:如果实施错误，只是假设的未来版本，没有什么可以中断的。对开发人员来说，没有任何信号表明实施是有缺陷的，因此错误可以在没有被注意的情况下发生。也就是说，在部署了新版本的协议之前，实现失败了，但是到那时，但是到了代码部署之后，每个人都需要花费数年的时间进行升级。一些服务器实现未能正确处理“未来”版本的TLS，这应该是意料之中的。
TLS版本协商虽然很简单，但实际上是协议设计反模式的一个例子。它证明了协议设计中称为骨化的现象。如果一个协议被设计成一个灵活的结构，但实际上从来没有使用这种灵活性，那么一些实现将假定它是不变的。
在TLS 1.2部署的时候，围绕着一个新版的TLS展开讨论开始。就被称为TLS 1.3，版本号自然选为3.4。到2016年年中，TLS 1.3草案已经历了15次的讨论修改，版本号和结果基本确定。浏览器已经消除了不安全的后备。假设无法正确进行TLS版本协商的服务器，学习了POODLE的教程，并最终正确地实现了版本协商。但事实证明，情况并非如此。
当与3.4版本的客户交流时，很大一部分支持TLS 1.2的服务器会断开连接，而不是回答3.3。HannoBock，David Benjamin，SSL Labs和其他人进行的互联网扫描证实，TLS 1.3的失败率很高，在许多测量中超过3％。这与升级到TLS 1.2时所面临的情况完全相同。历史在重演。
这个意想不到的挫折给参与协议设计的人们带来了不同的危机。浏览者不希望重新启用这种不安全的降级，并且为了在接下来的五年中再次加强协议谈判而进行艰苦的斗争。但是，如果没有降级，使用TLS 1.3将会为用户打破3％的互联网。可以做什么？
有争议的选择是接受David Benjamin的建议，使第一个TLS 1.3消息（客户问候）看起来像TLS 1.2。客户端的版本号被重新改回（3,3），并引入了一个新的“版本”扩展，其中包含了受支持版本的列表。如果支持TLS 1.3和（3,3），则服务器将返回以（3,4）开始的服务器，否则返回之前的值。TLS 1.3草案16版本包含了这个“改进”的协议来协商逻辑。
大部分服务器都可以接受这个变化，而且很容易回到TLS 1.2，忽略了新的扩展。骨化是一个反复无常的现象。它不仅影响客户端和服务器，还会影响网络上与协议交互的所有内容。
本文由GDCA翻译于cloudflare
