因沃通事件,更换了 SSL 证书

沃通 (WoSign) 事件也发酵了有段时间,继 Safari 和 Mozilla 之后,Chrome 也声明取消对 WoSign & StartCom 证书的信任。

Sep 30, 2016: Apple: Blocking Trust for WoSign CA Free SSL Certificate G2
Oct 24, 2016: Mozilla: Distrusting New WoSign and StartCom Certificates
Oct 31, 2016: Google: Distrusting WoSign and StartCom Certificates


更换证书

说来 SSL 证书我也换了两次,最早用的是 Let’s Encrypt,后来图方便就换了 StartSSL。
虽然 Chrome 不信任的是 10 月 21 号 之后颁发的证书,不过既然 StartCom 和 WoSign 这么恶心,再者我的 StartSSL 的证书到 17 年初也过期了,就换成 AlphaSSL 的证书。
AlphaSSL 是 GlobalSign 的子公司,感觉名字也挺好看的。

对于 StartSSL 的替代品,腾讯云阿里云 都可以申请免费的 Symantec DV 证书,Comodo & SSL For Free 也是不错的选择。

顺便一提,Apple 2017 年将要求全面支持 HTTPS (ATS)。
虽然 Web 没有什么关系,不过对于部分网页中的非 HTTPS 链接,我建了个支持 HTTPS 的短网址服务:Vurls
因为除了 goo.gl 外,国内的短网址基本没有 HTTPS 支持。

沃通 (WoSign) 事件回顾

原文:The story of how WoSign gave me an SSL certificate for GitHub.com

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

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

StartSSL

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

证书颁发机构 (CA)

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

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

沃通 (WoSign)

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

由于沃通也是一家广泛受信的证书机构,用户无需做出任何改变,如果转向使用沃通,从此之后只需要管理一个证书就可以了。

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

域名验证

要想确定域名的所有权,证书颁发机构需要用户用一些方式来证明你的域名的拥有权。沃通要求的方式之一,就是他们给你提供一个写满了独特数据的文本文件。用户必须将这个文件放在网站上制定的地方,之后他们会尝试下载这个文件,再将下载下来的文件与提供给你的原文件进行对比,如果两个文件完全匹配,他们就可以认定你的对域名的所有权,并向你签发证书。

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

发现漏洞!

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

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

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

漏洞确认 – GitHub

我决定要继续测试。这个问题会出现在其他网站上吗?还是只是一个偶然事件?GitHub 是一个用来储存编程项目的网站。但是它也给每一个用户提供了自己的子域名,用来为他们的代码创建主页面。也就是说,我对于我自己的子页面 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 所有这几个域名的证书。在通过设置 hosts 后(hosts 文件,用于绕过 DNS 指定域名指向的 ip,译者注)我在本地计算机上建立了一个使用 GitHub 主域名的测试网站。在加载了这个网站之后,我看到它的 URL 为 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,他是网络加密和安全领域的一名大牛。我们先是通过邮件联系,后来又通了电话。我把 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)两种方式来验证证书。

证书透明度

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

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