Debian 瞻前微软顾后：安全改进是否会产生负面影响？

Linuxeden 开源社区 --

在许多互联网领域，尤其是 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 支持到底是好是坏还真不好说。让我们静观其变吧！

来源：SSL 中国

The post Debian 瞻前微软顾后：安全改进是否会产生负面影响？ appeared first on Linuxeden开源社区.

http://ift.tt/2wKVQRv