为什么无法加密种子下载流量?

21
这个问题的目的是希望更好地理解P2P、网络和安全/加密的本质。我是一个前端网站开发人员,如果我们深入到HTTP请求以下,我的网络栈知识并不强大。
话虽如此,我正在尝试了解ISPs如何“嗅探”种子流量并识别内容。我觉得这个问题会暴露我的无知,但是难道不可能有一种类似于HTTPS的P2P协议,使其不那么容易被读取吗?
我明白一个给定的数据包必须在途中标识其目的地,并传输到网络上,但是难道不能将种子数据包配置为仅显示它们的目的地,以便在到达目的地之前,没有人能够确定它的用途吗?为什么ISP可以查看P2P流量并了解其中的所有信息,而SSH却非常安全,这看起来是一个无法挽回的情况呢?

1
SO是关于计算机编程的问题,而不是关于计算机或网络如何工作的一般性问题。 - Barmar
2
是的,我询问的是,在编程中设计加密P2P协议的技术障碍是什么。 - temporary_user_name
请尝试在此处发布:http://serverfault.com/tour - Panther
这纯粹是一个协议设计问题,我认为这不适合在这里讨论。 - President James K. Polk
4个回答

21
每个答案似乎都对问题有不同的解释,或者更确切地说,对加密的不同假设目的。由于您将其与https进行比较,因此似乎可以合理地假设您正在寻找身份验证和保密性。我将列举一些尝试,按“安全”级别降序排列。这是一个以bittorrent为中心的答案,因为您在问题标记了bittorrent。

SSL

从最强大的系统开始,可以在SSL上运行bittorrent(许多客户端不支持它,但在完全受控的部署中可以完成)。这使您获得:

  1. 参与的每个对等方的身份验证
  2. 通过使用群集根证书签署其证书来选择哪些对等方被允许进入群集的能力。
  3. 所有对等方连接+跟踪器连接的SSL加密

跟踪器可以验证连接到它的每个对等方,但即使泄漏或猜测了对等方列表(或一个对等方),仍然存在点对点身份验证,阻止任何未经授权的访问。

Bittorrent over SSL已实现部署

加密种子文件

在BitTorrent(uTorrent客户端)中,我们为种子文件的磁盘层面添加了对称加密支持:

enter image description here

所有的bittorrent引擎都将在加密块上运行。数据完整性检查(块的sha-1哈希)将在加密块上完成,.torrent文件将具有加密数据的哈希值。像这样的加密种子与不支持该功能的客户端向后兼容,但他们将无法访问数据(只能帮助Swarm并进行种子传播)。
要以未加密的形式下载种子,您需要在磁力链接中添加“&key=”参数,然后uTorrent会在磁盘边界解密和加密数据(使数据保留在磁盘上)。任何没有密钥的人添加磁力链接,都只会得到加密数据。
还涉及一些其他细节,例如加密.torrent文件中的一些元数据,例如文件列表等。
这不允许您选择哪些对等方可以加入。您可以授权给想要的对等方访问权限,但由于它是对称密钥,因此任何有访问权限的人都可以邀请任何其他人或发布密钥。它不会为您提供比您找到磁力链接时更强的身份验证。
它为您在可信对等方之间提供机密性,并且可以让不受信任的对等方帮助进行种子传播。 bittorrent协议加密 BitTorrent协议加密更准确地说应该是混淆。它的主要目的不是验证或控制对群集的访问(它从信息哈希派生加密密钥,因此如果您可以保密,您将获得该属性)。主要目的是避免简单的被动监听和流量整形。我的理解是,它现在更难有效地避免被识别为BitTorrent流量。它还提供了对复杂主动攻击的弱保护。例如,如果启用DHT或未加密跟踪器连接,则很容易了解信息哈希值,这是关键。
在私有种子的情况下(其中禁用了DHT和对等交换),假设跟踪器运行HTTPS,则没有明显的漏洞。然而,我的经验是,https跟踪器通常具有自签名证书,并且客户端不会验证跟踪器。这意味着毒化跟踪器的DNS条目可能足以进入群集。

3
µTorrent 的加密规格是什么? - the8472
是的,这需要完成,因为ISP会直接给您发送一封信件,说您下载了“泰坦尼克号”。这是什么鬼?显然,像这样危险的事情在1.0版本中需要实现加密。 - buycanna.io

2

Torrent流量可以加密,还有VPN / SOCKS代理可以用于重定向流量,即通过加密隧道经由另一个国家连接到对等体。尽管如此,即使您使用这样的服务,仍有许多通过侧信道(例如DNS查找,不安全跟踪器,受损节点)泄漏流量的方法,而大多数人并不了解如何遵循所有适当的安全/匿名预防措施。此外,仅与也强制加密的客户端通信将限制您可以连接的同行数量。


SOCKS代理不加密?除非你通过SSH代理。 - jiggunjer

1
您所考虑的问题是点对点加密和公共上下文中无限数量的同行之间的区别。任何公共同行的解密只有在某个地方有一个启动器时才能生效 - 一种解密密钥,所有公共同行都可以使用。在保护免受ISP干扰的情况下,他们也将访问该密钥,除非有一些排除协议只在其他人之间共享密钥。这样做并不实际。在点对点连接中,TLS密钥协商最终创建一个由两个对等方共享的会话加密密钥。该密钥是伪随机且特定于会话的。以这种方式在互联网上共享的数据对于没有参与密钥协商的客户端是不可用的。

1

比特流量(具体来说是用于传输大部分数据的点对点协议)可以加密。但这种加密方式不提供强有力的保密/身份验证保证,类似于HTTP2的机会主义加密

客户端-跟踪器通信可以使用HTTPS进行加密。

这两个组件为您提供了一个工作中的、尽管受限制的比特流堆栈,其内容已加密且对被动观察者不可见。

基于侧信道数据(数据包大小/流量模式、所联系的域等),ISP仍然可能能够将其识别为“可能是比特流”,但他们无法确切知道正在传输什么。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接