SSL固定和证书到期

此问题涉及在客户端应用程序中针对Web api和证书过期使用SSL Pinning.

场景:

我拥有example.com并且有一个托管api的子域,例如:api.example.com

我希望通过SSL使用api ,因此为子域创建了SSL证书.

获得证书后,我有:

公共证书

中级证书

私钥

我的理解是我在我的网络服务器上安装了这些证书.

然后我希望我的客户端应用程序连接到api.为了减轻中间人攻击风格,我希望使用SSL Pinning,以便客户端只与我的api通信,而不是欺骗它的人.

为了引入客户端应用程序,我有两个选择,针对公共证书或中间证书.

假设我实现了这一点.

当api.example.com上的证书到期时会发生什么？

我的理解是客户端应用程序将不再有效.

我是否需要再次重新生成一整套公共/中间/私人物品？然后在应用程序中添加新的公共或中间证书？

问题:

在api.example.com上的证书更新之前,我仍然希望客户端应用程序能够正常运行.当然,新的证书可以放在客户端应用程序中,但是推出需要时间.

我怎么处理这个？

我已经读过Google每个月都会更新他们的证书,但不知何故设法让公钥保持不变:如何在iOS上固定证书的公钥

如果可行,那么解决方案就是从服务器中提取公钥并根据本地存储的公钥进行检查......但谷歌如何做到这一点？

谢谢

克里斯

注意:我更熟悉浏览器到服务器的固定(HTTP公钥锁定 - HPKP)而不是app到服务器固定,但我认为主体是相同的.在HPKP中,固定策略由服务器作为HTTP头提供,但是理解这通常内置在应用程序中,而不是从HTTP响应中读取.请仔细阅读以下答案:

固定通常是针对密钥而不是证书,可以是多个级别.所以你有几个选择:

重用相同的密钥/ crt以生成新证书.一些(在我看来正确!)建议每次续订证书时生成一个新密钥,但是当你使用固定时这很复杂.固定是否会鼓励像密钥重用一样的安全习惯？

在您的固定策略中有几个备份密钥,并在证书续订时轮换它们,丢弃最旧的,并添加一个有足够时间和更新的新版本,永远不会被发现.我个人更喜欢在证书续订时生成密钥,而不是在可能或可能已经受到损害的情况下进行一些备份,所以我也不是特别喜欢这个.你应该有多少备份？例如,如果您需要重新颁发证书,因为在续约方面妥协并且还要搞砸了？那2？3？100？

更进一步.说第一个中间证书或根CA证书.因此,任何新颁发的证书仍然是可信的(提供它由相同的证书路径发布)这的缺点是四折:i)你仍然可以让你自己开放由该固定证书颁发的错过发布的证书(不是一个大规模的交易恕我直言,因为你仍然大规模减少你的攻击面,但仍然是一些人的担忧),ii)你不能保证客户端将使用该中间证书,因为有时有多个有效路径.第二个是一个更大的交易.您认为提供中间证书可以保证会使用这种情况,但情况并非如此(大量的sha-1示例).iii)不保证新证书将由相同的中间人或根证书发布(特别是当技术发生变化时,如sha2的引入),所以对我来说这整个选项是非首发iv)它将你与使用相同的证书提供商联系起来(也许没什么大不了的,但我喜欢自由行动).不确定应用程序是否原生支持此功能,但浏览器肯定会这样做.

在策略缓存过期之前,请提前续订并不要使用新密钥.例如,如果您有一年的证书和30天的固定策略,那么您可以在11个月后续订,将新密钥添加到策略中,然后等待30天,这样您就可以确定每个人都会选择新策略或至少旧策略将过期,然后切换密钥和证书.取决于短期政策并可能浪费其中的一部分(在此示例中至少30天),除非证书提供商在旧政策到期后的第二天提前提供证书.对于应用程序,如果将固定策略硬编码到其中,则可能涉及推出更新所需的时间长度.

最终,因为证书确实需要更新,所以我不是钉住的忠实粉丝.我不认为做的东西是定期延长,半永久性的是正确的答案.甚至有一些关于在浏览器中预加载固定策略的讨论让我感到不寒而栗.

固定可以保证流氓CA不会为您的域颁发证书,但这与固定麻烦相比有多大可能？像证书透明度这样的东西 - 甚至只报告固定可能是对这个问题更好的答案,即使它们实际上并没有阻止这种攻击.

最后是本地安装的根(例如,用于防病毒扫描程序或公司代理),绕过固定检查(至少在浏览器上),这再次降低了我在我眼中的效率.

因此在使用钉扎之前要仔细考虑并确保您了解所有后果.