今天殆知阁又被人爆出干了一件阴间事,未经帐户所有者同意,在其所控制的实例上创建与原帐户相同的镜像帐户,并且没有做出任何声明。甚至还像正常帐户一样与其它用户互动。

这样的行为与360快视频未经授权镜像B站一样,是极其严重的侵权行为。

先说结论:daizhige的镜像账号甚至不是爬虫,是当年mao.daizhige.org和其他站互通留下的的联邦宇宙数据缓存。在服务器后台处理生成。

是明显的故意行为。

此人不得好死。

下面是分析:

  1. 嘟文右上角的时间,点开是pawoo的链接,如果是爬虫通过正常流程发嘟,是不可能这样的。

  2. 爬虫不可能精确复制关注人数和关注者人数

根据一嘟友的分析,殆知阁这些李鬼帐户并不是创建帐户然后通过爬虫抓取,而是利用 ActivityPub 网络的互联互通特性,直接将实例中缓存的外站用户数据创建为李鬼帐户。

不同实例互联互通是联邦宇宙(fediverse)的最大优点,但是难免会存在殆知阁这样的恶意节点/实例存在,那么应如何确保本站的数据不流入这些恶意节点呢?

答案是开启 secure mode

所需条件:服务器运行 Mastodon v3.2.0 以上版本。

具体操作步骤是:

  1. .env.production 文件中添加 AUTHORIZED_FETCH=true

  2. 重启 Mastodon 相关服务。

  3. 运行 tootctl accounts rotate --all 管理命令,更换当前实例所有帐户的密钥。

完成上述步骤后,本站在此操作之后的新嘟文就将不会流入被封禁(suspend)的实例。


下面介绍原理。

我们先看一看开启 secure mode 之后,Mastodon服务器有什么改变?

三大改变:

  • 改变一:Mastodon 将不再为 public 属性的嘟文生成 linked-data signatures

  • 改变二:所有 ActivityPub 请求均需带有 HTTP Signatures

  • 改变三:所有涉及用户的API请求,必须携带有效的Token。


什么是 HTTP Signatures?

ActivityPub 协议标准中只定义了客户端与服务端,服务端与服务端之间如何通迅,以什么格式进行通迅,但对于身份认证并没有做出相应的规定。

如果不进行身份认证,必然会出现仿冒他人身份(actor)大发垃圾信息(SPAM)的情况出现。

因此,Mastodon 在实现 ActivityPub 协议标准时,采用了 HTTP Signatures 的认证方式。

Mastodon 为每个帐户(actor)生成一对RSA密钥,在向其它实例的 inbox 投递信息时,所发送的 HTTP 请求中附带有 Signature 请求头。 该请求头中,指明了本条消息的签名密钥所在位置以及签名内容。

当 inbox 收到 ActivityPub 相关请求时,Mastodon 将会验证 Signatures 请求头中附带的签名的有效性,如果该签名通过验证,则接受该请求,否则拒绝该请求。

/images/mastodon-secure-mode/signature_verification.svg

Mastodon验签流程,参见 signature_verification.rb

什么是 Linked Data Signatures?

除了上述 HTTP Signatures, Mastodon 还支持 Linked Data Signatures。

Linked Data Signatures 顾名思义,即附加于 JSON-LD 数据中的签名。

设想这样一个场景:

你的实例加入了一个中继(relay),该中继有数百个成员,你向该中继投递一条 public 属性的嘟文,然后该中继向加入该中继的数百个实例投递转发了你的这条嘟文。

如果没有 LD-Signatures,这些实例收到中继转投的这条嘟文,因为无法确定该条消息的可靠性,将要据嘟文URL,从原站(即你的实例)尝试抓取这条消息,你的服务器必须要应对纷至踏来的抓取请求。如果你加入了一个大型中继,这将对你的服务器造成很大的压力。

如果向中继投递时附上了 LD-Signatures ,加入该中继的其它实例将便能自行验证该消息的可靠性,而无须从原站重新抓取。

但这样带来的问题是,由于 LD-Signatures 的存在,该消息是可以自验证的,所以你无法控制该嘟文的传播范围。


当你启用 secure mode 之后,由于停止了 Linked Data Signatures,当一条嘟文因为转发或中继到达新实例时,新实例为了验证该嘟文的可靠性,该实例必须从原站(你的实例)重新抓取。因此你可以控制嘟文的传播范围。

此外,Mastodon v3.2.0 后 ActivityPub 相关的 GET 请求也需要有效签名。

如果你的实例从一开始便屏蔽了实例A,并且同时开启 secure mode。

实例A将不能获得到你实例帐户的密钥,来自你实例的请求,将由于缺少相关密钥,无法验签而直接被Mastodon拒绝,因此你实例的嘟文将不会流入实例A。

如果你之前没有开启 secure mode,在开启 secure mode 之后,使用 tootctl accounts rotate --all 更换所有已存在帐户的密钥,也可以达到同样的效果。


secure mode 的副作用大概是对于旧版本(低于 v3.0.0)实例兼容性不好,您实例的数据可能无法被这些装有旧版本的实例接受。

不过,现在 v3.3.0 都已快出来了,绝大部分的中文实例也都升级至 v3.0.0 版本以上了,开启 secure mode 并不会带来太大冲击。

当然,万年不升级的 Pawoo 除外。

以下是开启 secure mode 并更换所有帐户密钥后在 Pawoo 上的体验,你可以借此大致体验一下 secure mode 对于被封禁实例的效果。

BGME实例可以看见Pawoo实例发出的消息,但Pawoo实例看不见BGME实例发出消息。

此外,Pawoo实例也将无法发现BGME实例的新用户。

位于Pawoo实例的嘟友,对不住了。