SSL pinning with *.appspot.com:我怎么知道谷歌啥时候会改变他们的公钥?
Posted
技术标签:
【中文标题】SSL pinning with *.appspot.com:我怎么知道谷歌啥时候会改变他们的公钥?【英文标题】:SSL pinning with *.appspot.com: How can I know when Google is going to change their public key?SSL pinning with *.appspot.com:我怎么知道谷歌什么时候会改变他们的公钥? 【发布时间】:2015-03-11 00:05:24 【问题描述】:我有一个 ios 应用程序即将在 App Store 中上线,它使用 Google App Engine 作为其服务器后端。捆绑在应用程序二进制文件中的是 *.appspot.com。通配符证书允许我使用捆绑证书的公钥对任何 HTTPS 连接进行 SSL 固定。这有助于防止对我的客户端/服务器通信的中间人攻击。
当我设置它时,我知道 Google 循环了他们的 *.appspot.com。每两个月颁发一次证书。但是,我希望 apppot.com 每月都使用相同的公钥,这样我的应用程序和服务器之间的通信就不会中断。
然而,在最新的证书中,谷歌在没有任何警告的情况下更改了他们的公钥。现在,就与我的服务器通信而言,我的应用程序是 DOA。尝试将 SSL 固定与 *.appspot.com 一起使用是不是我错了。证书? Google 是否会在开发人员要更改其公钥时通知他们?我是否应该将自己的证书与自定义域一起使用?
【问题讨论】:
这个问题似乎属于 Stack Exchange 网络中的另一个站点,因为它与编程或开发无关。也许你应该试试Information Security Stack Exchange。 【参考方案1】:一个有趣的巧合是,我刚刚对未来的一篇关于固定的博客文章进行了第一次编辑(我负责管理云技术支持博客文章),所以绝对没有疑问我的想法是:
尝试将 SSL 固定与 *.appspot.com 一起使用是不是我错了。 证书?
是的。
Google 是否会在开发者要更改其内容时通知他们? 公钥?
不,从上面说的。
我应该改用我自己的证书和自定义域吗?
是的,没错。更一般地说,仅固定到 您 控制的公钥是最佳做法。
来自未来博文的其他建议:您应用的一部分用户不会更新 - 那么您如何才能对您的 pin 组进行任何轮换?例如,如果 5% 的用户不更新,您可以将其关闭吗?该博客的建议是让应用程序绕过自己的固定检查,如果它知道它太旧 - 例如,如果系统时间比编译时嵌入应用程序的构建时间至少晚六周;至少,这样,非更新程序“变砖”是暂时的,而不是永久的......
【讨论】:
如果您需要有人帮助您对博客文章进行技术编辑,请告诉我是否可以提供帮助。多年来,我一直使用固定作为安全控制。我也很熟悉 Gutmann 的Engineering Security。我不确定这是一个好的策略:“博客的建议是让应用程序绕过自己的固定检查,如果它知道它太旧了......” 捍卫,不要问(见古特曼的书)。 noloader,gmail 帐户。 有趣的是,Public-Key-Pins
似乎已从 AppEngine 响应标头中删除,如 code.google.com/p/googleappengine/issues/detail?id=12694 中所述(我已经为我自己的应用程序验证了该问题)。可以将标头列入白名单(与 HSTS 一样),但无论如何我都找不到有关该政策的官方评论。
...HPKP 和 HSTS 一样,可以列入白名单。【参考方案2】:
我如何知道 Google 何时会更改其公钥?
除非出现问题,否则 Google 不会更改其公钥。所以你应该固定公钥。
鉴于实践中的所有失败,安全社区发现密钥连续性是一项重要属性。因此,安全社区中的一些人正在放弃密钥轮换,转而支持密钥连续性。
Google 使用短期的终端实体/服务器证书(30 天左右)来保持 CRL 较小(对于移动客户端尤其重要)。所以你不应该固定证书。
然而,在最新的证书中,谷歌在没有任何警告的情况下更改了他们的公钥
就我所知,这很奇怪。什么公钥改变了?是 Google CA(Google Internet Authority G2)、公共 CA(GeoTrust Gobal CA)还是最终实体证书?
您可以在android 4.2 and Pinning 上阅读有关 Google 对固定的立场的更多信息。一些 Google 安全工程师提供了他们的知识和意见。
就与我的服务器通信而言,现在我的应用程序是 DOA。尝试将 SSL 固定与 *.appspot.com 一起使用是不是我错了。证书?
我认为您使用固定并没有错。我怀疑这个问题与通配符证书或即将推出的Public Key Pinning Extension for HTTP (HPKP) 有关。
通配符证书在 EV 级别被 CA/B Forums(记录浏览器政策和程序)禁止,Google 是 CA/B 的成员(浏览器遵循 CA/B 论坛,而不是像许多其他的 IETF嫌疑人)。
Google 是否通过 HPKP 标头提供翻转? (实际上,网络级 SST/TLS 固定应该不依赖于应用层 HPKP 标头)。
现在这里有一些背景故事... IETF 将很快发布Public Key Pinning Extension for HTTP RFC。所做的更改可能有助于与 RFC 和 HPKP 标头保持一致。因此,在这种情况下,浏览器会去 IETF 进行标准化,而不是去 CA/B 记录政策和程序。
不过,我觉得 RFC 存在很多问题。我觉得你不应该依赖它作为安全控制,因为:
它适应由于覆盖而导致的拦截 它没有报告损坏的针组其中一些是由于使用了不兼容的安全模型,还有一些是由于哲学。由于 W3C 设计原则(特别是,请参阅 Priority of Constituencies),所使用的安全模型存在无法协调的漏洞。
您可以在Comments on draft-ietf-websec-key-pinning 的 IETF 邮件列表中阅读有关我的异议的更多信息。
【讨论】:
以上是关于SSL pinning with *.appspot.com:我怎么知道谷歌啥时候会改变他们的公钥?的主要内容,如果未能解决你的问题,请参考以下文章
适用于 android 和 IOS 应用程序的 ssl-pinning 正确方法
使用 AFNetworking 2.3.1 的自签名 SSL 证书
NSURLConnection sendSynchronousRequest + SSL Pinning