为额外的设备兼容性提供 SSLv2 有哪些风险?

信息安全 tls 风险管理
2021-09-07 00:53:12

SSL 2 于 2011 年被弃用。然而,许多设备是在 2011 年之前制造的,至今仍在使用,并且无法升级设备中的软件(例如手机、平板电脑、PDA、路由器、IP 相机、打印机等)。在设计网络服务时,仅使用 TLS 1.x 限制与客户端的安全连接是不切实际的,因为这会阻止大部分用户。

如果设计良好的网络服务提供 SSL 2 兼容性,今天会有多不安全?设计良好,安全性由多种方法提供,例如 2 因素身份验证、适当的用户权限管理、将用户输入封装在代码中、多次登录失败后自动锁定帐户、正确设置 DMZ 等。这里的关键因素是,如果不提供 SSL 2,则该服务将完全无法访问大部分设备(30~40%),而这些设备本来可以完美运行。

一个示例是用于日常通信的公司电子邮件服务器。敏感信息永远不会在此服务器上传达或存储。此服务器支持所有 SSL/TLS 协议,并可选择禁用较弱的协议。

在服务器上接受 SSL 2 连接到底有什么风险?


编辑:这不是关于 SSLv2 如何不安全或为什么不应该使用的问题。它涉及与提供 SSLv2 作为设备兼容性的附加支持协议相关的业务风险。涉及的设备有:

  1. 功能完善。
  2. 仅支持 SSLv2。没有可能的软件升级路径,因为它们不是计算机。
  3. 这些设备上唯一的其他选择是明文传输。
  4. 代表使用该服务的设备的大多数(或不可忽略的部分)。

我正在评估是否更换所有设备,或者继续使用它们,但以相对不安全的方式。因此,这是一项业务风险管理决策。但是我必须首先了解提供 SSLv2 的业务风险。

4个回答

SSL 2 已于 2011 年弃用

它没有被弃用,它被彻底禁止,这是一个巨大的区别。另请参阅不推荐使用 SSLv3 和禁止 SSLv2 之间有什么区别?

然而,许多设备是在 2011 年之前制造的,并且至今仍在使用

TLS 1.0 是在 1999 年定义的,并且从大约这个时候开始在主要的 TLS 堆栈(包括 openssl)中可用。不支持它在 2011 年已经不是一个选项。

如果设计良好的网络服务提供 SSL 2 兼容性

这是一种自相矛盾的说法:精心设计与提供 SSLv2 兼容性。在网络上拥有 SSLv2 设备不仅因为 SSLv2 协议本身是不安全的,而且还因为任何不能说比 SSLv2 更好的旧设备很可能也想使用弱密码

如果不提供 SSL 2,则该服务将完全无法访问大部分设备(30~40%),而这些设备本来可以完美运行。

根据环境的不同,您可以通过在前面添加一些软件来保护此类设备,以便它们可以使用更好的协议和密码。

一个示例是用于日常通信的公司电子邮件服务器。

如果这个服务器只支持 SSLv2,那么它一定是旧的,它有很多其他的漏洞TLS 1.0 已经在 Windows XP 中可用。

在服务器上接受 SSL 2 连接到底有什么风险?

虽然只有 SSLv2 是不好的,但除了其他协议之外还有 SSLv2 是不好的。有关SSLv2 的可用性如何帮助解密正确加密的连接的详细信息,请参阅DROWN 攻击

总而言之:
如果所有这些都是在您没有恶意活动的某个受限网络中完成的,那么使用 SSLv2 可能是完全安全的,就像纯文本一样。但是,一旦您有可能有人攻击网络,您就需要处理由不安全的 SSL 版本 ( DROWN ) 和 SSL 堆栈的年龄(弱密码)以及一般软件问题(即过时且可能易受攻击的软件)。

所有其他答案似乎都缺少的领域是,在实际中使用 SSLv2 的相对安全性(或缺乏安全性)取决于它们将在其中使用的环境的威胁模型。

所以每个人都会同意 SSLv2 是一个弱协议(来自无与伦比的 Leek 先生的更多技术细节在这里。基本上,使用 MITM 的攻击者会更喜欢攻击使用 SSLv2 建立的连接,并且在它使用较弱密码的情况下,攻击者可以查看连接中的流量可能能够更轻松地解密它。无论哪种情况,公平地说这仍然不是低端攻击,对 SSL 的 MITM 攻击并非易事,即使是相对较弱的密码也需要解密有点努力。在民族国家的攻击水平范围内,但通常不在临时或低端攻击者的范围内

除此之外,我们还有 DROWN,但关键点是,它仅适用于另一台服务器使用与运行 SSLv2 相同的私钥的情况。

那么这会让我们回到哪里,回到你的威胁模型。谁是可能想要破坏您的系统的攻击者?

如果我们正在研究高端专业人士或民族国家,可以公平地说 SSLv2 不应该以任何方式出现在卡片上,因为它的弱点很可能会被这些攻击者利用

但是,如果您的担忧更多是关于临时或低端攻击者很容易访问传输中的数据(也许它是通过有其他用户的无线网络传输的),那么实际上我认为您不太可能得到通过对 SSLv2 的攻击而受到损害

在这些情况下,最大的实际业务风险可能是,从合规性的角度来看,这看起来不太好,而且如果您聘请安全顾问,他们会将其标记为风险......

除了您的 SSLv2 问题,从现实世界的安全性角度来看,我可能会更担心在这些设备上运行的软件中可能存在的漏洞,因为听起来您将无法为它们获取安全补丁。 ..

如果设计良好的网络服务提供 SSL 2 兼容性,今天会有多不安全?

正如其他人所提到的,极度不安全。如果数据真的像您声称的那样不重要,并且您绝对必须支持那些过时的设备,那么您最好只允许与 60% 的最新客户端的安全 TLS 连接,并使用纯文本连接其他 40% 无论如何都是不安全的。

这样,当连接受到破坏时,您只会受到 40% 的清理损失......额外的好处是升级旧设备会有更好的举措,因为人们不会(错误地)认为有“在SSL2 至少有一些安全性”(没有)。

编辑:这不是关于 SSLv2 如何不安全或为什么不应该使用的问题。它涉及与提供 SSLv2 作为设备兼容性的附加支持协议相关的业务风险。涉及的设备有:

  1. 功能完善。
  2. 仅支持 SSLv2。没有可能的软件升级路径,因为它们不是计算机。
  3. 这些设备上唯一的其他选择是明文传输。
  4. 代表使用该服务的设备的大多数(或不可忽略的部分)。

我正在评估是否更换所有设备,或者继续使用它们,但以相对不安全的方式。因此,这是一项业务风险管理决策。但是我必须首先了解提供 SSLv2 的业务风险。

有两个商业风险:

  1. 您可能会将其他(TLS)客户端暴露于 DROWN 攻击(其他答案已经很好地涵盖了这些,所以我不会在这里重复它们)。
  2. 您可能会导致您的用户错误地认为他们的数据比以明文传输时更安全。

纯文本实际上会更安全,因为它会消除(1)并减轻(2)(在用户知道您正在使用纯文本的程度上)。

(从技术上讲,对明文会话发起攻击比攻击 SSLv2更直接。但您的威胁模型通常不应假设对手是懒惰的,因此我们不能认为 SSLv2 更安全。)