当您访问一个安全网站时，它会为您提供一个声明其身份的TLS证书。每个证书都有一个过期日期，当过期时，它就不再有效了。这个想法几乎和web本身一样古老：限制证书的生命周期是为了降低TLS服务器的密钥泄露。证书不是唯一过期的加密构件。当您访问受Cloudflare保护的站点时，我们还会告诉您其证书是否已被吊销（请参阅我们在OCSP stapling上的博文），例如，由于密钥被泄露，并且这个值（所谓的OCSP主键）有一个过期日期，也是这样的，以确定证书是否有效且未被吊销，则系统需要知道当前时间。事实上，时间对于TLS和其他各种协议的安全性至关重要。为了帮助保持时钟同步，我们宣布了一个免费的、高可用性和低延迟的认证时间服务，称为Roughtime，可在roughtime.cloudflare.com在端口2002。时间是诡计，你可能会惊讶地发现，在实践中，客户的时钟严重倾斜。最近对Chrome用户的一项研究表明，报告的TLS证书错误中有很大一部分是由客户端时钟偏差引起的。在收集错误报告期间，6.7%的客户报告时间延迟超过24小时。（0.05%提前超过24小时）这种偏差是导致至少33.5%的Windows用户、8.71%的Mac操作系统、8.46%的Android系统和1.72%的Chrome操作系统的抽样报告的原因之一。这些错误通常以警告的形式呈现给用户，用户可以通过单击来到达目的地。然而，显示过多的警告会让用户习惯于点击它们；这是有风险的，因为这些警告是为了让用户远离恶意的网站。时钟倾斜还阻碍了我们改进证书本身的安全性。我们希望颁发具有较短生存期的证书，因为证书的有效时间越短，密钥暴露的风险就越低。（这就是为什么让我们加密发行的证书，默认情况下只有90天有效。）但是倾斜时钟的长尾限制了证书的有效生存期；缩短太长的生存期只会导致更多警告。终结点在因特网上，通常使用网络时间协议（NTP）之类的协议来同步时钟。NTP的目标是精确同步，甚至考虑到网络延迟。但是，由于高负载服务器上增加的开销会显著降低精度，因此通常在没有安全特性的情况下部署它。因此，介于客户端和服务器之间的中间人攻击者很容易影响客户端的时钟。通过及时移动客户机，攻击者可以迫使客户机接受过期（也可能是受损的）证书；通过及时向前移动，攻击者可以迫使客户机接受尚未过期的证书有效。幸运的是，对于安全性和精确性都至关重要的环境，可行的解决方案即将出现。但对于许多应用程序来说，精确的网络时间并不是必需的；它只需精确到10秒的实时时间就足够了。这一观察结果是Google的Roughtime协议的主要动机，这是一个简单的协议，通过该协议，客户可以与一个或多个经过验证的服务器同步时钟。Roughtime缺乏NTP的精确性，但其目标是对加密应用足够精确，而且由于响应是经过身份验证的，中间人攻击就没有了可能的。那个协议设计简单灵活。一个客户机可以只从一个它信任的服务器上获得麻烦，或者它可能会联系许多服务器以使其计算更加可靠。但它最显著的特点是它增加了时间服务器的责任。如果一个服务器由于提供错误的时间而出现错误行为，那么协议允许客户端为这种错误行为生成可公开验证的加密证据。以这种方式使服务器可审计，使它们有责任提供准确的时间。我们正在为两个人部署一个粗糙的服务原因。首先，我们用于此服务的时钟与我们用来确定客户证书是否有效且未被吊销的时钟相同；因此，公开此服务将使我们对代表我们向客户提供的TLS工件的有效性负责顾客。第二一个伟大的时代已经来临。但它只有在几个独立组织参与的情况下才有用；粗糙时间服务器越多，生态系统就越健壮。我们的希望是，把我们的重量放在后面，将有助于粗糙的生态系统成长。那个Roughtime协议在其最基本的层次上，Roughtime是一个单轮协议，其中客户机请求当前时间，服务器发送签名响应。响应由时间戳（Unix纪元以来的微秒数）和半径（以微秒为单位）组成，用于指示服务器对报告时间的确定性。例如，半径为1000000μs意味着服务器可以合理地确定真实时间在报告的1秒之内时间。那个服务器证明其响应的新鲜性如下。请求由一个短的随机字符串组成，通常称为nonce（发音为/nän（t）s/，有时也叫/ˈen wən（t）s/）。服务器将nonce合并到其签名响应中，以便需要验证签名。如果nonce足够长（比如16个字节），那么可能的nonce数量非常大，以至于服务器不太可能遇到（或永远不会遇到）具有相同nonce的请求。因此，一个有效的签名可以作为密码证明响应是新鲜。那个客户机使用服务器的根公钥来验证签名。（密钥是在带外获得的；您可以在这里获得我们的密钥。）当服务器启动时，它生成一个联机公钥/密钥对；根密钥用于创建联机公钥的委派，而联机密钥用于对响应进行签名。委托的功能与web上的传统X.509证书相同：如下图所示，客户端首先使用根公钥验证委派，然后使用联机公钥验证响应。这就允许了委托者和服务器的操作分离，并限制了根机密的公开键。简化Roughtime（无委托）Roughtime with delegationRoughtime提供了两个旨在使其可伸缩的特性。首先，当请求量很大时，服务器可以通过从现在开始构造Merkle树对多个客户端的请求进行批签名。服务器在树的根上签名，并在响应中发送所需的信息，以向客户机证明其请求在树中。（数据结构为二叉树，因此信息量与批处理中请求数的基数2对数成正比；见下图）第二，协议通过UDP执行。为了防止Roughtime服务器成为DDoS攻击的放大器，请求被填充到1KB；如果UDP包太短，则在没有进一步处理的情况下丢弃它。请看这篇博文以获得更深入的信息讨论。艰苦的时间使用roughtime的批处理，协议足够灵活，可以支持各种用例。在验证TLS证书时，web浏览器可以使用Roughtime服务器主动同步其时钟。它还可以追溯使用，以避免向用户显示太多警告：当证书验证错误发生时，特别是当浏览器认为证书已过期或尚未生效时，可以使用Roughtime来确定时钟偏差是否是根本原因。它可以告诉用户他们的时钟是无效的，而不是告诉用户证书无效不正确。使用如果一个服务器是可信的，那么只有一个服务器就足够了，但是一个有安全意识的用户可以向多个服务器发出请求；delta可以通过消除异常值并平均响应来计算，或者用更复杂的方法。这使得计算对于一个或多个服务器是可靠的行为不端。制造服务器可管理性粗糙时间的真正力量在于它是可审计的。考虑以下操作模式。客户机有一个将按特定顺序查询的服务器列表。客户机生成一个随机字符串（用Roughtime的说法称为blind）散列它，并使用输出作为它对服务器的请求的nonce。对于后续请求，它按如下方式计算nonce：生成一个blind，计算此字符串的哈希值和来自上一个服务器的响应（包括时间戳和签名），并将此哈希用作下一个的nonce请求。链接以这种方式创建时间戳链的多个粗糙时间服务器将每个响应绑定到之前的反应。因此，盲板和签名序列构成了一个可公开验证的、加密的证据，证明时间戳是按顺序请求的（如果你愿意的话，"时钟链"）