IPFS的端到端完整性

整理:IPFS原力区
作者:Brendan McMillion.

 

本文描述了如何使用Cloudflare的IPFS网关建立端到端安全的网站,同时保持Cloudflare边缘网络提供的性能和可靠性优势。如果您想首先阅读IPFS背后的概念介绍,您可以在我们的公告中找到。或者,您可以直接跳到开发人员文档以了解如何设置自己的网站。

通过“端到端安全性”,我的意思是网站所有者和用户都不必信任Cloudflare来提供正确的文档,就像现在这样。这类似于使用HTTPS的方式意味着您不必信任您的ISP不修改或检查流量。

 

IPFS的端到端完整性
IPFS的端到端完整性

 

使用通用SSL进行CNAME设置

第一步是为您的网站选择一个域名。网站应该有自己的域名,而不是通过root哈希直接从网关提供,因此它们被浏览器视为不同的来源。这主要是为了防止缓存中毒,但也有一些功能优势。它为网站提供了自己的localStorage实例和他们自己的cookie jar,这些cookie是通过恶意第三方文档的检查和操作进行沙盒处理的。它还允许他们无冲突地运行Service Workers,并请求用户的特殊权限,例如访问网络摄像头或GPS。但最重要的是,拥有域名可以使网站更易于识别和记忆。

现在您已经选择了一个域,而不是按原样使用它,您需要添加“ipfs-sec”作为最左侧的子域。例如,您使用“ipfs-sec.example.com”而不仅仅是“example.com”。ipfs-sec子域是特殊的,因为它向用户和他们的浏览器发出信号,表明您的网站能够提供端到端的完整性。

除此之外,ipfs-sec域还需要正确设置DNSSEC以防止欺骗。与标准HTTPS不同,DNS欺骗通常不会导致中间人攻击,这正是DNS欺骗对IPFS的影响,因为网站的根哈希存储在DNS中。许多注册商使得启用DNSSEC像按下按钮一样简单,尽管有些人根本不支持它。

使用ipfs-sec域,您现在可以按照开发人员文档了解如何从IPFS提供通用静态网站。请注意,您需要使用CNAME设置并保留对DNS的控制权,而不是仅仅注册Cloudflare的简单方法。这有助于在管理DNSSEC签名密钥的一方和向最终用户提供内容的一方之间保持适当的分离。请记住,CNAME设置往往会出现问题并进入难以调试的情况,这就是我们为技术复杂的客户保留它们的原因。

您现在应该可以通过我们的网关支持的HTTP和HTTPS访问您的网站。

验证网关服务的内容

HTTPS有助于确保用户和Cloudflare边缘网络之间没有人篡改连接,但它无法确保Cloudflare实际上为用户要求的内容提供服务。为了解决这个问题,我们构建了两个连接项目:修改后的网关服务和浏览器扩展。

首先,我们分叉了go-ipfs存储库,并使其能够提供加密证据,证明它正在诚实地提供内容,只要它看到带有HTTP标头的请求,它就会做X-Ipfs-Secure-Gateway: 1。最简单的情况是当用户通过其散列从网关请求单个文件时 – 所有网关必须做的是提供内容以及重新计算给定散列所需的任何元数据。

更复杂的情况是用户从目录请求文件。幸运的是,IPFS中的目录只是包含从文件名到文件哈希的映射的文件,非常大的目录可以透明地分成几个较小的文件,构造成一个名为Hash Array Mapped Trie(HAMT)的搜索树。。为了说服客户端网关正在提供正确文件的内容,网关首先提供与目录对应的文件,或者如果目录是HAMT则提供搜索路径中的每个节点。客户端可以散列此文件(或搜索树节点),检查它是否等于他们要求的目录的散列,并在目录的内容中查找他们想要的文件的散列。然后,网关提供所请求文件的内容,客户端现在可以验证该文件,因为它知道预期的哈希值。

最后,到目前为止最复杂的情况是客户想要通过域名访问内容。这很复杂,因为用于验证DNS的协议(称为DNSSEC)很少有客户端实现。尽管一些注册商比设置HTTPS更容易,但DNSSEC也没有得到广泛部署。最后,我们最终编写了我们自己的简单DNSSEC验证解析器,它能够输出一个加密的令人信服的证据,证明它正确地进行了一些查找。

它的工作方式与HTTPS中的证书验证方式相同:我们从底部开始,一些权威机构的签名声称是他们希望我们提供的DNS记录的example.com。然后,我们从声称是.com的权限中查找委托(DS记录),其中说“example.com是具有这些公钥的权限”,而该权限又由.com权限的私钥签名。最后,我们从根权限ICANN(我们已经拥有其公钥)中查找授权,证明.com权限使用的公钥。捆绑在一起的所有这些查找形成了一个经过身份验证的链,从ICANN开始,到我们想要服务的确切记录结束。这些构成了证明。

 

IPFS的端到端完整性

DNSSEC中的信任链。

 

 

我们构建的第二个项目是一个浏览器扩展,它从IPFS网关和ipfs-sec域请求这些证明,并且能够验证它们。该扩展使用webRequest API位于浏览器的网络堆栈及其呈现引擎之间,防止向用户显示任何意外数据或执行意外代码。浏览器扩展的代码可以在Github上获得,可以通过Firefox的附加存储安装。我们很高兴能够添加对Chrome的支持,但是在他们的错误跟踪器中的这张票被解决之前,这无法继续前进。

另一方面,如果用户没有安装扩展程序,网关将不会看到X-Ipfs-Secure-Gateway标题,并且将像普通网站一样提供页面,而无需任何证据。这为使用IPFS提供了一个优雅的升级路径,可以通过我们使用第三方网关的扩展,也可以是在浏览器中运行正确IPFS节点的其他浏览器扩展。

