作者丨IP君
文章地址：http://www.ipfs.cn/news/info-100164.html
这篇文章描述了如何使用Cloudflare的IPFS网关建立端到端安全的网站，并且，该网站还保持Cloudflare edge网络的性能和可靠性。
使用通用SSL进行CNAME设置
第一步是为您的网站选择一个域名。
网站应该有自己的域名，而不是通过root哈希直接从网关提供。它们被浏览器视为不同的来源，是为了防止缓存中毒。
它为网站提供了自己的localStorage实例和他们自己的cookie jar，这些cookie是通过恶意第三方文档的检查和操作进行沙盒处理的。它还允许无冲突地运行Service Workers，并请求用户的特殊权限，例如访问网络摄像头或GPS。
但最重要的是，网站拥有域名更易于识别和记忆。
现在您已经选择了一个域，而不是按原样使用它，您需要添加“ipfs-sec”作为最左边的子域。
例如，您可以使用“ipfs-sec.example.com”而不是“example.com”。ipfs-sec子域是特殊的，因为它向用户和他们的浏览器发出信号，即你的网站能够以端到端完整性提供服务。
除此之外，ip -sec域需要正确设置DNSSEC以防止欺骗。
与标准的HTTPS (DNS欺骗通常不会导致中间人×××)不同，这正是DNS欺骗对IPFS所做的，因为网站的根哈希存储在DNS中。
通过使用IPFS -sec域，您现在可以根据开发人员文档
（https://developers.cloudflare.com/distributed-web/ipfs-gateway/connecting-website/）
了解如何从IPFS提供通用静态网站。
注意，你需要使用CNAME设置并保留对DNS的控制，而不是使用注册Cloudflare的简单方法。这有助于在管理DNSSEC签名密钥的一方和为最终用户提供内容的一方之间保持适当的隔离。请记住，CNAME设置往往存在问题，并且会遇到难以调试的情况。
验证网关服务的内容
HTTPS帮助确保用户和Cloudflare的edge网络之间没有人篡改连接，但它并不能确保Cloudflare真正服务于用户要求的内容。为了解决这个问题，我们构建了两个连接的项目:一个经过修改的网关服务和一个浏览器扩展。
首先，我们创建了go-ipfs存储库，并让它能够提供加密证明，证明它是诚实地提供内容的，每当它看到带有HTTP头X-Ipfs-Secure-Gateway: 1的请求时，它都会这样做。
最简单的情况是，当用户通过其哈希从网关请求一个文件时——所有网关必须做的是提供内容以及重新计算给定散列所需的任何元数据。
这里面更复杂的情况是用户从目录中请求文件。
IPFS中的目录只是包含从文件名到文件哈希的映射的文件，非常大的目录可以透明地分割成几个较小的文件，结构为一个名为hash Array mapping Trie (HAMT)的搜索树。
为了让客户相信网关服务于正确文件的内容，网关首先服务于与目录对应的文件，或者如果目录是HAMT，则搜索路径中的每个节点。客户端可以对这个文件(或搜索树节点)进行哈希，检查它是否等于他们请求的目录的哈希值，并从目录的内容中查找他们想要的文件的哈希值。
然后网关提供请求文件的内容，客户端现在可以验证这些内容，因为它知道预期的哈希值。
最后，客户端希望通过域名访问内容。
这很复杂，因为用于验证DNS的协议DNSSEC只有很少的客户端实现。
DNSSEC也没有被广泛部署，尽管一些注册商甚至让它比设置HTTPS更容易。最后，我们编写了自己的简单的dnssec验证解析器，它能够输出一个加密的令人信服的证据，证明它正确地进行了一些查找。
它的工作方式与HTTPS中的证书验证相同:我们从底部开始，一些权威机构的签名声称是example.com，而不是他们希望我们服务的DNS记录。然后，我们从声称为.com的权威机构中查找一个委托(DS记录)，该授权机构说“example.com是具有这些公钥的权威机构”，该公钥又由.com权威的私钥签名。
最后，我们从根权威机构ICANN(我们已经拥有其公钥)中查找授权，以证明com权威机构使用的公钥。所有这些查找捆绑在一起形成一个认证链，从ICANN开始，以我们想要服务的精确记录结束。这些构成了证明。
DNSSEC中的信任链
我们构建的第二个项目是一个浏览器扩展，它从IPFS网关和IPFS -sec域请求这些证明，并能够验证它们。该扩展使用webRequest API位于浏览器的网络堆栈和呈现引擎之间，防止任何意外数据显示给用户或意外代码执行。浏览器扩展的代码可以在Github上使用，并且可以通过Firefox的扩展库安装。
另一方面，如果用户没有安装扩展，网关就不会看到X-Ipfs-Secure-Gateway标题，它会像普通网站一样为页面服务，而不需要任何证明。这为使用IPFS提供了一个很好的升级路径，可以通过使用第三方网关的扩展，也可以通过运行适当的IPFS节点的浏览器扩展。
示例应用
到目前为止，我最喜欢的IPFS网站是协议实验室IPFS团队建立的英文维基百科。它速度快，玩起来很有趣，最重要的是它有实用价值。不过，有一个突出的问题是，它没有搜索功能，因此您要么必须知道想要查看的页面的URL，要么通过谷歌找到它。
我想提供一个使用IPFS可以实现的安全、高性能应用程序的例子，利用的是StackExchange网站的Kiwix档案，在此基础上建立一个分布式搜索引擎。您可以在这里玩成品:ipfs-sec.stackexchange. cloudflars -ipfs.com。
建造的方式其实是很简单的：我们建立反向索引和发布与其他每一个课件,连同一个JavaScript客户机可以读取索引和快速识别文档相关的用户的查询。构建索引需要对数据进行两次传递:
1.第一个通道决定我们希望允许用户搜索哪些词。词不应该太受欢迎(比如英语中的前100个单词)，因为这样包含该词的所有文档的列表就会很大，而且无论如何也不会改善搜索结果。
它们也不应该太罕见(比如具有次秒精度的时间戳)，因为这样索引就会充满无意义的标记，每个标记只出现在一个文档中。
2. 既然第一次传递给了我们想要跟踪的标记，那么第二次传递数据实际上构建了反向索引。也就是说，它从每个词构建一个映射到包含该词的文档列表(称为发帖列表)。
当客户端只想找到包含一些词的文档时，他们会下载每个词的列表并交叉它们。这听起来没有那么有效——事实上，即使在最坏的情况下，帖子列表也很小(小于30kb)。
而且，浏览器可以“输送”对帖子列表的请求(意思是，同时发送它们)，这使得对多个请求的响应速度与对一个请求的响应速度差不多。
我们还在每个帖子列表中存储一些简单的统计数据，以帮助排名结果。
本质上，包含查询词的文档比不包含查询词的文档排名更高。在查询中的词中，出现在较少文档中的词对排序的影响要比出现在许多文档中的词更大。
这就是为什么当我搜索AES SIV时，第一个返回的结果是:
· "Why is SIV a thing if MAC-and-encrypt is not the most secure way to go?"
而下面是第四个结果，尽管它比第一个结果得分更高，总点击次数更多:
· "Why is AES-SIV not used, but AESKW, AKW1?"
(AES是一种非常流行且经常被讨论的加密算法，而SIV是一种不太为人所知的使用AES的方式。)
但这正是它的特别之处:因为搜索索引存储在IPFS中，用户可以说服自己，在不下载整个语料库的情况下，没有任何结果被修改、重新排列或省略。
让这个语句成立有一个小技巧:由搜索客户端发出的所有请求都必须成功，如果不行，它将输出一个错误，没有搜索结果。
为什么要这样，因为它必须标记查询并决定要下载哪些帖子列表，而不是用户查询中的所有单词都可能被索引。
一个简单的解决方案是尝试无条件地下载每个单词的帖子列表，并将非200 HTTP状态码解释为“这个帖子列表一定不存在”。
在这种情况下，网络对手可能会阻止搜索客户端访问导致不良结果的帖子列表，从而导致客户端通过遗漏或重新安排来输出具有误导性的搜索结果。
我们所做的是将每个索引标记的字典存储在索引根文件中。客户端可以下载字典一次，缓存它，然后在每次搜索时使用它。
通过这种方式，搜索客户端可以查询字典来找出哪些请求应该成功，并且只发送这些请求。
当我们意识到将IPFS与Cloudflare结合起来的新途径和应用类型时，我们非常兴奋。当然，我们建立的IPFS网关和浏览器扩展需要时间才能成熟，形成一个安全可靠的平台。