我是如何迫使沃通给我签发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

余下全文(1/3)
分享这篇文章:

请关注我们:

发表回复

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