CA被黑客入侵有多可行？我应该删除哪些默认的受信任的根证书？

#1 楼

更新5 CA模型的根本问题（heh）是，在一般情况下，任何CA都可以为任何域颁发证书，因此您很容易受到最弱链接的攻击。至于您可以信任的人，我怀疑这个名单太长了，因为风险很高，安全性也很困难。我推荐Christopher Soghoian在该主题上的帖子，该帖子阐明了世界各国政府用于访问私有用户数据的各种方法-无论是通过运行窃听还是直接通过运营云服务的公司直接要求它，或者现在越来越多地通过CA强制要求或骇客：轻微的偏执狂：导致DigiNotar骇客的力量。

在此，我提供一些细节，最后提供一些潜在修复程序的链接。

2009年，Etisalat（阿联酋政府拥有60％的股份）推出了看起来很无害的BlackBerry补丁程序已将间谍软件插入RIM设备中，从而可以监视电子邮件，因此很难认为它是可信赖的。但是它在许多受信任的CA列表中：
http://arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars

更新1另请参见成功攻击的示例，据称是伊朗人ComodoHacker攻击Comodo：Rogue SSL证书（“ case comodogate”）-F-Secure Weblog。 F-Secure指出，Mozilla包括中国，以色列，百慕大，南非，爱沙尼亚，罗马尼亚，斯洛伐克，西班牙，挪威，哥伦比亚，法国，台湾，英国，荷兰，土耳其，美国，香港，日本的CA颁发的证书，匈牙利，德国和瑞士。

突尼斯是另一个运营着广受信任的CA的国家，并且也有很好的文件证明了其政府侵犯隐私的行为：Facebook如何回应突尼斯黑客的内幕-Alexis Madrigal-技术-大西洋

Mozilla注意到需要注意的另一种可疑做法：CA允许RA合作伙伴直接从根目录而不是通过中介发布证书：Comodo证书发行– Mozilla安全博客的后续。
另请参见，包括有关一个孤独的伊朗黑客Web浏览器对责任主张的猜测，以及Comodo披露了一次成功的证书颁发机构攻击，也许来自伊朗|修补匠的自由

更新3：ComodoHacker似乎也对DigiNotar CA发起了另一次成功的攻击。他们的网站从2009年开始遭到入侵，但直到2011年伊朗人还使用DigiNotar来为Google，Yahoo！，Mozilla，WordPress和The Tor Project的网站签署虚假证书后才注意到。 DigiNotar已有一个多月没有透露其入侵网站的知识。在DigiNotar上了解更多信息Hack重点介绍了SSL Web安全模型的严重故障|修补匠的自由。

我猜想，各种CA的脆弱性范围以及它们的效用都相差很大。因此，我建议您调整策略重点。当您可以将其范围缩小到要保护的特定资产时，只需删除所有CA（使用这些资产所需的CA除外）。否则，请考虑消除那些认为您最容易受到资产关注或最不受欢迎的CA，以减少攻击面。但是请接受这样一个事实，即使用最流行和最仔细的CA，您仍然会遭受复杂的攻击。<​​br />
更新2：在Freedom to Tinker上修复危险的CA基础设施方面，有一篇很棒的文章：更好的CA基础架构

它讨论了这些创新：


ImperialViolet-DNSSEC和TLS
网络公证人-观点：改进SSH样式的主机身份验证多路径网络探测功能
Google在线安全博客：提高SSL证书的安全性

Update 4我们在2011年8月发布的IT安全博客文章中还包括了转向DNSSEC的案例：
基于风险的解决证书颁发机构问题的解决方法«Stack Exchange Security Blog

Update 6一些证书颁发机构被发现违反规定。其中包括法国网络防御机构（ANSSI）和Trustwave，它们中的每一个都与欺骗性数字证书相关联。 （印度CCA）2014年：Google在线安全博客：维护数字证书安全性

另请参阅“证书透明性”问题，它看起来像是一种有助于早期发现不良证书和违反政策的方法。

#2 楼

正如马特·布拉兹（Matt Blaze）曾经写道的那样，CA可以保护您免受任何他们不愿意从中获利的人的侵害。那应该告诉您有关CA激励机制的位置以及该安排中的一些潜在风险的信息。

