本文主要是介绍Debian瞻前 微软顾后：安全改进是否会产生负面影响？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
在许多互联网领域，尤其是Web PKI和SSL/TLS行业中，我们大多生活在过去的决定中。脆皮密码、差强人意的协议设计以及不怎么标准的软件始终牵绊着前进的步伐。往往一个新操作系统或库的问世都会迅速被大量使用，然后整个生态系统需要花上很多年的时间处理各种遗留的设计缺陷。
随着互联网规模和重要性的增长，我们试图做出更明智的决定，以避免或至少缩短这一周期。最近，两个操作系统进行了更新，反映了两种不同的保持生态健康的做法：
Debian推动了其预发行版本的更改，将只支持TLS 1.2；而微软则开始在Windows Server 2008添加TLS 1.2支持。
这两个选择代表了相反的观点 - 一个展望未来，另一个回顾过去。
Debian发布了一个新版本的OpenSSL库，用于其不稳定的构建 - 一个包含最新版本的开发版本，且仅支持TLS1.2。这种非主流操作真的很少见——目前只有Mozilla的“Modern”配置设置才推荐使用TLS 1.2。
保持OpenSSL库的长期Debian开发人员Kurt Roeckx写道：“我希望Buster发布对TLS 1.2的支持将足够高，不需要再次启用[TLS 1.0和1.1]。 ”
Buster是Debian 10的代号，它是Linux发行版的下一个主要版本。没有宣布发布日期，但距离上一个版本的发布已经超过一年了。
对于只想使用旧版本的人，Roeckx并不留情，他说：“强烈建议你添加对TLS1.2的支持，或让对方添加支持。”
或许等到Buster发布的那天，仅支持TLS1.2不再是骚操作或大胆的配置。但熟悉SSL / TLS和Web PKI的人士都知道，我们都是晚期拖延症患者，要落实一个功能，只会晚不会早。
比方说，微软刚刚向其老化的Windows Server 2008平台添加了TLS 1.1和TLS 1.2支持。
表面上看，添加对优化版TLS的支持是件好事。但如果我们细看Server 2008的其他TLS功能，缺陷是显而易见的：
- 没有AES GCM支持
- 没有AEAD密码
- 没有SNI（服务器名称指示）支持
- 没有OCSP Stapling支持
这不是一个非常有吸引力的HTTPS服务器。可能你今天就不想用，更别提三年后了。
Windows Server 2008（使用IIS 7）至2020年仍处于扩展支持阶段。但为什么现在添加TLS 1.2？
从2018年6月开始，你将不得不支持TLS 1.1或更高版本的PCI兼容性。微软在其任何一篇关于添加TLS 1.2的博文中都没有提到PCI。它表示，它想要删除“弃用旧的安全协议”的障碍，并致力于“一流的加密”。
但是，如果更好的安全性是真正的目标，为什么微软忽略增加其他现代功能？为了公平起见，Windows Server 2008的TLS支持不是过于差劲。由于ECDHE支持，它至少具有PFS（完全正向保密）密码。
有时候，强行优化一个老系统可能会带来更多安全和生态上的落差。因为它使企业和用户有借口坚持早就该被替换或升级的系统。
这也是为什么去年Chrome把整个Diffie-Hellman密码类都移除掉的部分原因。尽管它可以只保留支持更强的2048位参数，直接取消全部更为简单安全。
Debian放出的仅支持TLS1.2的消息可能不是最终决定，但这种胆识确实值得赞许。与此同时，在Server 2008里添加TLS1.1和TLS1.2支持到底是好是坏还真不好说。让我们静观其变吧！
这篇关于Debian瞻前 微软顾后：安全改进是否会产生负面影响？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
