Netflix的短期证书电视电影小迷妹 TVco.cn

通过Prabath Siriwardena

今天，我们在WSO2办公室山景城举行了第六届硅谷IAM聚会。我们很高兴邀请 Netflix的Bryan Payne讨论主题“ 使用短期证书大规模使用PKI ”。 Bryan领导Netflix的平台安全团队，在加入Netflix之前，他曾担任Nebula安全研究总监。这篇文章是根据Bryan在见面会上的演讲和其他相关资源撰写的。

什么是短期证书？

短期证书与常规证书相同，不同之处在于有效期是较短的时间段，例如几天。这样的证书很快就会过期，最重要的是，在客户端过期之后，如果没有撤消机制，就无法关闭。建议使证书的生存期短至四天，以匹配OCSP响应被缓存的平均时间长度。

短期证书并不是什么新鲜事物-关于这一领域的研究甚至可以追溯到1998年。现在，关于短期证书的事情是，我们处在一个生态系统越来越庞大的世界中，我们拥有更多的东西自动化，突然之间，这很有意义。如果我们谈论这四年之前的事情，只会使人们越来越困惑。但是今天，每个听到它的人都渴望找到完成它的方法。

服务器公钥/私钥对

短期证书需要经常生成。这是否意味着每次生成新证书时，相应的服务器都必须生成一组新的公用/专用密钥对，生成CSR并由证书颁发机构进行签名？否。在证书签名过程中，服务器的公钥由证书颁发机构与到期日期和其他相关元数据一起签名。在短时间范围内重新生成证书时，只需更改到期日期，即可再次签名公钥和元数据。换句话说，可以继续针对相同的服务器密钥生成短期证书。

布莱恩对此有不同的想法。如果您担心丢失安全密钥，则最好不要保留相同的服务器密钥并仅以新的到期日期来更新短期证书。您需要重新生成服务器密钥，创建CSR并从证书颁发机构获取新证书。这就是Netflix遵循的方法。

为什么要使用短期证书？

证书吊销是一个较难解决的问题-尽管有多个可用选项：

CRL（证书吊销列表/ RFC 2459）
OCSP（在线证书状态协议/ RFC 2560）
OCSP装订（RFC 6066）
需要进行OCSP装订（草稿-Hallambaker-muststaple-00）

CRL是一种不常用的技术。发起TLS握手的客户端必须从相应的证书颁发机构（CA）获取较长的吊销证书列表，然后检查服务器证书是否在吊销证书列表中。例如，每次浏览网站时，浏览器都必须从相应的证书颁发机构下载此冗长的文档。浏览器可以这样做，而不是在本地缓存CRL。然后，您会遇到这样的问题，即基于过时的数据来做出安全决策。最终，人们意识到CRL无法使用，并开始构建新的东西，即OCSP。

面向短期证书的论文[1]指出了CRL的以下四个缺点。

1.关于真实CRL的研究表明，超过30％的吊销是在颁发证书后的前两天内发生的。对于CA，在其CRL发布频率和运营成本之间需要权衡。对于以较长间隔更新CRL的CA，存在无法及时阻止最近吊销的证书的风险。

2.由于CRL本身可以增长到兆字节大小，因此客户端经常采用缓存策略，否则，每次下载CRL时都会产生大量传输。这就引入了缓存一致性问题，其中客户端使用过期的CRL来确定吊销状态。

3.从历史上看，浏览器一直在容忍撤销失败（也称为“失败打开”），以免在无法访问其CA的情况下阻止访问流行的网站。实际上，它们默认会忽略CRL，或者在吊销失败时不显示明确的指示。不幸的是，这使网络攻击者仅通过破坏用户和CA之间的吊销请求就可以取消吊销。

4.还应注意，根据RFC5280，CRL的位置（由CRL分发点扩展指示）是证书描述的非关键组成部分。这意味着对于不具有此扩展名的证书，由验证者来确定CRL分发点本身。如果不能，则可以忽略CRL。

在OCSP世界中，情况比CRL更好。浏览器或TLS客户端可以检查特定证书的状态，而无需从证书颁发机构下载整个已撤销证书列表。换句话说，每次浏览器看到一个网站时，它都必须与相应的OCSP响应者进行对话，以验证服务器证书的状态。这在OCSP响应器上造成了一个麻烦。客户端仍然可以再次缓存OCSP决策，但是这又将导致同样的旧问题，即对过时的数据进行决策。 OCSP还会造成单点故障。通过DDOS攻击删除少量OCSP响应程序可能会破坏整个Internet。

谷歌宣布计划完全禁用Chrome（世界上最流行的浏览器之一）中的OCSP，而是重用其现有的软件更新机制来维护已撤销证书的列表。