#3 楼

恐怕这个问题的简短答案是，据我所知，这是不可能知道的。大多数常见的浏览器中都安装了大量默认CA，并且很难评估将证书颁发给政府或其他组织的“可信度”。

如果CA成为被称为不可信，那么它们很可能会从浏览器的默认安装列表中删除（根据下面的@ xce，Diginotar是一个很好的示例，Digicert也是一个很好的例子）

他们有可能在没有对请求者进行适当安全检查的情况下提供证书的风险。几年前，在Defcon上有多次主题演讲，主题是无需授权即可获得证书。

如果这是一个令人担忧的问题，那么我唯一想到的方法就是创建您已审核过的CA的白名单，并对提供的安全性感到满意。显然，这对于访问常规Internet无效，因为您最终可能会删除对您要使用的站点有证书问题的CA。

#4 楼

2个示例成为您需要了解的内容的核心内容，而不是您明确要求的内容：


几年前（2006年或2005年底），广为宣传的SSL网络钓鱼事件-一家伪造的银行网站收到了合法的SSL证书（我相信是从GeoTrust获得的），原因是该地区银行的网站存在拼写错误。 （更新：找到了这个历史链接-地址是银行的全名，而不是简称）。从那时起，还有其他案例发生网络钓鱼（SSL）网络钓鱼。。。要点是，无需借助“强制”即可获得证书。
最近的Stuxnet中篇小说，除其他策略外，还依赖于被盗证书。这些是从第三方驱动程序制造商那里“借来的”，并且由于它们是“受信任的”，因此可以被滥用以植入恶意软件。

然后，当然还有一些甚至没有使用CA的软件方案-例如具有调用Web服务的胖客户端，而不必费心验证服务器的证书...。

我的意思是，如果您担心基于SSL的MITM，通常（不是）应该让您担心的政府强制措施。通常有更简便，更易用的方法。
我什至反对“受信任的证书”被称为“受信任的” ...仅仅因为我知道你是谁，并不意味着我应该信任你...而且这并不意味着我应该相信您知道别人是谁。

更不用说，如果您从受信任的存储区中删除标准根证书，那么Internet上的许多站点将无法正常工作。

另一方面，如果您要处理的服务器/设备不需要一般的浏览功能，但要与特定的服务器（或一组服务器）通信，则一定要删除所有根证书，除了需要的白名单。
如果使用自己的内部CA，那就更好了....

#5 楼

每个CA都会发布一个证书实践声明，描述它们如何保护自己的密钥，并在颁发证书之前验证对证书的请求。该文档所在位置的URL通常嵌入在CA颁发的每个证书中。假设所讨论的CA确实遵循了此策略文档，则应向您说明它们用来确定请求证书的实体的有效性的长度。寻找陈述，表明他们使用硬件安全模块或加密模块来保护其CA签名密钥来保护签名密钥，多因素身份验证和基于仲裁的授权来签署证书等。这些保护方法使其变得更加困难且昂贵让流氓第三方窃取签名密钥。

大量受信任的CA（我的Mac System根钥匙串有175个）在这里为您提供方便，以使HTTPS系统可用于您以及不问这些问题的地球上的每个人。当然，您可以将每个CA排除在此列表之外，除非您亲自审核了它们的做法。对于封闭系统，在该系统中，您可以控制所有端点，并且受信任方的数量有限，这是可行的。 Subversion版本控制系统不包含任何受信任的Root证书，但是欢迎您为每个客户端添加自己的证书。对于整个网络，我们发现使其可用的唯一方法是让带外受信任方（提供操作系统或浏览器的公司，无论您如何看待它们）提供受信任的列表。证书，使您可以连接到世界上几乎所有启用SSL的服务器。

您是否真的需要信任列表中的所有这些证书？可能不会。但是您的OS /浏览器供应商无法预期（也不应该控制）您想与谁开展业务，因此它们包含了所有功能。大列表的问题在于，您拥有来自所有辖区的所有羽毛的CA，以及各种验证方法，它们的处理方式完全相同。并非每个CA都具有相同的作用：我们已经看到了受损的经销商登录凭据甚至CA密钥受损的情况。有些CA要求提供公司注册证书和您的长子的承诺，而其他CA仅验证您可以在您要申请证书的域上收到电子邮件。但是，您的浏览器将每个CA完全相同地对待。

