有没有办法使用 JavaScript 获取 SSL 证书详细信息？

Posted 2023-04-13

【中文标题】有没有办法使用 JavaScript 获取 SSL 证书详细信息？

【英文标题】：Is there a way to get SSL certificate details using JavaScript?

【发布时间】：2021-09-12 09:10:09

【问题描述】：

我想收集特定网站上 SSL 证书的某些详细信息。我知道在 Linux/MacOSX 上使用 openssl 工具很简单。然而，在 javascript 中是否可能相同或相似？

我了解浏览器会处理套接字连接，并且 SSL 握手发生在任何一方发送数据之前。但是在 XMLHTTPRequest 中，我想知道是否可以将这些详细信息作为某种响应代码等获取？

【问题讨论】：

我认为这是不可能的。

我一直在寻找 Javascript API 来测试经过验证的跨站点请求凭据，以提高站点安全性。可悲的是，浏览器丢弃了这些信息，这迫使脚本盲目地相信第三方内容现在是可信的，因为它在过去是可信的。这是一种可悲的状况。 :-(

有些人将证书详细信息添加到响应标头。在该设置中，您可以发出 xhr 请求并读取 req.getAllResponseHeaders()

总比没有好，但不提供任何实际的安全性。我最关心的是从广告商那里获取数据。当我为客户编写货币化广告代码时，我不想每隔几个月就回来检查广告商是否仍在营业，以防止他们的网站被劫持，因为我正在从网站上提取脚本资源不再归广告商所有，我不想告诉客户“现在这里很安全，但现在我完成了，你就靠自己了。祝你好运！”

【参考方案1】：

这些信息根本不会暴露给 javascript，它很少使用（因为它不可用，所以从来没有，但它将很少使用）以至于它被认为不够重要我想添加到 javascript 对象模型中......对于任何很少使用的功能都一样。

当然，出于安全原因，它也可能被忽略...我目前还没有足够的创造力来想出一个，但我相信那里也有一个漏洞利用。

【讨论】：

@GregS - 我也想不出一个……但我已经说过 100 次了，有人会想出一个我永远不会有的漏洞consireded，不同的心态我想......所以我只是把那个选项扔在那里。如果您托管有问题的 javascript……您不是已经拥有证书的人了吗？这就是让我认为可能会有更多的邪恶用途不知何故。正如我所说，这绝对不是我的专业领域，我将把它留给你和其他专门研究该领域的人详细说明可能的情况。

谢谢尼克，我想我将不得不考虑如何以跨平台的方式在客户端获取 SSL 详细信息，无需 JS 或安装替代二进制文件（例如 openssl、curl/wget） .

如果我可以使用 Javascript 测试我从中嵌入内容的第 3 方网站仍然是我在创作页面时信任的同一实体，这将提高我页面的安全性。目前，浏览器努力证明该信息，然后丢弃它，迫使我的页面假设今天仍然存在信任关系，因为过去存在信任关系。我几乎对你的帖子进行了-1 喷盲 FUD。知道你在和谁说话没有什么可利用的。请重新考虑你的答案。

@JamesKPolk 实际上这是一个安全问题，因为网站无法检测 SSL 是否已被破坏以及是否使用了假证书。

@aaa90210：很高兴你在 8.5 年后回复了，但是证书是公共价值，通过任何一种方式都不难获得。浏览器的 javascript 引擎不能轻易做到这一点并不是安全问题。

【参考方案2】：

证书不是 DOM 的一部分，所以不，这是不可能的。对不起！

【讨论】：

是的，可悲但真实。因此，我们需要一些相关的利益相关者向 W3C、Mozilla、Chromium 实际发出一些声音（一旦有 CVE 反对他们的平台未能遵循，Safari 和 Edge 就会效仿。）

【参考方案3】：

不，不可能。

可以通过 javascript 检测正在查看的当前页面是否通过 SSL 连接 (document.location.protocol=="https:")，但仅此而已。

【讨论】：

然后您可以将该 document.location 值传递给 REST 服务以获取证书信息。

@Saber “中间人”类型的攻击仍然是一个问题......我想检查证书公钥签名，以确保浏览器直接与 my 对话 服务器。但是，是的，有趣的想法......值得探索......

【参考方案4】：

目前的JS语言标准不暴露证书信息；除此之外，这可能取决于您使用 JavaScript 的方式，如果您希望最终用户的浏览器公开证书信息，那么这将是非常有问题的，因为您需要至少获得 FF、Chrome、Safari、IE , Edge, ... 暴露它。

但是，正如 Information Security post 中提到的，这对于这些浏览器来说并不是一个真正理想的选择，因为它会允许网站开发人员编写代码错误地信任用户端凭据的情况。

与其说是阻止 javascript 访问浏览器当前 SSL 证书信息的可见性安全风险，不如说是 JS 开发人员必须意识到“用户接受”证书不一定是第四个墙屏障安全风险该网站提供的那个。 html 页面确实不应该处理客户端代码的安全问题，而是应该能够依赖安全层来正确完成它的工作。 （我完全可以理解想要检查安全层，但是您在顶层所做的任何管理工作都只是肤浅的，或者是对整个生物圈的改造）

因为让我们暂时假设 javascript 确实提供了一种使用证书的方法，那么当 Bob 已经信任 Mallory 因为他的安全性被破坏时，就无法停止以下交换：

办公室工作人员 Bob 位于 Mega Corp. 的防火墙的一侧，IT Mallory 负责将流量传入和传出公司本地的防火墙，而 Web 主机 Alice 的精彩网站则在 WWW 上。

根据 Mega Corp. 的公司政策，Bob 只接受马洛里所说的话。 Bob 想要访问 Alice 的站点，但没有直接的外部访问权限，他试图通过持有他的证书（例如：“我在此声明我是 Bob”）通过防火墙建立一个安全连接，并询问 Alice真是令人费解，“我给你发了什么证书？” Mallory 收到 Bob 的请求，但她自己传递（例如：“呃，Bob 说我可以阅读他的网络邮件”），即使 Mallory 不理解 Bob 的复杂问题，她仍然向 Alice 重复, “akdvyfenwythnwerhy?”。 Alice 做了一些数学运算，发现“akdvyfenwythnwerhy？”是在问“我给你发了什么证书？”并用她看到的内容回复马洛里（“嗨，鲍勃，这是爱丽丝，你说：嗯，鲍勃说我可以阅读他的网络邮件”）。 Mallory 做了一些数学运算，哈哈大笑“akdvyfenwythnwerhy？=我给你发了什么证书？”，并代表 Alice 回答 Bob 的问题（“嗨 Bob，这是 Alice（Mallory) 你说：我在此宣布我是 Bob")。 Bob 相信生活是美好的，并继续阅读他的网络邮件，因为根据公司政策，他知道 Mallory 永远不会对他撒谎。 Mallory 现在能够阅读对话的双方，将 Bob 的请求发送给 Alice，以阅读他的网络邮件。 Alice 收到 Bob 的请求并说嘿等一下 Bob 我需要你运行这段 JS 代码来证明你知道你正在和 Alice 交谈。 Mallory 获取代码并运行它，然后将结果表明她知道她正在与 Alice 交谈并发送回 Alice。 Alice 说，这对我来说已经足够了，这是你的网络邮件。 Mallory 阅读了 Bob 的网络邮件，然后将其传递给 Bob，每个人都非常高兴。

