HTTPS and Certificate Transparency

HTTPS , CA , CT的一些内容

证书的作用

HTTPS

描述下HTTPS的过程

下图描述了HTTPS的简化的流程,具体每一步的传输的内容:http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

证书验证机制

  1. 当用户拿到了站点的证书后,要去验证这个证书的有效性。所以要去验证该证书的颁发者。

  2. 找到证书颁发者后(中间CA),要去验证这个颁发者的有效性。

  3. 找到中间CA的 根证书 颁发机构证书。

  4. 最终确定证书可用性,继续通信

客户端是是如何验证某个证书的有效性

证书颁发者一般提供两种方式来验证证书的有效性: CRLOCSP

CRL(Certificate Revocation List)即 证书撤销名单。证书颁发者会提供一份已经失效证书的名单,供浏览器验证证书使用。浏览器会缓存 CRL 。一段时间更新一次。

OCSP(Online Certificate StatusProtocol) 即 在线证书状态协议

除了 CRL,证书颁发者也会提供实时的查询接口,查询某个特定证书目前是否有效。实时查询的问题在于浏览器需要等待这个查询结束才能继续TLS握手,延迟会更大。

下面的内容,是对某blog的文章翻译和自己的理解,讲了CT,以及CT该如何用。文章分为3部分,每部分的原文链接已给出。

Certificate Transparency — The bright side and The dark side

原文连接:https://blog.appsecco.com/certificate-transparency-the-bright-side-and-the-dark-side-8aa47d9a6616

part 1

什么是Certificate Transparency

证书透明项目(Certificate Transparency project,简称CT)旨在记录、审计和监视证书颁发机构(CA)颁发的证书。这个项目的主要目的是防止ca在域所有者不知情的情况下为域颁发公钥证书。

下面是一些术语

Certificate Authority

证书颁发机构(CA)是颁发数字证书的实体。CA是受信任的第三方,由数字证书的所有者和依赖证书的一方信任。因此,CAs在Internet如何运行以及如何透明、可信地进行事务方面发挥着关键作用。

Digital Certificates

数字证书是可验证的小型数据文件,其中包含身份凭证,以帮助网站、个人和设备代表其真实的在线身份。在本文的上下文中,我们关心SSL/TLS证书,这是一种将web服务器的所有权细节绑定到加密密钥的数字证书。

Why did Google come up with Certificate Transparency?

起因:google发现了自己家的域名被CA私自颁发了证书

Certificate Transparency — Where is it now?

CT现在是一个互联网工程工作组(IETF)的开放标准,用于监控和审计此类数字证书。CT通过一个认证日志、监控和审计系统,允许网站用户和域名所有者识别错误或恶意颁发的证书。这有助识别未经授权的核证机关。

part 2

原文连接:https://blog.appsecco.com/certificate-transparency-part-2-the-bright-side-c0b99ebf31a8

The problem Certificate Transparency is trying to solve

公钥基础设施(Public Key Infrastructure, PKI)是一个框架,用于在可能从未谋面的各方之间实现安全通信。PKI模式依赖于:信任证书颁发机构(CAs)的第三方。CAs负责签发数码证书。SSL/TLS PKI依赖于:分层CA信任模型,叫做:certification hierarchy

CA颁发证书模型

  • 根CA位于证书层次结构的顶部,根CA是“自签名的”。大多数应用程序/设备都带有一组预先加载到其根存储中的根证书,根存储实际上是已批准的ca的数据库
  • 中间CA是信任链中的第一个环节。中间证书通常由根证书签名。如果中间CA受到攻击,来自其他中间CA的证书仍然有效
  • 用户是希望通过internet安全提供服务并需要SSL/TLS证书的任何人

CT要做的就是防止流氓证书

Can Certificate Transparency deal with the rogue certificates?

在CT下,CA必须将其发出的每个SSL/TLS证书发布到公共日志中。目前已知的CT日志的详细信息可以在CT project页面上找到。任何人都可以通过这些日志查找为任何给定域颁发的SSL/TLS证书。

域所有者可以简单地监视针对其管理的域颁发的证书的公共CT日志,并识别流氓证书。

通过提供一种查找所有SSL/TLS证书的方法,CT帮助我们在野外识别流氓证书,并找出哪个CA颁发了流氓证书。这使得诸如谷歌、Mozilla等浏览器制造商能够对ca错误采取行动。

How do I lookup certificates issued for my domain?