如果OCSP响应者未能响应怎么办？应该是浏览器阻止用户访问相应的网站吗？或者只是警告用户，让他/她选择继续进行操作？在大多数情况下，发生的是软故障-后者。

迈向短期证书[1]一文指出了OCSP的以下四个缺点。

1. OCSP验证增加了客户端的延迟，因为验证证书是一项阻止操作，需要往返于OCSP响应程序以检索吊销状态（如果在缓存中未找到有效响应）。先前的研究表明，91.7％的OCSP查找的开销很大，需要100多个毫秒才能完成，从而延迟了HTTPS会话的建立。

2. OCSP可以提供对撤销查询的实时响应，但是尚不清楚响应是否实际上包含更新的撤销信息。一些OCSP响应者可能在其后端依赖缓存的CRL。据观察，DigiNotar的OCSP响应程序在受到攻击后能很好地返回良好的响应。

3.与CRL相似，也有多种方法可以破坏OCSP验证，包括流量过滤或由网络攻击者伪造伪造的响应。最重要的是，浏览器中的吊销检查无法打开。当他们无法通过OCSP验证证书时，大多数浏览器不会警告用户或更改其UI，有些甚至根本不检查吊销状态。我们注意到，由于某些情况下浏览器无法访问OCSP响应程序，因此打开失败是必要的。

4. OCSP还带来了隐私风险：OCSP响应者知道最终用户正在验证哪些证书，因此响应者原则上可以跟踪用户正在访问的站点。 OCSP装订旨在减轻这种隐私风险，但并不经常使用。

使用OCSP装订，浏览器或客户端不需要每次看到网站都去OCSP响应程序。托管网站的Web服务器将从相应的OCSP响应程序获取OCSP响应，并将响应装订或附加到证书本身。由于OCSP响应是由相应的证书颁发机构签名的，因此客户端可以通过验证签名来接受它。现在，Web服务器不得不与OCSP响应者进行对话，这使事情变得更好，而不是客户端。即使在这种情况下，如果OCSP响应未附加到证书，客户端也会启动软故障。

如果必须进行OCSP装订，服务器将向客户端保证OCSP响应将附加到它在TLS握手期间收到的服务器证书上。如果未将OCSP响应附加到证书，而不是进行软故障，则客户端必须立即拒绝连接并阻止用户访问相应的网站。

短期证书如何工作？ -Netflix模型

从最终用户体验的角度来看，短期证书的行为与今天的普通证书相同，相反，短期证书的到期时间非常短。浏览器或TLS客户端不必担心针对短期证书进行CRL或OCSP验证，而会停留在证书本身标记的到期时间上。

短期证书的挑战主要在于其部署和维护。自动化是救援的女神！这与人们今天迁移到的高速部署并没有太大不同。在这样的部署中，关键是要有一种方法来检测和修复停机时间几乎为零的任何故障，而这些故障当然是不可避免的！ Netflix使用Simian Army，这是一整套将运行系统引入混乱的工具。这样做是有意的，它可以帮助Netflix生活在一片混乱的世界中，并从这种情况中恢复过来，而对它的业务运营影响很小或没有影响。 Netflix还拥有Chaos Kong，它不会杀死单个实例，而是一个完整的AWS区域。这些练习几乎每个月都在Netflix进行，但没有人注意到。在经过短暂认证的部署中可以遵循相同的模型-它可以用于测试系统，对系统施加压力并确保其在各种故障情况下都可以工作。

Netflix建议使用分层方法来构建短期证书部署。您将拥有驻留在TPM（受信任的平台模块）或SGX（软件保护扩展）中的系统身份或具有长期安全性的凭证，并且具有很多安全性。然后，使用该凭据获取短期证书。然后将短期证书用于Web服务，该证书将由TLS客户端使用。 Web服务可以使用其长期凭证定期刷新短期凭证。仅拥有短暂的证书还不够-承载服务（或TLS终结器）的基础平台应支持对服务器证书的动态更新。许多TLS终结器都支持动态重新加载服务器证书，但在大多数情况下不支持零停机时间。

假定长期存在的凭据受到良好保护，并且很难被破坏。如果是这样，那为什么我们需要短暂的凭证呢？为什么不自己使用安全性很高的长期凭证呢？答案在于性能。使用TPM或SGX，可以长期保护凭据。非常频繁地加载这样的长期凭证是一项昂贵的操作。

最终，Netflix提出了如下部署方案。用户将自己的代码部署到Git存储库中，然后Spinnaker将负责连续部署并生成AMI。

Spinnaker是由Netflix开发的开源多云连续交付平台，用于以高速度和信心发布软件更改。