（注意：我没有解决您在服务器端运行 JS 的情况，这将取决于您使用什么程序来运行 JS 代码。）

---

编辑 2018 年 4 月 4 日——虽然上面没有错，但更多的是从嵌入式和链接 JS 的角度来看，而不是关于 `XMLHTTPRequest` JS 对象；此外，反对与 `XMLHTTPRequest` 共享 PKI 详细信息的最有力论据可能如下：

需要在 HTTPS 协议的 HTTP 部分和 S 部分之间保留一条强有力的分界线。 JavaScript 和它的 XMLHTTPRequest 对象位于该行的 HTTP（应用层）一侧，而整个证书交换过程位于该行的 S（trans/sec 层）一侧。为了保持安全方面的原子性（热插拔），它的内部工作不能跨线暴露给应用程序端；因为可能有一天，传输/安全层不再使用 PKI 证书来促进其安全通信服务，当那一天到来时，没有人需要重写任何依赖这些证书中包含的细节来处理的现有 JS 代码随着 www 社区逐渐采用他们最喜欢的任何新安全层的风格引起的传播浪潮。

话虽如此，安全方面似乎也在进行法人实体审查——至少在某些情况下，例如 EV 证书——，而 IMO 的缺点是 RFC7230 section 2.7.2 没有重新定义 @ https-URI 中的 987654324@ 包括一个可选的 legalentity，安全层在验证与之通信的 url 时将使用它不仅是正确的端点，而且当前处于预期业务关系的控制之下。

authority     = [ userinfo "@" ] host [ "#" legalentity ] [ ":" port ]
legalentity   = *( unreserved / pct-encoded / sub-delims )

【讨论】：

您的回答没有解决问题。问题是Javascript是否可以访问已经被浏览器传输层证明的证书中的数据。不幸的是，浏览器丢弃了它。他的问题中没有任何暗示在 Javascript 中实现传输或绕过传输安全性。 -1

@Wil，在查看分布在线程中的 cmets 时，我相信当您应该查看 php 或 ASP 解决方案时，您正在尝试使用 JS。 JS 是客户端，如果您尝试在用户机器上检查证书信息，这在游戏中为时已晚。

我认为您忽略了这样一个事实，即正在编写真正的应用程序以在浏览器中运行 - 应用程序应该能够做一些简单的事情，例如证明他们正在与他们想要的对等方交谈交谈。 PHP 不在浏览器中运行。 ASP 不在浏览器中运行。未来不是服务器端应用程序。阻止应用程序证明对等方的身份会降低从 SSL-EV 到 SSL 破坏证书的传输安全性。

此外，阻止客户端 JS 应用程序相信其对受损令牌的自我证明的有效性证明可以防止它犯下非常大的错误； JS 应用程序层从下面的安全层获取其数据，包括应用程序自己的代码，因此当安全令牌被泄露时，同样假设 JS 代码也是相当安全的，并且没有神奇的有效性证明，当换出时中间方使用function check_valid()return true; 并不总是像上面过于简化的现实示例中所示的那样对损坏的令牌进行橡皮图章。