示例应用

到目前为止,我最喜欢的IPFS网站一直是协议实验室IPFS团队推出的英语维基百科的镜像。玩起来快速,有趣,最重要的是具有实用性。然而,一个突出的问题是,镜像没有搜索功能,因此您必须知道要查看的页面的URL或尝试通过Google找到它。在土耳其语镜在应用内搜索,但它需要在同一主机上动态API的调用,而且不会通过CloudFlare的网关工作,因为我们只提供静态内容。

我想提供IPFS可能实现的各种安全,高性能应用程序的示例,这使得构建搜索引擎看起来像是一个主要的候选者。我们决定采用所有不同StackExchange网站的Kiwix档案,并在此基础上构建分布式搜索引擎,而不是窃取协议实验室的“IPFS维基百科”的想法。您可以在此处使用完成的产品:ipfs-sec.stackexchange.cloudflare-ipfs.com

它的构建方式实际上非常简单,至少就搜索引擎而言:我们构建一个倒排索引并将其与每个StackExchange的其余部分一起发布,以及一个可以读取索引并快速识别相关文档的JavaScript客户端到用户的查询。构建索引需要对数据进行两次传递:

  1. 第一遍确定我们希望允许用户搜索的单词/标记。令牌不应该太受欢迎(比如英语中的前100个单词),因为那时包含该令牌的所有文档的列表将是巨大的,并且它无论如何都不会改进搜索结果。它们也不应该太罕见(就像具有亚秒精度的时间戳),因为那时索引将充满无意义的令牌,每个令牌只出现在一个文档中。你可以得到最频繁k令牌的一个很好的估计,仅仅使用恒定的空间,从非常简单的节省空间的算法本文
  2. 既然第一遍给了我们想要跟踪的标记,第二遍传递数据实际上构建了倒排索引。也就是说,它构建了从每个令牌到包含该令牌的文档列表的映射,称为发布列表。当客户想要仅查找包含一组单词/标记的文档时,他们会下载每个单独标记的列表并将它们相交。它听起来效率低于实际效果 – 实际上,即使在最坏的情况下,帖子列表也很小(<30kb)。并且浏览器可以“管道化”发布列表的请求(意思是,立即将它们全部发送出去),这使得对几个请求的响应速度与获取响应一样快。

我们还在每个帖子列表中存储一些简单的统计信息,以帮助对结果进行排名。从本质上讲,包含查询令牌的文档的排名通常高于不包含查询令牌的文档。在查询中的标记中,出现在较少文档中的标记对排名的影响大于许多文档中出现的标记。这就是为什么当我搜索“AES SIV”时,第一个返回的结果是:

  • “如果MAC-and-encrypt不是最安全的方式,为什么SIV会成为事?”

而以下是第四个结果,即使它的得分和总命中数高于第一个结果:

  • “为什么不使用AES-SIV,而是AESKW,AKW1?”

(AES是一种非常流行且经常讨论的加密算法,而SIV是一种鲜为人知的使用AES的方法。)

但这才是真正特别之处:因为搜索索引存储在IPFS中,用户可以说服自己没有修改,重新安排或省略任何结果而无需下载整个语料库。有一个小技巧可以使这个陈述成立:搜索客户端发出的所有请求都必须成功,如果不成功,则输出错误而没有搜索结果。

要了解为什么这是必要的,请在首次获取用户查询时考虑搜索客户端。它必须对查询进行标记化并确定要下载哪些发布列表,而不是可以将用户查询中的所有单词编入索引。一个天真的解决方案是尝试无条件地下载每个单词的发布列表,并将非200 HTTP状态代码解释为“此发布列表必须不存在”。在这种情况下,网络攻击者可以阻止搜索客户端访问导致不良结果的发布列表,从而导致客户端通过省略或重新安排输出误导性搜索结果。

我们所做的是将每个索引标记的字典存储在索引根目录中的文件中。客户端可以下载字典一次,对其进行缓存,然后将其用于每次搜索。这样,搜索客户端可以查阅字典以找出哪些请求应该成功并且仅发送那些请求。

从这里

当我们意识到将IPFS与Cloudflare结合起来的新途径和应用类型时,我们非常兴奋。当然,我们建立的IPFS网关和浏览器扩展需要时间才能成熟,形成一个安全可靠的平台。但是,通过第三方托管服务提供商和CDN安全地提供网页的能力非常强大,而密码学家和互联网安全专业人员长期以来一直在努力。和我们建造它一样有趣,我们更加兴奋地看到你用它构建的东西。

 


IPFS原力区

IPFS原力区是全球第一大IPFS价值生态社区,总部位于上海,聚集了众多技术大咖和IPFS爱好者;IPFS原力区秉持:价值,共建,共赢,荣耀的文化理念;提供全面、精细、优质的IPFS咨询和技术支持,将生态中的爱好者转化为IPFS支持者和参与者。

未来,IPFS原力区做好价值文化基因传播、紧盯人工智能,量子计算,大数据等前沿科技,把IPFS技术随时架设在最新的技术基础之上,推动IPFS生态的健康发展。

IPFS的端到端完整性

更多分享,敬请关注

 

原创文章,作者:IPFSforce,如若转载,请注明出处:http://ipfser.org/2018/09/19/ipfsp2psafe/

发表评论

登录后才能评论

联系我们

在线咨询:点击这里给我发消息

邮件:[email protected]

工作时间:周一至周五,9:30-18:30,节假日休息

QR code