SSL 指纹不一致:这是什么意思?

信息安全 tls 证书 公钥基础设施
2021-09-03 19:15:08

如果这不是在 Stack Exchange 网络上提出我的问题的最佳地点,我深表歉意,我不知道在哪里可以获得足够的关注和相关性。

Facebook 提供 SSL 主机,可以通过https://www.facebook.com访问。基本上,据我了解,证书的更改只应在删除旧证书时发生。然而,Perspectives(Firefox 的一个插件,检查来自许多服务器的指纹)发现 Facebook 的指纹不一致。我很担心,我希望您能就此事发表见解。

透视截图 2月23日

编辑:屏幕截图的解释

Notary 和 current key 列列出了所有试图访问 www.facebook.com 的服务器,以及他们在主机证书中找到的指纹。密钥历史记录显示 30 天内的密钥更改。因此我们可以推测:

  • 在全球范围内,证书更改发生
  • 一张证书(蓝色)似乎是主要证书
  • 其他人有时会替换它并且相当可疑

为什么 Facebook 会以这种方式更改他们的证书?这是一种常见/安全的做法吗?

我了解具有证书颁发机构的 PKI 不是很安全,我知道某些人(无论是富有、强大还是知识渊博)很容易获得他们想要的任何域的证书。但在全神贯注之前,我想知道是否有与安全无关的合乎逻辑的解释。

作为比较,这里是https://encrypted.google.com的公证结果:

加密的.google.com

证书更改会定期发生,但浏览器的密钥在 30 天内只能看到一次。我开始认为没有什么是真正可疑的,但这些做法似乎破坏了透视图的有用性,并要求用户信任公司。他们至少应该为此提供某种解释,为什么不提供他们的证书指纹列表。

赏金:我希望看到一些关于这样一个系统的参考资料,当然有可能找到一个规范或文档,推荐在同一个区域集群内使用多个证书进行这样的配置,就像 Facebook 的情况一样。另外,如果存在其他可信的理论,请分享。

既定事实

感谢此线程中的答案和评论,我们可以弄清楚:

  • Facebook 确实有不同的证书
  • 即使在单个 IP 之后(负载均衡器)
  • 以这种方式吊销和更换证书会更容易

  • 这会提高安全性吗?
  • 跟踪哪个服务器有哪个证书看起来很乏味,这种方法真的值得吗?它甚至不可扩展,因为单个区域集群中的证书不同
  • 如果发生泄漏,只保留备用证书怎么样?从安全的角度来看,保留它们而不是全部部署它们似乎更好:如果一个泄露,为什么不泄露其他?

编辑:接受的答案

参考接受的答案和评论,我看得更清楚。它帮助我理解了这种设置背后的原因,现实生活中的部署可能不像我最初想象的那么简单。我觉得很遗憾,透视插件在这种情况下几乎没用,但我不能指望 Facebook 会关心这一点,这对几乎每个人来说都毫无意义。谢谢大家的意见。

2个回答

这可能取决于公证服务器上也可能发生的 dns 解析 + 缓存。如果您解析 www.facebook.com,您通常会获得一个 IP 地址。但是这个 IP 会随着时间的推移而变化,并可能将您带到不同的地方。

我只是快速检查了一下,确实给我的 www.facebook.com IP 地址改变了,而且证书信息也不同了。

在几分钟的时间里,我收到了 www.facebook.com 的 3 个不同的 IP 地址:69.171.229.16, 69.171.234.80,69.171.228.40

为每个 IP 获取 SSL 证书会产生不同的证书。但是,即使对于相同的 IP 地址,证书也不一致。在那几分钟里,我至少收到了两个证书:

