google.com”，在该服务器上创建CSR，然后将其发送给证书颁发机构进行签名吗？假设我选择了我能找到的最便宜，最便宜的服装。那行得通吗？有什么机制可以阻止人们这样做？
我很清楚，由于指向真实Google的DNS记录，我不会收到发往google.com的任何流量，但是我MitM可以使用此方法攻击任何Google流量。我也可以将本地流量重定向到我自己的服务器上，而用户却不知道。
#1 楼
这比您想象的要成问题，尤其是对于像Google这样的公司而言，因为它们是这类恶作剧的常见目标。但是有多层保护措施，随着时间的流逝，我们的保护也会越来越好。您的第一道防线是证书颁发机构。
他们不应让证书签署不当。每个CA都有自己的机制来验证您是否有权购买给定域的证书，但是通常它包括让您执行以下一项或多项操作：
验证列在其中的电子邮件地址的所有权域的WHOIS信息。
验证电子邮件地址的所有权，该电子邮件地址遵循域上几种预定模式之一（例如“ administrator @ {domain}”）
在域上创建特定的DNS记录
/>对该域名托管的网站进行了特定更改
，但是由于我们拥有的CA数量众多，因此发布了数量惊人的不当证书。这是“您实际上只有一份工作”的情况，但我们必须接受会发生错误的情况。
创建了证书透明性来帮助审核CA
CA的问责制和透明性，因此Google决定通过证书透明性对其进行处理。
这是CA签署的每个证书的公共日志；如果证书未显示在日志中，则该证书无效，并且该日志仅用于追加；您无法返回并清理历史记录。它仍然相对较新，但是Chrome已经在某些CA（包括所有EV CA）上要求它。想法是您可以按照日志查看是否应该显示您的域。工具仍在不断发展，以使其变得更简单，但这是一项非常有前途的技术。
您的最后一道防线是关键锁定
安全性更高的浏览器将允许域所有者将一个或多个公共密钥“固定”到其域。这是整个PKI系统的终结，并将信任直接注入浏览器。域名所有者可以通过HTTP标头告知浏览器仅允许使用具有特定公钥的证书，并且实际上可以将预定义的声明发送到浏览器本身。即使具有有效的CA签名，这也可以防止使用未经授权的证书。
DNSSEC和DANE最终将运用于此
。使用DNSSEC，您可以对DNS记录进行签名，这意味着您可以将公共密钥签名直接放在DNS中。这意味着您不需要第三方证书颁发机构来签名密钥。这是一个非常优雅的解决方案，但是DNSSEC仍然遥遥无期。您不能在许多操作系统上使用它，而且采用肯定是很高兴的。
评论
只是想知道，您说其中某些事情的采用速度很慢，您知道为什么会这样吗？可能是各方不相信解决方案/难以实施/尚未测试/未知的副作用/ X公司不想做公司Y想出的事情/其他/以上所有吗？
– TMH
16-2-24在11:09
@TomHart通常在采取安全措施时会很慢，因为这会迫使一方更加诚实，而不是他们想要的。 CA不喜欢证书透明性，因为它会使错误公开。某些ISP不太喜欢dnssec，因为它阻止了它们“自定义” DNS响应。有关协议本身的任何辩论都会给不感兴趣的各方以借口拖延脚。
– tylerl
16年2月24日在15:29
某些ISP可能不喜欢DNSSEC。但是对于DANE，SSL证书上的DNSSEC记录需要由客户端而不是ISP进行验证。 OTOH没有太多理由在客户端上验证AAAA和A记录。这种验证将破坏对NAT64等记录的合法处理。而且它也不会阻止劫持，因为ISP可以劫持IP层的连接。 ISP验证DNSSEC记录确实很有意义，在这种情况下，验证不会阻止ISP在验证后处理记录。
–卡巴斯德
16-2-24在23:01
顺便说一句，固定功能仅适用于数量有限的大个子-例如，Chrome固定了Google的密钥以提醒您流氓或伪造Google域名，但是如果您访问的是伪造的Microsoft域，则不会执行任何操作。 DNSSEC当然是当前“手指交叉和希望”系统的答案。
– gbjbaanb
16年2月25日在15:18
@gbjbaanb任何人都可以在其证书上启用固定，但是站点操作员必须将其打开，并可以选择通过浏览器分发其密钥签名。
– tylerl
16-2-25在15:33
#2 楼
在某人将为给定域名签名证书之前，您需要证明DNS所有权。仅用Google的域创建CSR是不够的。
如果证书颁发机构实际上为您提供了您没有证明所有权的域的有效证书，则该CA将立即被人们不信任，并且其根证书将从信任库中删除。
评论
除非从字面上讲太大，否则无法使CA失败。
–用户
16-2-24在14:20
您的最后声明过于强烈。要使CA不可信，首先必须将其发现。除非该网站像Google那样被大量使用和监控，否则不太可能被发现。
– Steve Sether
16-2-24在18:47
另外，“为不拥有的证书购买CA证书”正是TrustWave将下级CA证书出售给某些企业（而非CA）时发生的情况。 Trustwave应该当之无愧。但事实并非如此。规则只和选择遵循规则的人一样好，而浏览器在这方面做得不好。
– Steve Sether
16年2月24日在19:19
您的意思是为您不拥有的域购买证书？
– d1str0
16-2-24在19:21
我一直在从几个CA购买大型公司的证书...。我填写了表格，实际上唯一的“证明”是使用公司的电子邮件。您认为这是证据吗？
–blankip
16年2月26日在6:30
#3 楼
从理论上讲，对于当前的证书颁发机构，这是可能的。但是有许多安全措施。但这已经得到回答。但是letencrypt证书颁发机构无法做到这一点。因为它使用ACME协议证明域名所有权。
基本上，您运行letencrypt客户端，该客户端使用ACME协议与letencrypt证书颁发机构的服务器进行对话，以证明您拥有所声明的域名。一旦证明这一点，您将免费获得自动的新证书。
#4 楼
简短的回答；是的，它可以正常工作。鉴于证书的工作方式，如果您找到的证书足够薄，无法执行此操作，那么最终可以得到一个说您的Google.com的证书。
问题在于，应该由CA来验证您的身份。那是他们的全部目的。一个做得不好的人不会长久。
通常，这些不那么值得信任的CA在信任链中处于第4级和第5级，并且通常会迅速将其识别出来并从信任链中删除。
也就是说，仅查看证书时，CA是防御的最后一道防线，因此，如果您在没有适当研究的情况下找到可以证明您是google.com的证书，那么您将结束并附有证明您是google.com的证书。 （可能很短的时间）
重要的是要注意，这对于攻击是一个严重的威胁，对于大型服务器是一个问题。如果您可以通过恶意代码向客户端添加根证书，这也是一种可能的（但使用较少的）攻击方式。
作品中有一些“修复”，例如DNSSEC，但要广泛使用还需要一段时间。
今天最好的保护是确保您的客户端根证书是健全的，而不是添加到它们中。
评论
您的意思是“可以”-如果您记得有人在几年前设法购买了在live.fi域上注册到Microsoft的证书（这是一项技术含量较低的攻击，但仍然有效），那么它还是有效的，或者拥有DigiNotar为Google，Microsoft和Nokia颁发的有效证书
– gbjbaanb
16-2-25在15:15
评论
以前没有人尝试过这种方法，因为大多数人都知道这是行不通的:)。 ----提示：@ d1str0的回答。除非您想“列在清单上”，否则应考虑将“我可以做...”表格更改为“可以做...”表格。 ;-)
我敢肯定，这个问题只是脑力激荡，但他听起来似乎确实打算对Google的域进行MITM攻击。这是对当下力量的不断注视的嘲讽评论。
您甚至可以自己签署csr。问题是要由主要应用程序（通常是主要的浏览器供应商）信任的标准根CA列表中的CA进行签名。
@ dr01：google.com确实是一个主机名，并且具有A和AAAA记录。