皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

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

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支持到底是好是坏还真不好说。让我们静观其变吧!

来源:SSL中国