有没有过期的 SSL 证书这样的东西?

信息安全 tls
2021-09-05 16:49:56

有没有过期的 SSL 证书这样的东西?我们的场景是我们开发和销售嵌入式设备(想想“物联网”)。这些设备上运行的 Web 服务器很少,允许某些管理功能(如 Cisco 家庭路由器允许管理操作)。我们希望这些小型 Web 服务器具有良好的安全性,即不传递明文密码。最直接的方法是使用 SSL 在加密的 SSL 会话中传递密码。但是,一旦我们将这些小型 Web 服务器出售给我们的客户,它们就不受我们的控制。我们如何处理这些设备中过期的 SSL 证书?在不受我们控制的系统上升级 SSL 证书并不容易。是否有更好的方式为此类设备提供安全登录体验?如果“物联网”

4个回答

不,有几个原因:

  • 证书不仅包含有关所有者的信息,还包含其公钥。匹配的私钥只有证书的所有者知道,并且使用公钥加密可以验证 SSL 连接的端点确实是所有者(或至少是拥有私钥的人)。证书本身是由浏览器信任的证书机构签署的(这都是简化的)。但是,所有这些东西的加密强度取决于密钥的大小和使用的算法。增加尺寸会使一切变慢,较小的尺寸会使一切变得不那么安全。而且由于计算机变得更快,而加密专家只会变得更好,并且会找到破解算法的新方法,因此证书的加密保护会随着时间的推移而变得更弱。

  • 证书可能会被泄露,例如,一些坏人或机构可能会获得私钥,从而将自己标识为所有者或解密所有流量。在这种情况下,证书将被吊销,吊销信息可公开访问。如果证书永不过期,则需要永久保存这些信息,并且所需的存储空间和检查证书是否吊销的时间将会增加。这样更便宜的最终用户证书的到期时间比更昂贵的证书更短,因为心胸狭窄的最终用户可能也不保护他们的私钥,所以他们的撤销可以在到期日之后被丢弃是件好事。

实际上,是的 - 您可以生成自己的根证书(即成为您自己的证书颁发机构),然后使用根密钥签署每个 SSL 证书 CSR。然后,您将能够在每个设备上安装的 SSL 证书上设置未来的到期日期(例如,使用非常乐观的产品寿命估计)。唯一美中不足的是,您的根证书必须作为受信任的根安装在每个访问管理功能的客户端 Web 浏览器中。如果这对您的用户来说太复杂了,他们可以简单地单独信任每个证书这可能更容易。实际上,考虑到这一点,每个单独的证书都需要绑定到某个主机名或 IP 地址,以避免任何其他浏览器警告(例如,证书主机名与浏览器中的实际主机名不匹配)所以你的主机名必须“硬编码”到设备中。由于这不切实际,每个用户都需要点击浏览器警告才能访问设备。解决方法是您需要这样做,以便他们可以自己更新证书以完全删除浏览器警告,或者您可以让设备生成自己的证书。

我的 ZyXel NAS 提供了生成自己的功能并允许为证书设置通用名称:

在此处输入图像描述

生成您自己的证书将具有与使用公共证书颁发机构相同的加密优势,并且由于各个设备将拥有自己的私有主机名,因此此解决方案可能比使用公共 CA 更合适。Intranet 证书可用(但正在逐步淘汰),但由于它们需要完整的域名或 IP 地址,您的客户需要自己在设备上更新它们。

有关其工作原理的完整详细信息,请参阅本文

RFC 5280,第 4.1.2.5 节(“有效性”)确实在技术上准确地回答了您的问题。

简而言之,有效期为 99991231235959Z(格林威治标准时间 9999 年 12 月 31 日 23:59)的证书确实可以满足您的确切要求,但 RFC 5280 还要求您必须能够撤销该证书才能打破认证路径(即通过撤销证书)在此日期之前。

到期日也被视为用户应该审查现有技术措施是否仍然符合当前标准的日期(例如,他们是否应该从 1024 位长模数升级到 2048 位长模数,或将其服务器从 DES 升级到 AES )。

出于同样的原因,商业 CA 同意在未来 3 年以上不颁发证书,并且确实需要公共 IP 空间上可公开解析的 DNS 名称;最有可能的是,这两个要求对您来说都是障碍。

所以最后,只有两种选择:

  • 成为您自己的根 CA 并自动颁发此类证书。“永远”颁发证书的策略不符合浏览器和操作系统供应商的安全考虑,因此这最终将要求您的用户手动导入您的根 CA。建议您的用户信任您的根 CA 是一项敏感操作,可能不会在您的用户中得到很好的接受。CA 可能使用 x509 名称限制(因此颁发的证书仅对某些域或 IP 子网有效),但每个考虑到安全性的人仍然会质疑这样做是否是个好主意。简而言之:这会变得非常复杂、棘手和冒险——不要这样做。

  • 在制造或“重置为出厂设置”时,请在每个设备上和/或为每个设备生成一个单独的私钥,并颁发一个自签名证书,其有效期为未来 10 年(或上述特殊日期)。该文档需要要求您的用户在“重置为出厂设置”后删除以前安装的证书并导入该特定证书以避免浏览器警告。向用户解释为什么需要这样做的额外业力:)

请注意,当您使用“永久”日期时,证书可能仍会变得“不太安全”或“无效”。例如,浏览器和操作系统确实规定了最小密钥长度或(损坏的)算法,以相应地拒绝和更新这些要求。所以现在,1024 位可能“工作”,但浏览器开始使用较少的 2048 位显示连接是“不安全”或“无效”。算法也确实崩溃到浏览器不再信任它们的地步。如果您的自签名证书使用此功能,则需要相应地更新它。

我想我找到了一个相当好的解决方案。您的物联网设备应该连接到一个可以由您管理的中央 web 和 websocket 服务器,这样您就可以每年获得它的 SSL 证书。

由于服务器创建了 websocket 服务器,因此您的 IoT 设备可以作为客户端安全地连接到它。据我所知,他们可以验证是否连接,因此它是安全的。

然后所有客户端/Web 接口都可以将 http 请求/websocket 消息发送到您的中央服务器,中央服务器可以将它们传输到指定的物联网设备。当然,您必须设置一些密码才能使用户只能连接自己的设备。

(让我知道您对此有何看法,我不是安全专家。)