SSL固定和证书到期 [英] SSL Pinning and certificate expiry

问题描述

此问题与在客户端应用中针对Web api和证书使用SSL固定有关 到期.

This question relates to the use of SSL Pinning in a client app against a web api and certificate expiry.

场景:

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

I own example.com and have a subdomain where an api is hosted, as such: api.example.com

我希望通过 SSL 使用api，因此将为子域创建一个SSL证书.

I wish to use the api over SSL, so an SSL Certificate is created for the subdomain.

获得证书后，我将拥有:

After the certificate has been acquired, I have:

• 公共证书
• 中级证书
• 私钥

据我了解，我将这些证书安装在Web服务器上.

It's my understanding that I install these certificates on my webserver.

然后我希望我的客户端应用程序连接到api.减轻中间人风格 攻击，我希望使用SSL固定，以便客户端仅与我的api通信，而不与 有人在欺骗它.

I then wish for my client app to connect to the api. To mitigate against man-in-the-middle style attacks, I wish to use SSL Pinning, so that the client will only communicate with my api, not someone spoofing it.

为了固定客户端应用程序，我有两种选择，要么固定在公共场合，要么固定在中间人 证书.

In order to pin in the client app, I have two choices, either pin against the public or intermediate certificate.

假设我实现了这一点.

api.example.com 上的证书过期会怎样?

What happens when the certificate on api.example.com expires?

据我了解，该客户端应用将不再起作用.

It's my understanding that the client app would no longer work.

我是否需要重新生成一整套公共/中级/私人项目?接着 在应用中添加新的公共证书或中间证书?

Do I need to regenerate a complete set of public/intermediate/private items again? and then put a new public or intermediate certificate in the app?

问题:

在api.example.com上的证书更新之前，我仍然希望客户端应用能够正常工作. 当然，可以在客户端应用程序中放入新证书，但是推出类似的事情需要花费时间.

I would still like the client app to work until the certificate on api.example.com was updated. Of course, a new certificate can be put in the client app, but things like roll-out take time.

我该如何处理?

我已阅读到Google每月都会更新其证书，但不知何故设法保持公钥不变:

I've read that Google updates their certificate every month, but somehow manages to keep the public key the same: How to pin the Public key of a certificate on iOS

如果可能的话，解决方案是简单地从服务器中提取公钥，并对照本地存储的公钥进行检查...但是Google如何做到这一点?

If that's possible, then the solution is to simply extract the public key from the server and check it against the locally stored public key...but how do Google do it?

谢谢

克里斯

推荐答案

注意:我更熟悉浏览器到服务器的固定(HTTP Public Key Pinning-HPKP)而不是应用程序到服务器的固定，但是我想主要是相同.在HPKP中，固定策略由服务器作为HTTP标头提供，但要了解，此策略通常内置于应用程序中，而不是从HTTP响应中读取.因此请牢记以下所有答案:

Note: I'm more familiar with browser to server pinning (HTTP Public Key Pinning - HPKP) rather than app to server pinning, but I presume the principal is the same. In HPKP the pinning policy is provided by the server as a HTTP header but understand this is often built into the app rather than read from the HTTP response. So read below answer with all that in mind:

固定通常是针对密钥而不是证书，并且可以是多个级别.因此，您有几种选择:

Pinning is usually against the key not the cert and can be a multiple levels. So you've several choices:

1. 重复使用相同的密钥/crt来生成新的证书.有些人(我认为是对的！)建议您每次更新证书时都生成一个新密钥，但这在使用固定时很复杂.那么固定会鼓励不良的安全习惯，例如密钥重用吗?

1. Reuse the same key/crt to generate a new cert. Some (rightly in my opinion!) recommend generating a new key each time you renew your cert but this is complicated when you use pinning. So does pinning encourage poor security habits like key reuse?

您的固定策略中有几个备份密钥，并在证书更新时将它们轮换使用，从而舍弃了您最旧的密钥，并添加了很多新的密钥，这些密钥具有足够的时间和更新，因此永远都不会丢失.就我个人而言，我更喜欢在证书续订时生成密钥，而不是在周围有或可能已经遭到破坏的情况下进行一些备份，因此我也不是对此特别感兴趣.您应该拥有多少备份?例如.如果您由于续约方面的折衷而需要重新发行证书，并且也将其弄乱了吗?那么2? 3? 100?

