0%

HTTPS and Certificate Transparency

Posted on Edited on In Disqus:

HTTPS ， CA , CT的一些内容

1. 证书的作用

1.1. HTTPS

描述下HTTPS的过程

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

1.2. 证书验证机制

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

  2. 找到证书颁发者后（中间CA），要去验证这个颁发者的有效性。

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

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

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

证书颁发者一般提供两种方式来验证证书的有效性： CRL 和 OCSP。

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

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

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

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

2. Certificate Transparency — The bright side and The dark side

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

2.1. 什么是Certificate Transparency

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

下面是一些术语

Certificate Authority

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

Digital Certificates

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

2.2. Why did Google come up with Certificate Transparency?

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

2.3. Certificate Transparency — Where is it now?

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

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

2.4. 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被授权之前测试他们的配置和证书。

2.5. Conclusion

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

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

2.6. The side effect of Certificate Transparency

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

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

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

2.7. 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/

2.8. Attacking Content Management Systems using Certificate Transparency

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

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

2.9. 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政策

3. 结语

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