证书透明（CT）是一个雄心勃勃的项目，它通过为保护HTTPS的系统引入责任感来帮助提高在线安全性。Cloudflare宣布支持该项目，推出两项新的公益服务：Nimbus：一个自由开放的证书透明日志Merkle Town：探索证书透明生态系统的仪表盘在这篇博文中，我们将解释什么是证书透明，以及它将如何成为确保在线用户安全的关键工具。对于网站运营商和证书颁发机构来说，尽快了解CT是非常重要的，因为在Chrome中，对于2018年4月之后颁发的所有证书，都必须参加CT。我们还将解释Nimbus是如何工作的，以及CT如何使用一种称为Merkle树的结构来扩展到支持Internet上所有可信证书的程度。关于梅克尔镇的更多信息，请阅读我的同事帕特里克·多纳休的后续文章。信任和责任我们在网上做的每件事都需要一个基本的信任水平。当您使用浏览器访问银行网站或您最喜爱的社交媒体网站时，您希望连接另一端的服务器由地址栏中指定的组织操作。这种期望是基于信任的，这种信任是由一个叫做web公钥基础设施（webpki）的系统支持的。从较高的层次来看，PKI类似于公证员系统，通过向服务器提供一个被称为数字证书的签名对象，授予服务器服务网站的权限。此证书包含网站名称、请求证书的组织的名称、证书的有效期以及公钥。对于每个公钥，都有一个关联的私钥。为了使用给定的证书为HTTPS站点提供服务，服务器需要证明相关私钥的所有权。站点从称为证书颁发机构（CA）的受信任的第三方获取数字证书。CA在向操作员颁发证书之前验证其对域的所有权。如果证书的颁发CA受浏览器信任，则该证书可用于通过HTTPS向站点访问者提供内容。所有这些都是在浏览器的引擎盖下发生的，只有当你的地址栏上有一个绿色的小锁，或者出错时会出现一条讨厌的错误消息。Web的PKI是一个复杂而复杂的系统。有几十个组织运行受流行浏览器信任的证书颁发机构。不同的浏览器管理自己的"根程序"，在根程序中选择哪些证书颁发机构是可信的。成为受信任的CA通常需要通过审核（webtrustforcas）并承诺遵守一组称为基线要求的规则。这些规则由一个名为CA/Browser论坛的标准机构设置，该论坛由浏览器和CA组成。每个根程序都有自己的应用程序过程和特定于程序的指南。这个系统运行得很好，直到它不工作为止。作为一个信任系统，PKI有很多失败的方法。webpki固有的风险之一是任何证书颁发机构都可以为任何网站颁发任何证书。这意味着香港邮政局可以签发一份有效的证书。gmail.com网站或者脸谱网，每个浏览器都会信任它。这迫使用户对证书颁发机构非常信任，并希望他们不会因为向错误的人颁发证书而行为不端。更糟糕的是，如果CA受到黑客攻击，攻击者可以在CA不知情的情况下颁发任何证书，从而使用户面临更大的风险。如果有人设法获得了一个不是他们的网站的证书，他们可以冒充该网站的访问者，窃取他们的信息。为了了解流行浏览器信任多少CA，下面是Firefox中160个受信任CA的列表。微软和苹果维护自己的列表，这些列表相当长（Cloudflare在我们的cfssl_trust存储库中跟踪这些列表）。当你浏览因特网时，通过暗中信任所有这些组织，用户承担了证书颁发机构错误行为的风险。PKI缺少的是问责制。如果一个错误颁发的证书被用于针对某个人，那么没有反馈机制让任何人知道CA的行为不正常。这不是理论上的情况。2011年，达奇·迪吉诺卡被黑了。黑客利用他们对CA的访问为*颁发证书。谷歌. 然后他们试图用这个证书冒充Gmail和伊朗的目标用户，试图泄露他们的个人信息。谷歌使用一种称为公钥锁定的技术检测到了这一攻击。密钥锁定是一种有风险的技术，只有在非常精通技术的组织中才可行。键锁定所提供的价值通常被它所带来的操作风险所掩盖。它通常被认为是"脚炮"机制的典型例子。浏览器不推荐使用键固定。如果密钥锁定不是解决方案，那么如何检测CA渎职？这就是证书透明性的来源。CT的目标是公开所有证书，以便可以检测到错误颁发的证书并采取适当的措施。这有助于实现问责制，以平衡我们对脆弱的网络PKI的信任。发光创意共享零（CC0）-angele-j如果所有证书都是公开的，那么错误颁发的证书也是公开的。证书透明性使用一种叫做区块链的技术为web PKI带来了责任感，一种只附加公共账本，一种有序列表。它将可信证书放入一个列表中，并使该列表对任何人都可用。这听起来很容易，但鉴于互联网的分散性，要使其成为可靠的问责基础，还有许多挑战。CT生态系统是PKI的扩展，引入了额外的参与者和角色。除了浏览器和CA之外，还引入了新的参与方，以在系统的整体运行状况中发挥作用。这些当事人是：日志运算符审核员监视器在较高的层次上，日志操作员是管理只能添加到的证书列表的人。如果有人向日志提交浏览器信任证书，则必须在预先设置的最大合并延迟（MMD）宽限期内将其合并到列表中，该宽限期通常为24小时。日志向提交者返回一个收据，称为签名证书时间戳（SCT）。SCT是在宽限期内将证书包含在日志中的承诺。您可以通过CT API（在rfc6962中定义）与CT日志交互。审核员是保证日志操作员诚实的第三方。他们在互联网上从不同的有利位置查询日志，并互相闲聊证书的顺序。他们就像PKI的狗仔队。它们还通过测量SCT的时间戳和日志中显示的相应证书之间所用的时间来跟踪SCT是否得到了认可。除了作为仪表板之外，Merkle Town后端也是一个审计程序；它甚至在其他日志中检测到问题。监视器是一种帮助提醒网站错误发布的服务。它会为新证书爬网日志，并在找到域的新证书时向网站所有者发出警报。流行的监视器包括SSLMate的CertSpotter和Facebook的证书透明监视。Cloudflare计划在今年年底为客户提供一个集成到Cloudflare仪表板中的免费日志监控服务。让浏览器知道证书已被记录推动web采用CT的一种方法是让浏览器开始要求记录网站证书。在建立连接时，通过直接查询日志来验证证书是否已被记录是一个潜在的隐私问题（向第三方公开浏览器历史记录），并且会增加延迟。相反，确保证书被记录的更好的方法是要求服务器提供sct，即上一节中描述的包含收据。有多种方法可以将SCT呈现给客户机。最流行的方法是在证书颁发时将sct嵌入到证书中。这涉及到CA向各种CT日志提交一个预证书（证书的前身），以便在完成证书之前获得sct。对于没有嵌入sct的证书，服务器有其他机制将sct传输到客户端。SCT可以作为TLS扩展包含在连接中，也可以包含在装订的OCSP响应中。这些机制更难可靠地实现，但它们允许在CT中包含任何证书。带有嵌入式SCTs的证书浏览器CT要求并非所有日志都是平等创建的。恶意CA可以与一组日志串通来创建一个证书和一组SCT，而不会将证书合并到日志中。然后，该证书可用于攻击用户。为了保护生态系统不受共谋风险的影响，支持CT的浏览器选择只从经过审核的日志列表中接受sct。还有多样性要求：日志应该由不同基础设施上的不同实体管理，以避免共谋和共享停机。如果连接从经过审核的日志中向客户提供足够的SCT，以适应证书的风险状况，则称这些连接是"CT合格"的。为了使一个连接在Chrome中是CT合格的，它必须遵循Chrome的CT策略。对于大多数证书，这意味着至少需要为一个Google和一个Chrome信任的非Google日志提供SCT。长寿命证书多于两个SCT。为了获得Chrome的信任，CT日志必须提交包含并通过90天的监控期，在此期间必须通过一些严格的要求，包括：没有超过MMD（最大合并延迟）超过24小时的停机有99%的正常运行时间，没有比MMD更长的停机时间（根据Google的测量）合并一份由日志wi签发的SCT证书