查找为您的域颁发的证书的最简单方法是使用收集CT日志的搜索引擎,并让任何人搜索它们。下面列出了一些流行的方法

  1. https://crt.sh/
  2. https://censys.io/
  3. https://developers.facebook.com/tools/ct/
  4. https://google.com/transparencyreport/https/ct/

The state of Certificate Transparency adoption

到目前为止,CT受到了积极的欢迎,其使用率正在上升。

  • 这些 Let’s encrypt, Digicert, Symantec, Comodo CA都在积极的这么做
  • 像Mozilla Firefox和谷歌Chrome这样的主流浏览器都实现了CT
  • Facebook不仅倡导CT,还发布了一个证书透明监控工具。使用此工具,您可以搜索为域颁发的证书,并在为域颁发新证书时通过电子邮件得到通知。

从2018年4月起,Chrome将强制所有新证书使用CT。Chrome对CT的支持要求CAs记录Chrome中出现的绿色地址栏的所有扩展验证(EV) SSL证书。

Chrome还致力于实现一个新的HTTP头,expect-ct,它将允许服务器操作人员在CT被授权之前测试他们的配置和证书。

Conclusion

CT是提高SSL / TLS PKI生态系统安全性的重要一步。 CT正在整个行业中得到采用和实施,这是一个积极的信号。 如果越来越多的CA落后于CT,整个SSL / TLS生态系统就变得越透明和安全。

Part 3

原文连接:https://blog.appsecco.com/certificate-transparency-part-3-the-dark-side-9d401809b025

The side effect of Certificate Transparency

CT日志按设计包含由参与CA为任何给定域颁发的所有证书。这些日志是公开的,任何人都可以查看这些日志。

SSL/TLS证书通常包含域名、子域名和电子邮件地址。这使得它们成为攻击者的信息宝库。

通过查看CT日志,攻击者可以收集关于组织基础设施的大量信息,如内部域、电子邮件地址。

Let’s look at how attackers look through Certificate Transparency logs

下面是一些搜索引擎,可以用来搜索CT日志

  1. https://crt.sh/
  2. https://censys.io/
  3. https://developers.facebook.com/tools/ct/
  4. https://www.google.com/transparencyreport/https/ct/

Attacking Content Management Systems using Certificate Transparency

在设置Wordpress、Joomla等流行的内容管理系统(CMSs)时,有一个时间窗口,安装程序没有任何形式的身份验证。现在,许多web托管提供商默认支持HTTPS,因此域名最终将出现在CT日志中,这取决于CA,这可能发生在接近实时的情况下,或者有几个小时的延迟。如果攻击者可以通过CT日志搜索并在没有身份验证的情况下找到这样的web应用程序,那么他/她就可以接管服务器。

对上面这段话进行下解释:在安装CMS时候,如果在安装过程中被攻击者发现域名,那么攻击者可以接手这个安装进程,好像如此。

How can you secure your domains now?

  • 您可以避免使用SSL/TLS支持,这样您的内部主机就不会出现在CT日志中。这种方法绝对不推荐。如果您正在处理敏感信息,那么不使用SSL/TLS不是一个好主意
  • 通过使用通配符证书,您可以拥有对所有子域有效的单个证书,从而不会在CT日志中显示子域名。使用一个通配符证书来保护多个域可能被证明是单点故障,因此不建议使用。
  • 接受这样一个事实:所有SSL/TLS受保护的域/子域将在公共CT日志文件中列出。更好地保护服务器和应用程序端点。任何不打算公开的内容都必须在身份验证之后。
  • 您可以在组织中部署自己的公钥基础设施(PKI)。这将避免您的内部主机出现在由公共CA维护的CT日志中
  • CloudFlare有一个有趣的项目CFSSL,用于构建内部CA基础设施。他们还有一个项目certmgr,可以使用CFSSL自动化证书管理
  • 一些ca为客户提供了一个选择,让他们选择不使用CT日志。选择退出CT日志可能听起来是一个安全的主意,但是您将错过CT提供的所有安全好处
  • 考虑从CT日志中编辑子域信息。如果您的CA支持名称编校,那么您可以选择将子域信息隐藏在CT日志中。尽管名字修订比退出CT要好,但它仍然会使您难以跟踪伪造的证书。修改后的域名将不会被Chrome识别为符合CT政策

结语

虽然CT是一个非常棒的想法,但它也存在一些重大的隐私和安全风险,但是考虑到CT在解决恶意证书这一由来已久的问题方面所提供的优势,我们认为采用CT作为安全机制是一种公平的权衡。