Have several back up keys in your pinning policy and rotate them around on cert renewal discarding your oldest and adding a new one with plenty of time and updates to never be caught short. Personally I prefer to generate the key at cert renewal time rather than have some backups around which may or may have been compromised so I'm not a particular fan of this either. And how many backups should you have? E.g. If you need to reissue a cert because of compromise around renewal and also mess it up? So 2? 3? 100?

进一步固定引脚.说出第一个中间证书或根CA证书.因此，任何新发行的证书仍然是受信任的(假设它是通过相同的证书路径发行的).它的缺点是四方面:i)您仍然对由该固定证书发行的未正确发行的证书保持开放的态度(与您一样，这不是一笔大笔交易恕我直言仍然大大减少了您的攻击面，但仍然使某些人担心.ii)您不能保证客户端会使用该中间证书，因为有时会有多个有效路径.第二个是更大的交易.您可能会认为，提供中间证书将保证可以使用此证书，但事实并非如此(大量的sha-1示例). iii)不能保证新的证书将由相同的中间人或根颁发(特别是在技术的变化，例如引入sha2时)，所以对我来说，这是一个完全入门的问题.iv)将您与使用相同的证书提供者联系在一起(也许没什么大不了的，但是我喜欢移动的自由).不确定应用程序是否本身就支持此功能，但浏览器肯定会支持.

Pin further up. Say the first intermediate or the root CA cert. So any newly issued cert is still trusted (providing it's issued by same cert path) The downside of this is four fold: i) You still leave yourself open to miss-issued certs issued by that pinned cert (not a massive deal IMHO as you've still massively reduced your attack surface but still a concern to some people), ii) you cannot guarantee the client will use that intermediate cert as there are sometimes multiple valid paths. This second one is a much bigger deal. You'd think that providing the intermediate cert would guarantee this would be used but that's not the case (plenty of sha-1 examples of this). iii) There's no guarantee new cert will be issued by same intermediate or root (especially when technologies change like introduction of sha2), so to me this whole option is a non-starter iv) It ties you in to using same cert provider (perhaps not a big deal but I like the freedom to move). Not sure if apps support this feature natively anyway but browsers certainly do.

提前更新，在策略缓存过期之前不要使用新密钥.例如，如果您拥有一年的证书和30天的固定政策，则可以在11个月后进行续订，将新密钥添加到该政策中，然后等待30天，这样就可以确保每个人都会选择新政策，或者至少可以选择旧策略将过期，然后切换密钥和证书.取决于短期策略，但是可能会浪费一部分策略(在此示例中至少为30天)，除非证书提供者在旧策略到期后的第二天开始提前提供证书.对于应用程序，如果将固定策略硬编码到其中，则可能需要花费一定的时间才能推出更新.

Renew in advance and do not use the new key until policy cache expires. For example if you have one year certs and a 30 day pinning policy then you can renew after 11 months, add the new key to the policy, then wait 30 days so you can be sure everyone will have picked up new policy or at least the old policy will have expired, then switch keys and certs. Depends on a short policy and potentially wastes a portion of that though (at least 30 days in this example), unless cert provider provides cert in advance starting on day after old policy expires. For an app, if pinning policy is hard coded into it, then this might involve the length of time it takes to push out an update.

最终，由于证书确实需要续签，因此我不喜欢固定.我认为制作 需定期更新的内容是正确的答案.甚至还有关于在浏览器中预加载固定策略的话题，这让我感到震惊.

Ultimately, because certs do require renewing, I'm not a big fan of pinning. I don't think making something that is subject to periodic renewal, semi-permanent is the right answer. And there are even some talk of pre-loading pinning policies in browsers which just makes me shudder.

固定可确保流氓CA不会为您的域颁发证书，但是与固定的麻烦相比，这真的有多大可能性?诸如证书透明性"之类的东西-甚至只报告固定问题，即使实际上并没有阻止该攻击，也可能是该问题的更好答案.

Pinning provides assurance that a rogue CA is not issuing certs for your domain but how likely is that really compared to the hassle of pinning? Something like Certificate Transparency - or even report only pinning may be a better answer to that problem even if they don't actually stop that attack.

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

Finally locally installed roots (e.g. for antivirus scanners or corporate proxies), bypass pinning checks (on the browser at least) which again reduces its effectiveness in my eyes.

因此，在使用固定之前，请仔细考虑并确保您了解所有后果.

So think carefully before using pinning and make sure you understand all the consequences.

这篇关于SSL固定和证书到期的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！