针对相同通用名称的流氓证书的防线将是在客户端上缓存原始证书：如果突然出现了来自不同CA的不同证书，则应该引起关注。我不知道今天的浏览器如何处理这种情况，而且我也懒得找出答案。

#6 楼

这种讨论总是使我想起这个Mozilla错误，要求包含一个新的CA。非常好笑，但很有见识。

#7 楼

我相信几年前美国政府曾试图通过立法，赋予他们权力以迫使CA产生第三方的有效证书以进行窃听或不进行窃听。我找不到这方面的证据，所以我可能想起了DefCon谈话中提到的Rory。

#8 楼

假设一些糟糕的政府希望看到计算机的SSL流量。强制默认CA颁发新证书的可行性如何？


谓词和问题无关。强制CA颁发新证书的难易程度或频繁程度无关紧要-可能的窃听者看不到您的数据，除非它们具有已安装证书中的私钥。 IIRC（但我建议您检查一下），CSR不包含私钥-因此CA无法以这种方式获得它。他们无法更改您的计算机使用的密钥。

但是，流氓CA可能会颁发伪造的证书-这样一来，您的站点就有可能遭受MITM攻击。 MD5格式和Etisalat的最新问题表明它并非不可能。

#9 楼

研究要在Windows PC中删除的证书时，首先应确保未删除系统所需的证书。如果尝试这样做，将会收到以下错误消息



这是带有证书列表的URL，这些证书不能从Windows系统http中删除： //support.microsoft.com/?id=293781

接下来，您应该考虑删除（测试删除）中间证书，因为它们仅“纯粹出于遗留原因”存在。

在评估删除所有剩余证书时，请考虑Microsoft根证书计划要求CA通过以下审核标准之一：


ETSI 102 042
ETSI 101 456
用于CA的WebTrust
WebTrust EV就绪审核
ISO 21188（请注意，它们不接受ISO 27001）

如果要从非MSFT浏览器（IE），则您可能需要查看这些CA质量准则。

限制

该程序还具有适用于密钥用法的其他审核。密钥用法仅限于以下用途：


服务器身份验证（SSL）= 1.3.6.1.5.5.7.3.1
客户端身份验证（SSL）= 1.3.6.1.5.5 .7.3.2
安全电子邮件（SMIME）EKU = 1.3.6.1.5.5.7.3.4
代码签名EKU = 1.3.6.1.5.5.7.3.3
时间戳EKU = 1.3.6.1.5.5.7.3.8
OCSP EKU = 1.3.6.1.5.5.7.3.9
加密文件系统EKU = 1.3.6.1.4.1.311.10.3.4

禁用的密钥用法

以下密钥用法被禁止通过以下程序：智能卡登录这是仅限企业的方案，因为需要Active Directory部署，并且必须将根添加到Active Directory中的NTAuth存储中。有关详细信息，请参见以下知识库文章。 http://support.microsoft.com/default.aspx?scid=kb;zh-CN;Q281245
数字版权此EKU已过时。 Windows Media DRM将其自己的XML格式用于许可证，而不使用X.509。
限定从属此EKU已过时，Windows会忽略。
密钥恢复企业CA方案。
文件恢复此EKU已过时，并且被Windows加密文件系统（EFS）忽略。
所有应用程序策略我们不能授予“所有用途”，因为这必然允许企业专用的EKU和其他不可接受的EKU。复制企业方案
证书请求代理
企业CA方案
密钥恢复代理企业CA方案
CA加密证书
企业CA方案

接受条件

此外，在根目录上添加通用或政府CA之前，必须满足以下条件：


