我是如何迫使沃通给我签发Github的SSL证书的

|

当我意识到我获得了真实可用的GitHub主域名的SSL/TLS的时候，我觉得真是太荒诞了。Https的本意，是为预防被窃听和监控，然而，有了这些key，我却相对容易的成为了可以发动攻击的中间人。

我想要从头开始讲述这个故事，告诉你我是如何从证书商沃通那里获得这些证书的。

StartSSL

作为网站和schrauger.com这个域名的拥有者，我想要确保我的页面都通过https加密。虽然我的网站上并没有太多有意思的东西，但是我依然想要确保网站的安全，而且我的服务器也能够处理多出来的加载时间。因此，大约3年半以前，我选择了StartSSL。那时候，这是唯一一个可以提供免费SSL证书的受信证书提供商。

证书颁发机构 (CA)

其实，任何人都可以为任何域名生成证书。然而，你的浏览器却并不认这些证书。它只相信少数几个机构颁发的证书，这些机构就是证书颁发机构。因此只有这些机构才有权颁发证书，这些证书可以告诉全世界他们已经对你进行了审查，确认了你是该域名的拥有者和管理者。

随着我不断学习和实践，我开始添加了一些子域名。StartSSL虽然可以提供免费证书，但是每一个cert只能用于一个域名。因此，我所创建的每一个域名，都需要一个独立的cert。随着子域名数量的不断增多，管理这些cert变得非常困难，因为每一个cert都会在被创建一年之后过期，我需要不断的登录StartSSL来为每一个子域名生成新的cert。

程序员专属礼品：编程水杯
程序员专属礼品：编程水杯

沃通

2015年春天，沃通这家来自中国的证书颁发机构进入了我的视野。他们宣称自己可以提供免费的SSL证书，而且这些证书不仅有效期提高到了3年，而且一个cert最多可以支持100个域名。

由于沃通也是一家广泛受信的证书机构，我网站的终端用户无需做出任何改变，而且大大简化了我的证书管理流程，从此之后只需要管理一个证书就可以了。

现在我来简述一下我的工作，我是一个linux系统管理员，也是中佛罗里达大学的一名web开发者，具体就职于医学院。我需要管理med.ufc.edu这个网站，还有一些其他的子网站。最终我决定给网站创建一个沃通的证书，并且进行一次测试，测试通过的话，就用沃通的证书，还能省点钱。

域名验证

要 想为域名获取认证，受信的证书颁发机构需要你用一些方式来证明你的域名的拥有权。沃通要求的方式之一（也是其他许多证书颁发机构所要求的方式），就是他们 给你提供一个写满了独特数据的文本文件。你必须将这个文件放在网站上制定的地方，之后他们会浏览这个位置，然后下载这个文件。他们再将下载下来的文件与提 供给你的原文件进行对比，如果两个文件完全匹配，他们就可以认定你的对域名的拥有权了。在你的请求被批准之后，他们就会向你签发证书。

还有，在证明了你对主域名的控制权之后，他们还会默认你同时也拥有子域名的控制权。这是因为主域名的DNS操作者对于任何子域名也有完全的控制权。大多数证书颁发机构都是如此，这一点是无可厚非的。

发现漏洞！

当然，我也经过了这个验证步骤。和往常一样，我决定给子域名也加上了“www”。

然而，我并没有为 “www.med.ufc.edu”这个域名申请证书，而是不小心写成了“www.ufc.edu”。不久之后，我发现了这个失误，正当我想要移除第二条申请记录的时候，我发现沃通显示我所有申请都通过审核了。

我并不是学校主网站的管理员。很显然我并没有ufc.edu或是www.ufc.edu这两个域名的控制权。但是沃通却很痛快的通过了我的请求，为我提供了这个主站的证书。

漏洞认证 – GitHub

我决定要继续测试。这个问题会出现在其他网站上吗？还是只是一个偶然事件？GitHub是一个用来储存编程项目的网站。它是一个代码repo。但是它也给每一个用户提供了自己的子域名，用来为他们的代码创建主页面。在这个页面下，用户想做什么都可以。

也就是说，我对于我自己的子页面（schrauger.github.com以及schrauger.github.io）拥有完全的控制权。因此，我可以通过上传文档文件的方式，向沃通证明我拥有这个域名，那么我就可以为这两个子域名申请证书。

之后，我请求沃通也为github的主域名github.com和github.io生成证书。沃通的域名认证流程并没有看出哪里有不妥，他们认为我可以控制Github的主域名，尽管我提供的只是一个子域名。

我还额外添加了www.github.io这个域名，而并没有添加www.github.com这个域名，原因是我笨的把它忘记了。截止到目前为止，我的心跳在加速，肾上腺素不断的分泌，因为我这样做辜负了互联网对SSL的信任。请不要太责怪我。

沃通签署了我所申请的证书，我的天哪，我获得了github.com、github.io、www.github.io、schrauger.github.com和schrauger.github.io所有这几个域名的证书。在跳过了DNS入口之后，我在本地计算机上设立了一个响应了GitHub主域名的测试网站。在加载了这个网站之后，我看到它的位置为https://github.com，而浏览器显示，我当前的连接获得了沃通签署的可用证书的加密。

我打开了另一个GitHub账号，并且获得了第二个证书，但是这个证书只可用于github.io上，因为从user.github.com上向user.github.io的重定向，只对在系统中当前活跃的用户有效，之后GitHub才会决定是否在用户页面上使用第二个证书。

请求帮助

我有点不知所措了。我不知道该如何报告这个重大的问题。我无法把所有细节发到公共论坛中，否则会有人去利用这个漏洞。

