我想收集特定网站上 SSL 证书的某些详细信息。我知道在 Linux/MacOSX 上使用 openssl 工具很简单。然而，在 JavaScript 中是否可能相同或相似？
我了解浏览器处理套接字连接，并且 SSL 握手发生在任何一方发送数据之前。但是，在 XMLHTTPRequest 中，我想知道是否可以将这些详细信息作为某种响应代码等获取？
有没有办法使用 JavaScript 获取 SSL 证书详细信息？
IT技术
javascript
ssl
openssl
dom-events
2021-01-13 17:54:21
4个回答
这些信息根本没有暴露于JavaScript中，就这样很少使用（也从来没有因为它是不可用的，但它会很少使用），它不被认为足够重要添加到JavaScript对象模型，我想。 ..对于任何很少使用的功能都没有留下任何东西。
当然，出于安全原因，它也可能被排除在外……我目前没有足够的创造力来提出一个，但我相信那里也有一个漏洞利用。
证书不是 DOM 的一部分，所以不，这是不可能的。对不起！
不，不可能。
可以通过 javascript 检测正在查看的当前页面是否通过 SSL 连接（document.location.protocol=="https:"），但仅此而已。
当前的 JS 语言标准没有公开证书信息；除此之外，这可能取决于您使用 JavaScript 的方式，如果您希望最终用户的浏览器公开证书信息，那么这将是非常有问题的，因为您需要获得最低限度的 FF、Chrome、Safari、IE , Edge, ... 暴露它。
然而，正如在这篇信息安全帖子中提到的，这对于这些浏览器来说并不是一个真正理想的选择，因为它会导致网站开发人员编写代码错误地信任用户端凭据的情况。
阻止 javascript 访问浏览器当前 SSL 证书信息的可见性安全风险与其说是可见性安全风险，不如说是第四道屏障安全风险，其中 JS 开发人员必须意识到“用户接受”的证书不一定是提供的网站。HTML 页面真的不应该处理客户端代码的安全问题，而是应该能够依赖安全层来正确地完成它的工作。（我完全可以理解想要检查安全层，但你在顶层所做的任何管理工作要么是肤浅的，要么是对整个生物圈的改造）
因为让我们暂时假设 javascript 确实提供了一种使用证书的方法，那么当 Bob 已经信任 Mallory 因为他的安全性被破坏时，就无法停止以下交换：
上班族 Bob 位于 Mega Corp. 伟大防火墙的一侧，IT Mallory 负责在本地将流量传入和传出公司的防火墙，而 Web Host Alice 的真棒网站在 WWW 上。
- 根据 Mega Corp. 公司的政策，鲍勃只接受马洛里所说的表面value。
- Bob 想访问 Alice 的站点，但没有直接的外部访问权限，他试图通过持有他的证书（例如：“我在此声明我是 Bob”）来通过防火墙建立安全连接，并以一种非常令人费解的方式询问 Alice ，“我给你发了什么证明？”
- Mallory 收到了 Bob 的请求，但转而传递了她自己的请求（例如：“呃，Bob 说我可以阅读他的网络邮件”），即使 Mallory 不理解 Bob 令人费解的问题，她仍然向 Alice 重复，“akdvyfenwythnwerhy ？”。
- 爱丽丝做了一些数学运算并计算出“akdvyfenwythnwerhy？” 是问“我给你寄了什么证书？” 并用她所看到的回答马洛里（“嗨，鲍勃，这是爱丽丝，你说：呃，鲍勃说我可以阅读他的网络邮件”）。
- Mallory 做了一些数学运算，有一个啊哈时刻“akdvyfenwythnwerhy？=我给你发送了什么证书？”，并代表 Alice 回答 Bob 的问题（“嗨，Bob，这是 Alice（Mallory），你说：我在此声明我是鲍勃”）。
- Bob 相信生活是美好的，并继续阅读他的网络邮件，因为根据公司的政策，他知道 Mallory 永远不会对他撒谎。
- Mallory 现在能够阅读对话的双方，将 Bob 阅读他的网络邮件的请求传递给 Alice。
- Alice 收到 Bob 的请求并说嘿等一下 Bob 我需要你运行这个 JS 代码来证明你知道你正在和 Alice 交谈。
- Mallory 获取代码，运行它，然后将结果发送给 Alice，说明她知道她正在与 Alice 通话。
- 爱丽丝说，这对我来说已经足够了，这是您的网络邮件。
- Mallory 在将邮件传递给 Bob 之前阅读了 Bob 的网络邮件，每个人都非常高兴。
（注意：我没有解决您在服务器端运行 JS 的情况，这取决于您使用什么程序来运行您的 JS 代码。）
编辑 2018 年 4 月 4 日——虽然上述内容没有错，但更多的是从嵌入和链接的 JS 的角度来看，而不是关于“XMLHTTPRequest”JS 对象；此外，反对与 XMLHTTPRequest 共享 PKI 详细信息的最有力的论据很可能如下：
HTTPS 协议的 HTTP 部分和 S 部分之间需要保持一个强有力的分界线。JavaScript 及其XMLHTTPRequest对象驻留在该行的 HTTP（应用程序层）一侧，而整个证书交换过程驻留在该行的 S（传输/秒层）一侧。为了保持安全端的原子性（热插拔），其内部工作不能跨线路暴露给应用程序端；因为可能有一天，传输/安全层不再使用 PKI 证书来促进其安全通信服务，当那一天到来时，没有人需要重写任何依赖这些证书中包含的详细信息来处理的现有 JS 代码随着 www 社区引起的传播波慢慢采用他们最喜欢的任何新安全层的风格。
话虽这么说，在安全性方面确实出现了在某些情况下还可以做法律实体审查--at至少像EV certificates--，这是IMO来的短RFC7230第2.7.2节，它并没有重新定义authority的https-URI包含legalentity安全层在验证与之通信的 url 时将使用的可选内容不仅是正确的端点，而且当前处于预期业务关系的控制之下。
authority = [ userinfo "@" ] host [ "#" legalentity ] [ ":" port ]
legalentity = *( unreserved / pct-encoded / sub-delims )
其它你可能感兴趣的问题