在 Web 浏览器中,JavaScript 是否可以获取有关当前页面使用的 HTTPS 证书的信息?
是否有一种方法可以让在浏览器中运行的 JavaScript 确定使用哪个 CA 证书来验证浏览器当前 HTTPS 连接的远程主机,并获取该证书的属性(例如 CA 的名称)?
如果没有,是否有其他选项可以通过编程方式获取此信息,例如服务器端的 ActiveX、Java、CGI,...?
Is there a method for JavaScript running in a browser to determine which CA certificate is being used to authenticate the remote host for the browser's current HTTPS connection, and also obtain properties of that certificate, such as the name of the CA?
If not, are there any other options for programatically obtaining this information, such as ActiveX, Java, CGI on the server side, ...?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
您可以使用开源 Forge 项目 来执行此操作。它在 JavaScript 中实现 SSL/TLS。您可以对服务器进行 ajax 调用并使用回调来检查证书。请记住,服务器是发送 JavaScript 的服务器,因此不应使用它来确定您是否信任 JavaScript 所在的服务器。 Forge 项目确实允许跨域请求,因此如果您使用它来进行信任,您可以从您已经信任的服务器加载 Forge JavaScript,然后联系您尚不信任的服务器。但是,除非其他服务器提供跨域策略,否则您将无法执行跨域请求。
https://github.com/digitalbazaar/forge/blob/master/README。 md
自述文件中的博客链接提供了有关如何使用 Forge 及其工作原理的更多信息。
You can use the opensource Forge project to do this. It implements SSL/TLS in JavaScript. You can make an ajax call to the server and use a callback to inspect the certificate. Keep in mind that the server is the one sending the JavaScript so this shouldn't be used to determine whether or not you trust the server the JavaScript is from. The Forge project does allow cross-domain requests, so if you are using this for trust, you can load the Forge JavaScript from a server you already trust and then contact the server you don't yet trust. However, unless that other server provides a cross-domain policy, you will not be able to perform the cross-domain request.
https://github.com/digitalbazaar/forge/blob/master/README.md
The blog links in the README provide more information on how Forge can be used and how it works.
从 复制我自己的答案从Chrome扩展程序访问证书信息的方法
2018答案:是的,在Firefox 62中
您需要制作一个WebExtension,也称为浏览器扩展程序。
请参阅访问 MDN 上的安全信息
您还可以查看以下文档:
您需要 Firefox 62。
这是一个有效的
background.js
manifest.json
:它也可以在 Chromium 中实现一次此代码已合并。
Copying my own answer from Is there any way to access certificate information from a Chrome Extension
2018 answer: yes, in Firefox 62
You'll need to make a WebExtension, which is also called a browser extension.
See accessing security information on MDN
You can also check out the docs for:
You'll need Firefox 62.
Here's a working
background.js
manifest.json
:It also may be implemented in Chromium once this code is merged.
Web 浏览器中运行的 JavaScript 无权访问证书信息。证书信息也不通过 HTTP 传递到应用程序。我的研究表明,Web 应用程序无法确定中间人攻击是否在主机和客户端之间的某个位置注入了伪造的证书。
JavaScript running in the web browser does not have access to the certificate information. The certificate information is also not passed through HTTP to the application. My research indicates that there is no way for the web application to determine if a man-in-the-middle attack has injected a bogus certificate somewhere between the host and client.
不,您显然可以使用 AJAX/ActiveX/Java/Flash/Silverlight 和自定义服务器端脚本来完成此操作,但我不明白为什么您需要这个。
编辑:上面的想法是,您将向服务器发出网络请求(使用上述技术之一),并询问该网络请求使用了什么证书。然后服务器可以检查自己的配置并回答问题。
如果浏览器以某种方式信任无效的证书并连接到错误的服务器(例如 MITM 服务器),则该服务器可能会撒谎。一旦浏览器的信任机制受到损害,我不知道如何避免。
据我所知,没有办法(纯粹使用客户端 API)直接询问浏览器“用于浏览器当前的 SSL 连接”使用什么证书。就连 Forge 也不会这么做。它创建一个完全并行 SSL 会话,但它不允许您询问浏览器的本机 SSL 会话。
No. You could obviously do it with AJAX/ActiveX/Java/Flash/Silverlight and a custom server-side script, but I can't see why you would need this.
EDIT: The idea above is that you would make a network request (using one of the above technologies) to the server and ask what certificate was used for that network request. The server could then inspect its own configuration and answer the question.
If the browser is somehow trusting an invalid certificate and connecting to the wrong server (e.g. a MITM server), the server could lie. Once the browser's trust mechanism is compromised, I don't know how to avoid that.
As far as I know, there is no way (purely using client side APIs) to directly ask the browser what cert it's using "for the browser's current SSL connection". Even Forge doesn't do that. It creates an entirely parallel SSL session, but it doesn't let you ask about the browser's native SSL session.
AFAIK 不仅仅使用 Javascript。但有些网络服务器允许您访问线程或进程的连接参数。然后,服务器端脚本可以将这些值与请求一起发送,然后您可以使用它。
我为 nginx 网络服务器找到了这个:
http://wiki.nginx.org/NginxHttpSslModule
(查看页面底部的变量)。应该可以将它们设置为环境变量并将它们传递给您的 FastCGI 进程或您使用的任何进程。
AOLServer/Naviserver 允许使用 nsssl 模块进行类似的访问。
AFAIK not with Javascript alone. But some webservers allow you to access the connection parameters of the thread or process. A serverside script can then send those values along with the request and you use it.
I found this for nginx webserver:
http://wiki.nginx.org/NginxHttpSslModule
(Look at the bottom of the page for the variables). It should be possible to set them as environment variables and pass them to your FastCGI processes or whatever you use.
AOLServer/Naviserver allows similar access with the nsssl module.
实际上,这没什么用处——为什么您需要从已呈现的单个页面上的 JavaScript 了解证书信息?
如果它不可信,那么显然您的代码也可能已被更改,因此,它也不能被信任。
如果它不可信,
如果证书实际上是受信任的,那么您如何区分该情况与证书不受信任的情况,但您的代码已通过 MitM 攻击进行了修改,以防止出现其他情况?
因此,检查证书仅在浏览器扩展(假定为可信代码)中有用,而不是在各个页面中的脚本> 他们自己。扩展使用的此类接口是特定于浏览器的,并且并非所有浏览器都提供它。例如,Mozilla 浏览器确实允许您查看证书(提供诸如 EFF SSL Observatory),
In practical terms, this has little use -- why would you need to know certificate information from JavaScript on the individual page already rendered?
If it's not trusted, then obviously your code could have been altered, too, so, it cannot be trusted, either.
If the certificate is actually trusted, then how would you be able to distinguish the scenario from the one where the certificate is not trusted, but your code has been modified through a MitM attack to think otherwise?
So, checking certificates would only be useful from within Browser Extensions (which are presumed to be trusted code) as opposed to the scripts in the individual pages themselves. Such interface that extensions use is browser-specific, and not all browsers even provide it. For example, whereas Mozilla browsers do let you peek into the certificates (affording extensions like the EFF SSL Observatory), Chromium is still lacking.