我正在开发一个web应用程序,它可以与本地安装的桌面应用程序通信,从用户机器获取证书信息并执行数字签名。
目前,可以使用window.crypto自动生成密钥并在javascript中使用这些自动生成的密钥执行数字签名。但是,无法通过javascript或html访问安装在OS或Firefox keystore上的供应商CA发出的用户密钥来执行数字签名,这就是我们在安装的本机应用程序上转发的原因。
这个本机应用程序是一个旧的java小程序的移植,因为--希望很快--这一技术不会被所有主流浏览器所支持(目前它是自2015年9月以来未在Chrome上得到支持,而且在边缘中也不支持),除了java插件本身,它还将是在Java 9中被废弃。目前,我们已经有了一个Java Web开始工作,但是有一种替代的方法来执行签名是一种要求,因为JNLP并不是非常适合用户的方式:它需要每次在具有签名配置的用户机器上下载JNLP,没有从浏览器到JNLP的通信,并且有必要对后端执行AJAX轮询以检查签名是否完成.
本机应用程序基本上是一个本地http服务器,它通过REST公开业务方法,这样只需对结果进行一些AJAX调用就可以轻松地从我们的web应用程序中使用。
当web应用部署在HTTP中时,它工作得非常完美,问题是我们的web应用程序在HTTPS下是安全的,但是我们的本地应用程序是HTTP服务器,因此在默认情况下,主要的浏览器会由于混合内容而阻止我们从web应用程序到本地应用程序的AJAX调用。
任何CA供应商都将为本地主机域颁发服务器证书,而且由于本机应用程序安装在客户端上,私钥将在每台客户端机器上可用,因此由官方CA颁发的证书是不可能的。还请注意,我们的本机应用程序必须在异构环境中工作:不同的操作系统、不同的浏览器、不同的网络,因此SSL的代理解决方案也不是一种选择。
我想到的一个可能的解决方案是生成一个自签名证书,并将我们的本地应用程序配置为HTTPS服务器。不过,我在这个解决方案中发现了一个缺陷:本机应用程序或客户端必须手动在客户端所以信任存储中安装此证书,或者在firefox信任存储中安装该证书,这是一个安全问题,因为您要在信任存储中添加一个自签名证书。
我的问题是:
CN=127.0.0.1颁发证书,如果网络上没有代理或被编辑的主机,那么第三方服务器不可能为您提供内容服务,不是吗?这个解决办法听起来有那么糟糕吗?发布于 2016-11-25 16:26:50
每个这样做的人(github,spotify,暴雪,dropbox等)去年都看到他们的证书被吊销,因为私钥是在本地存储的,并且被认为是被破坏的。
有两个解决办法:
如果原产地的主机组件匹配CIDR符号之一127.0.0.0/8或::1/128 RFC4632,则返回“潜在可信”。
您可以从CA获得local.myapp.com这样的域的标准证书,并将此主机与dns中的127.0.0.1相关联。
这将使https调用从您的网页到您已安装的应用程序。
请注意,这可能存在安全问题。实际上,Chromium打算阻止这些对本地主机的调用(或者添加一个选项来选择-> https://bugs.chromium.org/p/chromium/issues/detail?id=378566)。但是多个网站正在这样做:
关于Spotify如何实现它的解释:http://cgbystrom.com/articles/deconstructing-spotifys-builtin-http-server/
由于需要使用HTTPS,因此需要一个有效的SSL证书来避免浏览器的抱怨。Spotify通过注册一个仅指向127.0.0.1的域(*.spotilocal.com)来解决这个问题。但是,它们没有连接到顶级域,而是使用通配符域,每次都连接到随机子域(例如abcrjdknsa.spotilocal.com)。这样做的原因是为了避免浏览器对每个域的最大连接限制,允许浏览器中更多的选项卡并发使用它们的API,而代价是额外的DNS查找。
https://softwareengineering.stackexchange.com/questions/336821
复制相似问题