在启动期间，将为每个实例提供对长期凭证和短期凭证的访问。凭据引导程序由Metatron完成，它是Netflix的一个工具，负责凭据管理。目前， Metatron处于Beta版，并且计划在将来对其进行开源。一旦将初始凭据供应到服务器实例中，它将与Netflix Lemur API进行对话，以获取短期证书。每获得一个新证书，服务器环境就会随之更新。

Netflix Lemur管理TLS证书创建。尽管Lemur本身不能颁发证书，但它充当CA与环境之间的代理，为开发人员提供了一个中央门户，以使用“默认”默认值颁发TLS证书。

微服务和短期证书

Netflix在地球上拥有最大的微服务部署。他们使用短期证书来保护微服务之间的交互-更准确地说，Netflix将TLS相互身份验证与短期证书一起使用以保护微服务之间的通信。每个微服务都可以充当客户端和服务。

Netflix的短期证书部署仅集中在数据中心内，而不是面向公众的前端。它只是服务器到服务器的通信-或微服务之间的通信受到短期证书的保护。

其他实施/研究

论文《 短期证书 [1]》使用Java建立其证书颁发机构，并作为Web应用程序在Apache Tomcat上提供。 Web服务器向证书颁发机构服务器发出HTTP GET请求，以指定要检索的证书的通用名称以及唯一的证书标识符。该标识符允许Web服务器通过其一个证书颁发机构存储的相同通用名称下的多个证书。

这些标识符由服务器的所有者在向短期证书的证书颁发机构注册时选择。它们允许服务器以通用名称拥有多个证书，例如，如果他们希望使用不同的私钥/公钥对，或者想要的证书是通配符证书，而又是特定于域的证书。在预签名或按需模式下，CA的servlet在文件系统上查找适当的证书。在按需模式下，匹配模板证书的有效期将更新并使用证书颁发机构的私钥进行签名。私钥以加密方式存储在证书颁发机构的服务器上，并在启动时解密并带入内存。

签名和常规证书处理使用IAIK加密库完成。使用不同的密钥对预签名的证书进行脱机签名，然后将其手动传输到服务器。每个预签名和按需证书的有效期为四天，以匹配缓存OCSP响应的时间长度。

他们还用Java实现了针对Apache Web服务器的服务器端程序。该程序被设置为每天执行的Cron作业。程序运行时，它将检查以确保证书即将到期。如果为true，则向证书颁发机构发出GET请求以获取预签名或按需证书。一旦获得证书，它将以标准PEM格式存储到文件系统中。

设置Apache SSL配置文件，以使证书的文件位置是符号链接。当新证书存储在文件系统上时，程序必须重新指向新证书的符号链接，并可以选择清除过期的旧证书。此后，服务器证书下载程序会向Apache发出正常重启命令。这样可确保Web服务器重新启动并加载新证书，而不会中断任何现有连接。

从原则上讲，《 迈向短期证书》 [1]提出的这种模式与Netflix所遵循的模式并没有很大区别。

保护浏览器免受网络中介的影响 [5]提出了短期证书作为提高TLS性能的一种方法。根据他们的建议，证书颁发机构可以配置短期证书的有效期，以匹配他们在实际环境中测得的OCSP响应的平均有效期，即4天。这样的证书很快就会过期，最重要的是，在客户端过期后，它们会失效关闭（将它们视为不安全的），而无需撤销机制。进一步根据该提议，当网站购买为期一年的证书时，证书颁发机构响应是可用于下载按需短期证书的URL。该URL在一年中保持活动状态，但是颁发的证书仅有效几天。

摘要

短期证书并不新鲜。这个概念存在了几十年，并且在进入主流方面进展缓慢。在CRL，OCSP，OCSP装订和OCSP必须装订中发现的大多数缺陷都是在短期证书中解决的。

短期证书可以在面向公众的前端使用，也可以仅在数据中心内使用。 Netflix当前的重点是后者。根据Bryan的说法，构建证书颁发机构生态系统以支持面向公众的网站的短期证书将需要一些时间。

参考文献

迈向短期证书：http：//www.w2spconf.com/2012/papers/w2sp12-final9.pdf
使用短期证书的大规模PKI：http：//www.meetup.com/Silicon-Valley-IAM-User-Group/events/230537915/
改善吊销：OCSP必需装订和短期证书：https：//blog.mozilla.org/security/2015/11/23/improving-revocation-ocsp-must-staple-and-short-lived-certificates/
证书吊销的当前状态（CRL，OCSP和OCSP装订）：https://www.maikel.pro/blog/current-state-certificate-revocation-crls-ocsp/
保护浏览器免受网络中介的侵害：http：//repository.cmu.edu/cgi/viewcontent.cgi？article = 1430＆context = dissertations
Web的PKI中证书吊销的端到端度量：http：//www.cs.umd.edu/~dml/papers/revocations_imc15.pdf