代码之家  ›  专栏  ›  技术社区  ›  DougN

自签名证书-帮助用户知道他们需要将根CA添加到受信任的证书存储

  •  4
  • DougN  · 技术社区  · 15 年前

    我有一个桌面产品,它使用嵌入式Web服务器,该服务器将使用自签名证书。

    有没有什么东西我可以放在一个网页中,检测到他们没有将根CA添加到他们的可信列表中,并显示一个链接或DIV,或者指示他们如何做?

    我想可能是一个DIV有安装CA的指令,以及一个运行一些测试的javascript(试图访问一些没有内部警告的内容??),如果测试成功,则隐藏DIV。或者类似的…

    有来自优秀社区的想法吗?:)

    9 回复  |  直到 8 年前
        1
  •  10
  •   markusk Kiril Kirilov    15 年前

    你为什么要这样做?培训用户不分青红皂白地安装根CA证书是一个坏主意,因为网站告诉他们这样做。你在破坏整个信任链。有安全意识的用户会忽略您安装证书的建议,并可能得出结论,您没有认真对待安全性,因为您不必费心从现有CA获取证书。

    你真的需要https吗?如果是这样,您可能应该咬紧牙关,与CA达成协议,以便为客户提供适当的CA签名服务器证书。如果Web服务器仅用于来自桌面应用程序的本地连接,则应将自签名证书作为安装过程的一部分添加到受信任列表,或者切换到HTTP。

        2
  •  2
  •   abmv    15 年前

    假设您知道C并且您想安装一个pfx文件,那么创建一个将从URL运行的exe。 Follow this URL

        3
  •  2
  •   Einstein    15 年前

    我唯一的想法是使用框架和一些JavaScript。

    框架的第一个元素将充当看门狗,等待x时间(javascript settimeout),然后用超链接或指令向用户显示自定义的SSL故障消息,以下载自签名证书。

    第二个frame元素尝试HTTPS连接,如果成功,则重置看门狗帧,使其永不触发。如果失败(假设https证书验证失败),那么看门狗消息将被激发并显示给用户。

    根据浏览器的不同,您很可能仍然会看到这种方法的一些安全警告,但您至少可以在不要求用户运行不受信任的代码的情况下推送自己的内容,而不需要使用适当的信任链(这比接受证书验证错误和建立不受信任的POV更糟糕)SSL会话

    可以使用其他测试方法(如xmlhttprequest等人)对概念进行改进。

        4
  •  2
  •   tomjen    15 年前

    你不应该这样做。根证书并不是您刚安装的,因为添加一个根证书可能会破坏HTTPS提供给您的任何安全性。

    但是,如果您正在制作桌面应用程序,那么只需收听127.0.0.1。这样,流量就不会离开用户的计算机,而且没有攻击者可以监听。

        5
  •  0
  •   Alexander Kosenkov    15 年前

    您可以尝试在每个用户会话中添加一些(隐藏的)Flex元素或Java Applet。 它将只下载服务器的任何HTTPS页面,并获取有关连接的所有信息:

    com.sun.deploy.security.CertificateHostnameVerifier.verify()
    or
    javax.security.cert.X509Certificate.checkValidity()
    

    我认为flex(对用户来说更常见)应该有类似的方法从用户的角度验证HTTPS证书。它还应该共享OS的可信证书存储,而Java可能有它自己的。

        6
  •  0
  •   SpliFF    15 年前

    因为服务器运行在客户机(桌面产品)上,它不能使用winapi/os函数检查支持的浏览器中是否安装了证书?我知道火狐在用户的配置文件目录中有一个证书数据库,IE可能在注册表中保存信息。它对所有浏览器都不可靠,但是如果服务器只是在“找到证书”和“继续之前请确保已安装了证书”之间进行选择,那么不会造成任何伤害,因为用户可以选择以任何方式继续。

    您还可以通过提供嵌入式浏览器(即Gecko)来简化问题,这样您只有一个浏览器可以处理,这简化了很多事情(包括预安装根CA)。

        7
  •  0
  •   Mr. Shiny and New 安宇    15 年前

    回顾一下:您正在桌面应用程序上设置WebServer;每个桌面都有自己的Web服务器,但您希望使用SSL来保护到该Web服务器的连接。

    我想这里的证书有几个问题,一个是用于访问桌面的主机名必须与证书匹配。在这种情况下,除了在客户机上生成证书,您别无选择。您需要允许用户以某种方式指定主机名,以防无法从主机本身检测到外部人员使用的名称。

    我还建议允许管理员为那些不想依赖自签名证书的人安装可信证书。这样,您还可以将可信证书维护的成本转移给真正需要它的管理员。

    最后,根据我的经验,浏览器允许或拒绝自签名证书,服务器无法知道证书是否被拒绝、临时接受或永久接受。我假设在某个地方必须有一种机制来处理SSL故障,但是典型的Web编程不在该层上运行。在任何情况下,如果SSL失败,Web服务器唯一能做的就是回退到非SSL,并且您在注释中指出您不能拥有任何非SSL。我认为您应该尝试解除这种限制;在这种情况下,非SSL起始页将非常有用:它可以测试(使用帧或图像或JSON或AJAX)HTTPS连接,并且可以链接到有关如何设置证书的文档,或者在何处下载证书的安装程序。

    如果浏览器因为自签名证书而无法连接,并且根本不允许您使用纯HTTP,您还可以通过其他什么方式与用户通信?没有其他渠道,你无法建立,因为你没有任何沟通。

    您在编写用于安装证书的Win32应用程序的注释中提到过。您可以在安装应用程序本身时安装证书,但这对任何远程浏览器都没有帮助,并且本地浏览器不需要SSL来访问本地主机。

        8
  •  0
  •   dlongley    14 年前

    我们一直在研究一个名为forge的开源JavaScript项目,它与这个问题有关。你有你的用户可以访问的网站吗?如果是这样,那么您可以通过您的网站使用Flash for Cross Domain+javascript for TLS提供到这些桌面应用程序的安全连接。它将要求您在您的网站上实现一些Web服务来处理桌面应用程序证书的签名证书(或者让您的桌面应用程序上载自签名证书,以便通过javascript访问它们)。我们在这里描述它是如何工作的:

    http://blog.digitalbazaar.com/2010/07/20/javascript-tls-1/

    另一种设置网站的方法是直接在桌面应用服务器上托管javascript+flash,但由于它允许MITM攻击,因此安全性较低。您可以让您的用户通过常规HTTP访问桌面应用程序,下载JS+Flash+SSL证书,然后通过JS开始使用TLS。如果您使用的是本地主机连接,那么MITM攻击可能就不那么令人担忧了——可能足以让您考虑使用此选项。

        9
  •  0
  •   Chris Cashman    8 年前

    ActiveX控件可以做到这一点。但我真的没有插话来帮助解决问题,更多的是不同意你所做的是一个安全风险的立场。

    要清楚,您需要一个安全的密码(希望是AES而不是DES),并且已经控制了您的端点,只是不能完全排除可能捕获明文密码或其他敏感数据的混杂模式网络嗅探器。

    SSL是一个“安全套接字层”,根据定义,它不依赖于任何证书。

    然而,所有有效的现代密码都要求它对隧道端点进行身份验证,这并不总是每个应用程序都必须的;我在许多使用Web服务API管理节点的后端数据中心自动化例程中遇到了一个挫折,“用户”实际上是之前需要加密密钥交换的过程。进行一次平静的指挥谈判。

    在我的例子中,VLAN是通过ACL保护的,所以我真的“可以”发送明文身份验证头。只是打字让我有点吐出来。

    我敢肯定我会因为输入这个而生气,但我已经非常有战斗力了,在我的IT职业生涯的10-15年里,我也会对你做出同样的评价。所以我同情他们的担心,非常感谢他们对安全感的热情是否足以点燃我的火焰。他们最终会解决的……

    但我同意这样一个事实,即“培训”用户自己安装根CA是一个坏主意。另一方面,如果您使用自签名证书,则必须培训他们安装该证书。如果一个用户不知道如何确定一个CA证书是否可信,那么他们肯定无法从一个CA证书中确定一个自签名证书,因此任何一个过程都会有相同的效果。

    如果是我,我将自动化流程,而不是让它帮助最终用户,这样它就可以尽可能地对他们隐藏起来,就像一个合适的pki对企业所做的那样。

    说到这个,我就想到了一个可能的解决办法。使用Microsoft PKI模型。使用Server 2012 R2,您可以通过“工作区”使用“设备控制”向甚至不是域成员的端点传递受信任的密钥,并且客户端计算机可以订阅多个工作区,因此如果它们订阅,则它们不会仅提交给您的工作区。一旦完成并进行身份验证,AD证书服务角色将推送Active Directory或指定LDAP服务器中存在的所有必需根CA证书。(如果您使用的是脱机CA服务器)

    同时,我也意识到这条线有7年的历史了,但是我确信它仍然会被大量需要类似解决方案的人引用,并且感觉有义务分享一个对比的观点。(好的,微软,我给你的插头的回扣在哪里?)

    -现金男