今天，我们很高兴地宣布我们的解决方案来解决影响加速移动页面（AMP）的最大问题：在提供AMP缓存内容时无法使用真正的源URL。为了允许AMP缓存在其原始URL下提供内容，我们实现了HTTP签名交换，它将真实性和完整性扩展到代表发布者缓存和服务的内容。这种逻辑存在于Cloudflare worker上，这意味着将HTTP签名的交换添加到您的内容中只需要一个简单的Workers应用程序。Cloudflare上的发布者现在可以利用AMP性能，并让AMP缓存使用其原始URL服务内容。我们很高兴能将员工作为这项工作的核心组成部分解决方案.HTTP签名交换是新兴的网络打包标准的一个重要组成部分，这是一套用于通过优化的交付系统（如googleamp）打包网站进行分发的协议。这一宣布正好赶上了2018年Chrome开发峰会，我们的同事Rustam Lalkaka谈到了我们推进网络包装的努力标准。什么是网络包装吗？为什么它很重要？您可能已经看到了每天都需要Web打包。在你的智能手机上，也许你已经搜索过圣诞果岭，直接从谷歌访问了1-800-Flowers，并且惊讶地发现该网址下提供的内容https://google.com/amp/1800flowers.com/blog/flower-facts/types-of-christmas-greens/amp。这是AMP的一个实例，Google为缓存的内容提供服务，以便更快地加载所需的web页面。出于明显的安全原因，在没有HTTP签名的exchangeGoogle的情况下，通过AMP访问1-800个Flowers无法在发布者url下提供缓存内容。要安全地显示URL中的内容，需要其域的TLS证书。谷歌不能代表供应商提供1-800-Flowers的证书，因为它没有相应的私钥。此外，Google不能，也不应该能够使用对应于1-800-Flowers的私钥对内容进行签名证书无法使用AMP的原始内容URL带来了一些严重的问题。首先google.com/ampURL前缀可以去除URL的含义。令出版商沮丧的是，他们的内容不再是通过URL（更不用说证书）直接归属于他们的。出版商再也无法证明其所提供内容的完整性和真实性代表。第二，对于web浏览器来说，缺少发布者的URL可能会使缓存网页的完整性和真实性受到质疑。也就是说，没有明确的方法来证明这个响应是1-800-Flowers发布的实际页面的缓存版本。此外，Cookie由第三方提供商管理，如Google，而不是发布者。输入网络包装，一个规范的集合"包装"网站内容与信息，如证书及其有效性。HTTP签名交换规范允许第三方缓存缓存和服务HTTPS请求，并提供完整性证明和真实性.HTTP签名交易：通过加密技术扩大信任在AMP之前的日子里，人们希望在一个确定的网址上找到一个网页的内容。拥有最终URL域的发布者将向访问者提供一个与该域相对应并包含公钥的证书。发布者将使用相应的私钥签署加密握手，该握手用于派生共享对称密钥，用于加密内容并保护其完整性。然后，访问者将接收由共享密钥加密和签名的内容。然后，访问者的浏览器使用共享密钥来验证响应的签名，进而验证内容的真实性和完整性收到。有然而，像AMP这样的服务，在线内容可能对应于多个URL。这就带来了一个问题：虽然只有一个域实际对应于网页的发布者，但多个域可能负责为一个网页提供服务。如果出版商允许AMP服务缓存和服务他们的网页，他们必须能够签署他们的内容，即使AMP缓存为他们服务。只有这样AMP缓存的内容才能证明合法性.HTTP签名交换直接解决了将发布者签名扩展到AMP等服务的问题。这个IETF草案指定了发布者如何签署HTTP请求/响应对（交换）。通过签名的交换，发布者甚至可以在客户机发出请求之前确保对特定请求的响应的完整性和真实性。给定一个签名的交换，发布者授权中间层（比如Google的AMP缓存）转发交换；中间层用签名的HTTP请求/响应对中的相应响应响应响应给定的请求。然后，浏览器可以验证交换签名以断言中间响应的完整性和真实性。这就像是给一个由老师签名的小测验的答案。有一张签名的答题纸和从老师那里得到答案一样好时间。那个技术细节HTTP签名交换由以下内容生成第一步，第一步，发布者使用MICE（Merkle Integrity Content Encoding）为交换中包含的响应提供完整性的简明证明。首先，将响应分成若干个记录大小的块，这些块的长度为记录大小。以消息ABCD为例，它分为记录大小的块a、B、C和D。构造完整性证明的第一步是获取最后一个块D，然后计算以下：证明（D） =SHA-256（D | | 0x0）这就产生了证据（D）。然后，将块的所有后续证明值计算为以下：证据（C） =SHA-256（C | |证明（D）| | 0x1）证明（B）=SHA-256（B | |证明（C）| | 0x1）证明（A）=SHA-256（A | |证明（B）| | 0x1）这些证明的生成将生成以下树：proof（A）/\/ \/ \A证明（B）/\/ \/ \B证明（C）/\/ \/ \C证明（D）||D因此，proof（A）是一个256位的摘要，接收到真实响应的人应该能够自己重新计算。如果接收者可以重新计算一个与proof（a）相同的树头值，那么他们就可以验证他们收到的响应的完整性。事实上，这个摘要的作用与Merkle树的树头类似，Merkle树的树头被重新计算并与所呈现的树头进行比较，以验证特定节点的成员身份。小白鼠生成的摘要存储在回答。下一个，发布者将请求/响应对的头和有效负载序列化为CBOR（简明二进制对象表示）。CBOR的键值存储在结构上类似于JSON，但创建的消息更小大小。最后，发布者使用与发布者证书相关联的私钥对CBOR编码的请求/响应对进行签名。这将成为HTTP签名中sig参数的值交换最终的HTTP签名交换看起来像以下：sig=*MEUCIQDXlI2gN3RNBlgFiuRNFpZXcDIaUpX6HIEwcZEc0cZYLAIga9DsVOMM+g5YpwEBdGW3sS+bvnmAJJiSMwhuBdqp5UY=*；integrity="摘要/mi-sha256"；有效性url="https://example.com/resource.validity.1511128380";证书url="https://example.com/oldcerts";cert-sha256=*W7uB969dFW3Mb5ZefPS9Tq5ZbH5iSmOILpjv2qEArmI=*；日期=1511128380；过期时间=1511733180像AMP这样的服务可以通过使用新的HTTP响应格式来发送签名的交换，该格式除了原始响应外还包括上面的签名。当此签名包含在AMP缓存的响应中时，浏览器可以验证此响应的合法性。首先，浏览器确认cert url中提供的证书与请求的域相对应，并且仍然有效。接下来，它使用证书的公钥以及请求/响应对的头和正文值来检查签名sig的真实性。然后浏览器使用给定的完整性算法digest/mi-sha256（aka MICE）和摘要头的内容检查响应的完整性。现在浏览器可以确认由第三方提供的响应具有内容原始发布者的完整性和真实性。在所有这些幕后工作之后，浏览器现在可以显示内容的原始URL，而不是前缀为google.com/amp. 我愿意解决AMP最重要的痛点之一！与工作人员生成HTTP签名的交换从上面的概述中，显然涉及到生成HTTP签名交换的过程。如果有一种方法可以自动生成HTTP签名的交换，并让像AMP这样的服务自动接收它们呢？有了Cloudflare Workers……我们找到了一种方法，你可以拥有自己的HTTP源代码交换蛋糕，也可以吃掉它！我们已经为我们的一个客户1-800-Flowers实现了HTTP签名交换。Cloudflare Worker中部署的代码负责获取和生成创建此HTTP签名交换所需的信息。这个工作线程使用googleamp的自动缓存。当Google的搜索爬虫对一个站点进行爬网时，如果它最初以Vary:AMP Cache Transform作为响应，它将从同一个URL请求一个签名的交换。我们的HTTP签名交换工作线程检查是否可以生成签名的交换以及当前文档是否有效AMP。如果是，则返回Vary头。在Google的爬虫在响应中看到这个Vary头之后，它将发送另一个包含以下两个的请求标题：AMP缓存转换：谷歌接受：申请/签名交换；v=b2当我们的实现看到这些头值时，它将尝试生成并返回一个内容类型为：application/signed exchange；v=b2的HTTP响应。现在Google已经用我们的工作人员生成的签名交换缓存了这个页面，请求的页面将显示发布者的URL，而不是Google的AMP Cache URL。成功！如果你想在1-800-Flowers上看到HTTP签名的交换，f