我也无法直接与沃通取得联系，主要原因为语言不通，他们的网站中，也只有少数几个页面使用的是英文。另外，还有一个原因，就是我不想在报告这个问题之后，让他们不理睬我，然后偷偷的修补这个问题，当做什么都没有发生。

我觉得，如果我报告了这个问题，他们会修复之后继续保持沉默。毕竟，就在4年之前，另一家证书颁发机构DigiNotar就因为被爆出类似的事件而倒闭了。主流的浏览器（Chrome、Firefox、IE）都不再将DigiNotar作为受信机构，这家机构的所欲客户都选择了其他的竞争对手。

Stack Exchange

最后，我在Stack Exchange上创建了一个小号，在上面提了一个问题，询问接下来该怎么办。我并没有详细讲述细节，也没有提到沃通这家公司的名字。Stack Exchange社区提供了一些解决办法，大家通过投票的方式来确定最优的方案。

我联系了Dan Kaminsky，他是web加密和安全领域的一名大牛。我们先是通过邮件联系，后来又通了电话。我把GitHub证书的public key给了他，因为他可以代表我去联系沃通。

之后沃通修复了这个楼同，并且取消了我的GitHub证书。所有问题看上去都已经解决了。

证书现在还有效吗？

一年过去了，当我在清理服务器的时候，我又一次看到了这个证书。处于好奇，我又一次加在了这个网站，Firefox阻止了这个证书，说它已经被取消，无法使用。

然后我决定再用Chrome试试，我输入了github.com，然后确保我的hosts文件经过了重定向，之后点击回车。Chrome毫不用于的就加在了网站。

为何Chrome没有显示这个证书已经被取消？

我在收件箱中找到了沃通发来的邮件，他们说我的GitHub证书已经取消了。但是Chrome看上去并没有检查到这个信息，也就是说，这个证书对于任何Chrome用户来说依然有效！

之后我又意识到了一个严重的问题。我并没有收到www.ucf.edu证书被取消的邮件。我找到了那个证书，进行了一些测试，发现它依然有效。沃通并没有取消它！

也就是说，沃通并没有对其他的证书进行追加搜索，也没有取消它们。或者更糟糕的是，它们进行了搜索，但是并没有找到所有用这个漏洞所生成的证书。

GitHub Bug项目

发现这些问题之后，我通过bug项目联系到了GitHub。我向他们展示了这个证书，向他们解释了这个问题的严重性。在获得这些信息之后，GitHub立刻联系了谷歌Chrome的安全团队，该团队之后又联系了Firefox、IE和Safari的安全团队。

Mozilla与Chrome对话沃通

突然间，谷歌和Mozilla开始于沃通进行对话，而我也被卷入其中。沃通从来没有向任何人以及任何团队报告过有关这个GitHub证书的事情，对于我发现的这个漏洞，虽然他们已经进行了修补，但是没有进行报告。所有证书颁发机构都需要进行年度审核，他们有义务报告任何重大问题。

之后，我们发现，沃通还有其他一些隐藏未报的问题。其中之一，就是他们会使用非标准的port来进行域名验证，这个port可以被非服务器管理用户所控制。另一个问题，是一个API bug，这个bug允许

沃通回应

沃通加入了对话，他们说自己并没有意识到需要报告这个漏洞。发言人进行了掏钱，并且表示会在未来做的更好。他之后发布了33个利用我所发现的漏洞所生成的证书。

奇 怪的是，他表示，只有那些联系了沃通的证书创建人，他们所创建的证书才会被取消。打个比方，就好像是说警察会通缉罪犯，但是只有通过邮件给警察发送了自己 的照片、并且要求警察对自己进行通缉的罪犯，才能上通缉令。那些有意利用这个漏洞的人，是不会主动联系证书颁发机构要求撤销证书的。

沃通似乎没有意识到，所有那些通过这个漏洞所创建的证书，都必须无条件取消。而那些证书的创建者，可以通过已经修复了的系统进行重新申请，创建新的证书。

Chrome证书取消检查

沃通现在的证书吊销系统有着重大的问题。最主要的问题，就是有人可以使用这个漏洞发起中间人攻击，还能够阻止浏览器对证书是否已经被取消而发起的检查请求。如果证书取消检查响应失败，大都数浏览器都会默认接受这个证书。

这意味着，任何一个被取消的证书，依然可以被用来发起中间人攻击。在真正的攻击下，当前的证书取消检查系统无法有效的发挥作用。

CRLSet

谷歌决定放弃检查证书的取消状态。而是转而选择所有已取消证书的集合，然后将其整合进浏览器的更新。这样一来，著名的网站可以被加入进Certificate Revocation List Set (CRLSet)中，并且使用一个已经取消的证书来抵御中间人攻击。

不 幸的是，统计所有被取消的证书，这种做法既不实际，也不可能。说它不实际，是因为这样一来，每一次浏览器更新都会占据大量的大量的硬盘空间；说它不可能， 是因为并不是每一个证书颁发机构都会发布完整的被取消证书列表。谷歌必须要首先加在一个证书，然后查看证书的相信信息，才能获得查看取消状态的链接。

而且CRLSets也有自己的问题，因此虽然谷歌现在主要使用这种方式来检查证书的可用性，而Mozilla则在同时使用实时吊销检查和OneCRL（Mozilla自己版本的CRLSet）两种方式来验证证书。

证书透明度

谷歌和其他浏览器团队，最近一直在鼓励证书颁发机构发布证书透明度报告。这份报告中要包含证书颁发机构给每一个人所生成的证书。域名拥有者可以查看这个列表，检查自己的域名是否存在未经过认证的证书。

如今沃通也加入了这个行列，希望以后他们不会在出现类似的问题。

本文文字及图片出自 www.sdk.cn

你也许感兴趣的：

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注