CA必须提供以下要求的信息（请参阅第1步。请与Microsoft联系），并获得该计划成员资格的初步批准。
CA必须提供一个由CA的根证书颁发的测试证书，用于测试。可选地，CA可以向Microsoft提供可公开访问的服务器的URL，在该URL中可以验证从其根证书颁发的证书。 （有关详细信息，请参阅常见问题解答）。
CA必须完成Microsoft CA协议。只有在您完成了申请流程的第1步并获得了您的申请的初步批准之后，我们才会提供该协议。
根证书必须符合下面的“技术要求”部分。特别是，对于任何根和所有颁发CA，我们都要求RSA 2048位模数的最小加密密钥大小。 Microsoft将不再接受具有任何到期的RSA 1024位模数的根证书。我们希望新的根从提交之日起至少有效8年，但在2030年之前过期，尤其是当它们具有2048位RSA模数时。
从根证书颁发的证书必须支持CRL分发点扩展。 CRL分发点应指向可公开访问的位置。
CA必须具有成文的撤销策略，并且CA应该能够撤消其颁发的所有证书。

CA必须每十二（12）个月完成一次审核并将审核结果提交给Microsoft。审核必须涵盖Microsoft将通过分配扩展密钥用法（EKU）启用的完整PKI层次结构。我们启用的所有证书使用情况都必须定期审核。审核报告必须记录PKI层次结构的完整范围，包括颁发审核所涵盖的特定类型证书的任何子CA。合格的审核包括：



用于证书颁发机构的WebTrust v1.0或更高版本，由许可的WebTrust for CA审核员完成，
ETSI TS 101 456 v1.2.1或更高版本，
/> ETSI TS 102 042 V1.1.1或更高版本，或者
ISO 21188：2006，“金融服务的公共关键基础结构-做法和政策框架”，由CA审核员的授权WebTrust或



















我们保留更改上述审核和/或将来接受其他类似审核的权利。

技术要求

新的根证书必须满足以下技术要求：


根证书必须为x.509 v3证书。
主题名称必须包含有意义的CA名称（例如，不能为“ Root”或“ CA1”）
基本约束扩展：cA = true
密钥用法（如果存在）：仅keyCertSign和cRLSign

根密钥大小要求基于NIST SP 800-57：

     RSA greater or equal to 2048-bit modulus

     ECC greater or equal to P256 modulus

哈希算法必须至少为SHA1。不接受MD2，MD4或MD5哈希。
对于大于或等于RSA 2048位模数的根密钥，根证书必须在提交后至少8年且不迟于2030年到期。
中级CA证书不包括在根CA程序中（有关更多信息，请参见常见问题）。
CA不会颁发MD2，MD4或MD5从属或最终证书。由本程序分发的任何根证书中的实体证书，于2009年1月15日生效。
现有的（“旧版”）1024位RSA根证书可以由本程序分发，直到NIST截止日期为2010年12月31日为止，除非Microsoft另行提供。
CA可以从本程序分发的根证书中颁发1024位RSA证书，直到NIST截止日期为2010年12月31日为止。

#10 楼

使用MD5弱点创建恶意CA的演示：


原始研究
新闻报道

#11 楼

尝试着眼于第二个问题。

问题“我应该删除哪个默认受信任的根证书？”基本上取决于您与谁打交道。

您将“仅”需要信任对您所连接的任何网站进行签名的所有CA。

对于奶奶类型总是访问相同站点的用户，可能只有少数几个CA就足够了，而对于大量的Internet用户来说，列表却不会*如此迅速地增长。违反直觉的是，一些CA被大量使用（包括太大到无法使用的CA），而另一些CA则很少像几乎是地理上的CA那样在Internet上使用。

工具
缺省情况下，来自securitybydefault的SSLCop可能有助于阻止您不信任/不太可能需要的国家（例如，您不希望访问Brobdingnag政府的网站，而Brobdingnag政府恰好是该CA的主要用户）：
http ：//www.security-projects.com/？SSLCop

但是，如果您不信任太多的CA，最终将无法获得对用户所需网站的信任锚（并且无论是否有安全警告，都将继续访问它们），这同样很糟糕。

#12 楼

自2012年6月12日起，Microsoft发布了一个新的更新程序，它将禁用不受信任的根证书和任何其他报告给Microsoft的不可信证书。

此更新可用，目前尚不清楚更新已通过Windows Update发布，或者它是带外更新。

http://support.microsoft.com/kb/2677070