-----BEGIN CERTIFICATE-----
MIIDzDCCAzWgAwIBAgIQPAjP7r6f68QrsT7gPWIL3zANBgkqhkiG9w0BAQUFADCB
ujEfMB0GA1UEChMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazEXMBUGA1UECxMOVmVy
aVNpZ24sIEluYy4xMzAxBgNVBAsTKlZlcmlTaWduIEludGVybmF0aW9uYWwgU2Vy
dmVyIENBIC0gQ2xhc3MgMzFJMEcGA1UECxNAd3d3LnZlcmlzaWduLmNvbS9DUFMg
SW5jb3JwLmJ5IFJlZi4gTElBQklMSVRZIExURC4oYyk5NyBWZXJpU2lnbjAeFw0x
MTExMTcwMDAwMDBaFw0xMjA3MTMyMzU5NTlaMGoxCzAJBgNVBAYTAlVTMRMwEQYD
VQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlQYWxvIEFsdG8xFzAVBgNVBAoTDkZh
Y2Vib29rLCBJbmMuMRkwFwYDVQQDExB3d3cuZmFjZWJvb2suY29tMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQC4e9C0eD3zy0YR829bH7fd3PGGDp/3Rd7UR65Q
+jcsRoLZaer9k9tPEOd5ZmWR1MTzwVEmZ94fhoWf219K2Nx/v7fQaWYh5U0DETUo
bkDfR4zBAe+oMuFDIGrhEkUEdlWUOcpvScrtzRjRLyikTc4twjRlpB5RdnGGFopw
CRTNMwIDAQABo4IBIDCCARwwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG
+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL1NWUkludGwtY3JsLnZlcmlzaWdu
LmNvbS9TVlJJbnRsLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIw
CwYDVR0PBAQDAgWgMCkGA1UdEQQiMCCCEHd3dy5mYWNlYm9vay5jb22CDGZhY2Vi
b29rLmNvbTA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw
LnZlcmlzaWduLmNvbTANBgkqhkiG9w0BAQUFAAOBgQANiGfuAUQqkUZiD2cozCmb
7+e6vK5yzc/3o/zAd+QBydo7dkPo/t8nIHUfGxcAKUICjAzH/j3FDykK3bupFvBW
D4GoU6qVvNFgH8ucYWMNbxsknN/s3lcFryIGZYFcsYuPEB/rbBEEseKTilUSR7vt
pUEsLwSGdWwTNtKgy/COcQ==
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
MIIDnzCCAwigAwIBAgIQCSGX4cDpzQPaNSQ2VhCGgTANBgkqhkiG9w0BAQUFADCB
ujEfMB0GA1UEChMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazEXMBUGA1UECxMOVmVy
aVNpZ24sIEluYy4xMzAxBgNVBAsTKlZlcmlTaWduIEludGVybmF0aW9uYWwgU2Vy
dmVyIENBIC0gQ2xhc3MgMzFJMEcGA1UECxNAd3d3LnZlcmlzaWduLmNvbS9DUFMg
SW5jb3JwLmJ5IFJlZi4gTElBQklMSVRZIExURC4oYyk5NyBWZXJpU2lnbjAeFw0x
MTA3MTQwMDAwMDBaFw0xMjA3MTMyMzU5NTlaMGoxCzAJBgNVBAYTAlVTMRMwEQYD
VQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlQYWxvIEFsdG8xFzAVBgNVBAoTDkZh
Y2Vib29rLCBJbmMuMRkwFwYDVQQDExB3d3cuZmFjZWJvb2suY29tMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQC4e9C0eD3zy0YR829bH7fd3PGGDp/3Rd7UR65Q
+jcsRoLZaer9k9tPEOd5ZmWR1MTzwVEmZ94fhoWf219K2Nx/v7fQaWYh5U0DETUo
bkDfR4zBAe+oMuFDIGrhEkUEdlWUOcpvScrtzRjRLyikTc4twjRlpB5RdnGGFopw
CRTNMwIDAQABo4H0MIHxMDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0
cDovL29jc3AudmVyaXNpZ24uY29tMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5Bgtg
hkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vcnBhMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9TVlJJbnRsLWNybC52ZXJp
c2lnbi5jb20vU1ZSSW50bC5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUF
BwMCMAsGA1UdDwQEAwIFoDANBgkqhkiG9w0BAQUFAAOBgQAwUGokl1919Kf6YPDK
uoF+k7CFm+j2YtZqw4ilP9166qkM8IDWyYa87MB084WXSyfS1VnT5FSwzjP37+Qx
gjRaROuWGxfY25KebCQpoBW2PJp3S1JmqHHyxjk4mzr+tzWK0Qn+tlBUy9igtkIh
VybjO+AxBZve1qyJIsVraz8wrw==
-----END CERTIFICATE-----

当您访问任何一个 Facebook IP 地址时,Facebook 可能有一些优先级列表,其中列出了 DNS 问题的 IP 地址以及您命中的 SSL 端点(通过他们的负载均衡器)。他们的基础设施设置可能“更喜欢”某些端点而不是其他端点(也许他们在一个端点上的硬件比另一个端点上的硬件更强大),这就是为什么您通常会看到一个指纹,但偶尔会看到另一个。

更新:

要更具体地回答您的其他问题:

这会提高安全性吗?

我认为确实如此,但主要是如果您在说“安全性”时考虑可用性而不是机密性或完整性。如果一个证书过期/需要撤销/出于任何其他原因需要更换,您仍然有另一个完全可操作、有效且准备就绪。

跟踪哪个服务器有哪个证书看起来很乏味,这种方法真的值得吗?它甚至不可扩展,因为单个区域集群中的证书不同

这可能有点乏味,但我敢肯定,这只是 Facebook 在宏伟计划中必须处理的乏味任务的一小部分。这值得么?我想是的,我会说 facebook 这样做是有原因的(正如我上面提到的,主要是可用性原因)。我想它不是在服务器上运行,而是某种强大的专用 SSL 加速器/端点集群。这些将处理 SSL 流量,然后反向代理通信到一些前端 Web 服务器(无需担心证书)。

如果发生泄漏,只保留备用证书怎么样?从安全的角度来看,保留它们而不是全部部署它们似乎更好:如果一个泄露,为什么不泄露其他?

是的,让一些备用证书离线是一个非常好的主意,而且我不知道我会打赌 Facebook 也会这样做。拥有多个在线证书与拥有一些离线证书并不相互排斥。您假设他们部署了所有这些,但情况可能并非如此。还要建立逻辑联系,即如果一个人泄露了,其他人也会泄露,这需要更多的事实。如果他们有良好的安全措施来隔离事物,那么一个妥协不会立即链接到另一个妥协。例如,他们可以在不同的服务器操作系统上使用来自不同供应商的不同 HSM,由一组单独的防火墙保护并由完全独立的团队管理。

Facebook 可能为同一个端点部署了多个 SSL 证书。这通常是出于安全原因(泄露的私钥仅影响有限数量的主机)或出于可管理性原因(我可以错开有效期,因此不需要同时更换它们)。不同的证书意味着不同的序列号。结果,指纹会有所不同。

也有可能是证书的内容不同。例如,它们可能具有不同的 subjectAltName 扩展值,以通过多个 DNS 别名引用给定服务器。