如何将链接(图标,...)放入我的网页以显示当前的SSL证书信息?
最简单的方法可以是链接到一些在线网站验证器(第三方或我们自己的),但如果可能的话,内置的弹出浏览器信息会很棒。
我认为强调SSL安全性(例如,接近"购买"按钮)或当涉及存在框架和/或多个资源时,或者未知使用的特定证书时,...
存在某种方式吗?
谢谢!
更新:
答案 0 :(得分:1)
我认为没有办法做到这一点,我认为这不是一个好主意:访问有关证书的信息必须控制用户,而不是网站。否则该网站可以声称它想要的任何东西。此外,指向在线验证器的链接也具有误导性,因为该网站可能与验证者看起来与用户不同。
除此之外,仅仅使用SSL对网站的安全性并不多。任何人都可以获得这样的证书,仍然存储未加密的密码,信用卡信息松散,被黑客攻击或传播恶意软件。
答案 1 :(得分:0)
如何将链接(图标,...)放入我的网页以显示当前的SSL证书信息?
据我所知,没有这样的功能,在浏览器中实现这样的功能并不是一个好主意。
检查您的用户与您的网站之间的连接的安全性是遗憾的是您无法做任何事情。无论你从你的目的做什么都充其量只是一个噱头,最坏的情况是给用户一种虚假的安全感,可能会误导他们检查错误的东西并鼓励攻击者模仿你尝试过的那些迹象显示。
这实际上是一个非常基本的安全原则,只能通过教育用户来解决(这就是试图让他们检查错误的东西会导致弊大于利)。
引用Iszi from Security.SE:" 如果你要问这条线是否安全?",那么答案是" no"。 "
你从网站上做的任何事都可能是伪造者可以做的事情。
想象一下你确实可以点击并有一些弹出窗口显示网站安全网站的情况。这将使一个非常敏锐的用户必须寻找真正的浏览器对话框和虚假弹出窗口的迹象。
最终用户有责任检查是否使用了HTTPS并且正确使用了它。
这是一个更普遍的安全问题,实际上并非特定于计算。如果客户走进假冒银行冒充合法银行的名义存钱,合法银行就无法做任何事情。只有用户才能在进入大楼时进行任何必要的验证。
从安全角度来看,您尝试展示的信息不应由您访问的网站控制。这些验证有由浏览器本身完成,以供它们使用,否则它们将是无足轻重的。
混淆浏览器内容和来自网站的内容的用户界面通常不利于安全性。 (这就是full screen mechanisms必须具有特定于浏览器的UI组件的原因,这些组件不能由站点伪造,否则会带来安全风险。)
您可以做的第二件事就是尝试教育您的用户:例如,show是一个快速教程,向您的用户解释如何在浏览器中检查证书。这对所有人都没有帮助,如果有实际的攻击,但从长远来看它可以提供帮助。这是银行在不断告诉您的时候使用的策略" 不要向任何人提供您的PIN码或密码,我们的员工都不会要求他们" :这只会鼓励用户在有一天声称自己是员工的人试图获取这些详细信息时收到警报。银行无法在用户和假银行员工之间做任何事情(因为它甚至不在那里),但至少它会尝试提前教育用户。
从用户的角度来看,能够评估连接的安全性是一项棘手的工作,并不总是能够帮助改变用户界面。您提到的另一个类似系统是许多CA提供的外部安全封条。不幸的是,它们也不是一个好主意......
另一方面......"提供了一种查看与页面相关的证书的方法。当然?你试过我的例子吗? (例如在Firefox上)
让我们试试你的榜样吧。无需在page you link to上尝试表格,我们可以看到这样的印章,因为它位于该页面的底部。有一个徽标表示" ...安全,由..."提供,link to a certificate verification service,显示看起来令人放心的信息,例如&#34 ; 本网站可以使用SSL证书保护您的私人信息。与任何以https开头的地址交换的信息在传输之前使用SSL加密。"。
所有看起来都很好。
现在,首先,我在普通HTTP上的页面服务器上获得了这个封条,因此在该页面上肯定没有任何证据。让我们假装所有用户都明白,只有在同一主机名上使用https://
服务的网页才会受到该封印的保护。
当用户的浏览器(U)连接到站点(S)时,它获得证书(CS_from_U):这是用户想要验证的证书。
当用户的浏览器连接到信任印章信息站点(T)时,该系统显示它能够获得的证书(CS_from_T),但浏览器没有发送任何关于它见过的证书(CS_from_U)到T。
从U到S的连接(使用CS_from_U),从U到T的连接以及从T到S的连接(使用CS_from_T)是三个不同的连接。
T告诉你关于证书的事实上是关于合法证书CS_from_T。 U和S之间可能存在MITM攻击,这使CS_from_U成为与CS_from_T不同的证书(事实上,有些webfarms有时也使用不同的证书,无论如何都没有攻击)。
当然,非法的CS_from_U证书仍然必须由用户浏览器信任的东西发布,但这可能发生在手动异常,公司MITM代理或其他犯了错误的CA上。
实际上,这种密封验证对用户看到的证书没有多大帮助。它主要证明合法服务器确实从该CA购买了证书。它当然不能证明另一个证书不是由另一个CA颁发的,或者当时用户看到的证书是CA合法颁发的证书。
当然,很难评估风险的可能性。攻击者的困难部分是能够执行MITM攻击并拥有将被用户信任的证书(例如,来自欺诈CA),这有望是不可能的。在那个阶段,密封验证器显示的内容完全无关紧要。
最后,密封标识主要为用户提供安全的假象,因为它检查的内容假定它显示的内容没有被篡改。任何假设没有问题的逻辑推理都可以得出确实没有问题的结论。
在好的方面,this particular seal不仅仅是证书:它还有一个恶意软件扫描和漏洞评估部分,一般来说这肯定是一件好事。我不确定是否有其他CA,但这种服务可能很有用。
我一般都没有试图破坏CA系统,并且我没有反对此示例中使用的特定CA. CA系统充满了不完善之处,但很难找到更普遍适用的更好的解决方案。我试图指出的是,这种密封系统对证书没有真正的安全性。然而,这样的印章所做的是向其每个顾客的访客宣传CA,因此他们有告诉人们使用这些的既得利益。
总结:
如果您这样做的动机是从安全角度帮助用户,那么您可以做的最好的事情就是尝试教育他们。为了防止伪造UI元素,这些验证有由用户启动并通过浏览器而不是网站完成。
如果不是,或者除此之外,你还必须经过一个盒子勾选练习并显示一些看起来漂亮的符号(可能是由于商业压力),只需粘上你的印章即可。已经从您网页上的CA获取。