您的足迹: activitypub-security

Mastodon/Misskey/Pleroma 的安全性?

Mastodon/Misskey/Pleroma 的安全性?

在我接触到的中文泛长毛象社区中,经常可以看到关于长毛象以及(基于 ActivityPub 的)联邦宇宙的隐私以及安全性问题。在这里我尝试对一些相关讨论做一些总结。还在施工中,欢迎补充斧正~

安全性是什么?

这个问题讨论起来会没完没了。所以这里不打算对此做出说明。

各角色的权限

在这里我们看一下在不同设置下不同身份的人对我们信息的不同权限。下面假设没用屏蔽或是 Mastodon 安全模式(Secure Mode)。

(“本站”这个词会有歧义吗?因为是您在阅读这篇文章,所以“本站”是指所在站点的站长。站长这一词指的是对服务器本身有管理员权限的用户,虽然在技术上,对服务器本身有权限,以及对服务器软件有权限,这两者是不同的。(一般认为前者权限更高。)但因为目前大多服务器“站长”都同时具有这两者权限,这里简单起见,我们把两者统称为“站长”,权限取二者之和。)

下面的论述均建立在实例“正常”运作的前提下。这里的“正常”指的是至少遵守 ActivityPub 标准。(因为 ActivityPub 根据在不同服务器软件中可能用不同的变种,这里的 ActivityPub 把一些未严格规定的、但广为应用的规范也纳入了考虑。)若要考虑最坏情况,也即对方站点不遵守标准、竭尽全力剥夺信息的情况,请参考“外站站长”一节。

另外,就算是一般意义下正常运作的站点,也可能出现不符合下述描述的情况。例如,维护中或是更新中的站点无法与其它站点通信,因而从另外一个站点出发的屏蔽请求可能会被暂时错过,从而没有成功屏蔽。(事实上,一般这种情况下,服务器会继续间断地发出屏蔽请求,直到对方服务器维护或更新完毕或是判断对方服务器断线过久为止。)

没有账号的普通人

额,这个普通人可以注册账号……当然,在没有账号的情况下,TA 还是可以:

  • 查看你公开主页的活动(一般包括公开嘟文以及转发)、用户名、账号简介;
  • 如果你是 Mastodon 或 Pleroma 用户(Misskey 有待测试),并且站点开启了 RSS 功能:订阅你账号的 RSS;

这里需要提一句:技术上,没开安全模式的情况下,就算你所在实例有“公开主页只显示 10 条”等的功能,在比较坏的情况下,一个没有账号的普通人仍然可以看到你公开的所有嘟文。方法我不打算说,但可以说是非常简单。当然,服务器理论上也可以对此进行应对。(这里对站长说一句,真的想弄的话最简单的是把 outbox 节点直接在 nginx 里屏蔽。)就算开了安全模式,只要这个普通人找到一个没有被屏蔽的实例,例如 mastodon.social 等开放注册的实例(假设这个实例没有被本站实例屏蔽),那么他就可以升变为“有(可能许多)账号的普通人”,即下一节的内容。

有(可能许多)账号的普通人

注意,一个人可以有许多账号。

已被屏蔽了

这里的屏蔽可以是你的帐号屏蔽了这个人的帐号,也可以是本站实例屏蔽了这个人的帐号,甚至可以是本站实例屏蔽了对方帐号的实例。

(当然,TA 可以还是在合适的实例再注册一个帐号从而前往“没有关注你”的下一节。TA 仍然具有上一节的“没有账号的普通人”的权限。)

总之,在这个范畴下,如果对方帐号的实例还在“正常”运作的话:

  • TA 无法看见你的所有发布内容(可能可以看见头像以及帐号简介,这个有待验证)。

没有关注你

如果你没有开启关注审核,这个普通人可以随时关注你,从而进入下一节的内容。总之,在还没关注时,TA 可以:

  • 看到你的非私信、非关注者可见的内容;
  • 向你发送信息(包括嘟文、点赞等等);

关注了你

  • 可以看到你的仅关注者可见的内容。

被发送了私信

(如果 TA 没有被屏蔽,)被发送了私信后,TA 可以:

  • 看到你给 TA 发送的私信内容。

站长

本站站长

站长具有的权限是最大的。站长可以做到包括但不限于以下事情:

  • 修改本站账号的任何信息,乃至删号;
  • 查看本站账号的任何信息,包括私信、关注者可见的嘟文、邮件地址、IP 地址等;
  • 修改本站账号的浏览内容,如全站封禁外部账户(哪怕站内用户关注了此用户)、封禁某站点、过滤特定嘟文(Pleroma MRF);

以上是许多联邦宇宙服务器软件都会为站长提供的功能。但是,如果考虑极端情况,如服务器本身被入侵了,那么也有密码泄漏、帐号被夺走、身份被冒充等可能性。总之,基本概括下来,本站站长能够访问、修改、删除个人用户在本站站点上留下来的任何信息。

本站站长与外站站长的对本站用户的权限当然是不一样的。下面介绍外站站长的权限。

外站站长

和上面的总结相同,站长能够访问、修改、删除个人用户在站点上留下来的任何信息;修改或删除这些信息只会影响到 TA 们站内用户的浏览内容以及部分发布内容的到达范围。(这里不考虑站长冒用账户等各种情况。)所以这里的问题就变成“我们会在外站上留下什么信息”了。

在本站没有屏蔽这个外站的情况下,我们在外站留下的信息包括:

  • 我们给这个站点用户“主动”发送的所有内容,包括:发给对方用户的私信、@有对方的嘟文(这个与站点设置有关);
  • 我们给这个站点用户“隐式”发送的所有内容(对方站点有你的关注者时,你发的非私信内容都会发送给关注者,也包括你点的赞、互动和转发);
  • 对方站点主动获取的内容,这里包括 ActivityPub 协议中定义为公开的内容,基本上即:
    • 我们的公开内容,例如公开嘟文以及转发;
    • 我们的用户名、个人简介、头像;

在本站屏蔽了这个外站后,外站上仍可能:

  • 留下屏蔽前的信息;
  • 没有开启安全模式时:
    • 主动获取上面提到的“对方站点主动获取的内容”;
    • 经由双方实例都加入的 “中继”(relay)获取信息。

我们的邮箱、IP 地址不会被外站知道。

微博对微博用户的权限?

可以把上面的“本站站长”权限与法律取一个大致的交集。

屏蔽(Block)有什么作用?

在屏蔽后,屏蔽前的信息仍然有可能留下。

屏蔽一个用户

屏蔽的作用可以分为站内和站外两方面。在站内,其作用便是把有关用户的内容(包括互动)全部屏蔽、取消关注等。而在站外,你所在站点会通知被屏蔽用户所在的站点,让其配合。如果这个站点是正常的,那么被屏蔽用户也将看不见你所发的内容、取消关注等等;但是,如果站点不是很正常,那么就有其它可能。(例如,有一个站点会将其收到的屏蔽信息公开发布出来。)

所以,屏蔽只针对一个人的一个号,还需要对方实例本身正常运作。

一个用户屏蔽一个实例

屏蔽实例并不是 ActivityPub 协议的内容,我们只能猜测一下在不同服务器软件的它的实现。一个最可能的猜测就是:你屏蔽一个实例时,你等同于屏蔽其上所有用户,(有可能会向你关注的对方实例的用户、一些其它的已知用户发送屏蔽通知),你此后发布的信息都不会被主动推送到屏蔽的服务器。但是在未开启安全模式的情况下,对方站点仍可能得以主动获取一些信息。(见“外站站长”一节的“对方站点主动获取的内容”。)

本站实例屏蔽另一个实例

屏蔽实例并不是 ActivityPub 协议的内容,同样,我们只能猜测一下在不同服务器软件的它的实现。一个可能是:此时,本站向屏蔽的实例不会发出任何连接,此后发布的信息都不会被主动推送到屏蔽的服务器。

同样,在未开启安全模式的情况下,对方站点仍可能得以主动获取一些信息。(见“外站站长”一节的“对方站点主动获取的内容”。)

长毛象安全模式(Secure Mode)有什么作用?

所以屏蔽似乎没什么用,没有账号的普通人都可以对你的日常发布一览无余。安全模式主要想解决的是“尝试获取我们信息的到底是谁”这个问题。上面没有账号的普通人没有身份信息,但也可以访问一些数据,而安全模式使得任何访问都必须附上自己的身份信息(除网页访问外,这里的访问主要指的是使用 ActivityPub 这种协议在服务器之间的通讯)(当然,网页也可以添加其它的限制,如最多 10 条嘟文,或是直接空白不显示)。

开启了安全模式的话,如果访问附上的身份信息没有欺骗我们的话,那么我们就可以实现更好的屏蔽。这一点的讨论经常会涉及转发的问题:

  1. 我(a)所在实例 A 屏蔽了实例 B,
  2. 实例 B 上有个用户 b 关注了实例 C 上的用户 c,
  3. 那么用户 c 转发我(a)的嘟文会不会被 b 看到?

实际上,一般来说(对大多情况下的 c 来说),c 的“转发”实际上进行了如下操作:c 所在的实例 C 对实例 B 说“我转发了 https://AAA/aaa/123 这条链接的东西”,实例 B 顺着这个链接去向实例 A 要相应的内容。所以,B 要想知道真正的内容必须要经过 A,而安全模式使得我们知道来访者是 B ,这时屏蔽就可以起作用,这没有安全模式是做不到的。

但是,一个人可以有多个账号,这方面不多说,而身份信息的欺骗从技术上大概也只需要多一个没有被屏蔽的域名而已,只要实行的不是密不可透的白名单,那么还是会有风险。(但有时候可能增加哪怕那么一点安全性也是好的?无论如何还是不要放松警惕。)

注:这里的身份信息的校验大概过程是:

  1. B 访问 A 时说自己是 B,(没有安全模式时 B 可以直接说自己是个普通人,下面的屏蔽也无从谈起。)
  2. A 再去问 B “这个访问是不是你的呀”,得到回应(其实是密码学校验,不是回应)后,放行/屏蔽访问。
  3. 但如果 B 说自己是 D,同时 B 有 D 的控制权,那么欺骗 A 从技术上说是可能的。(但这样子倒不如直接从 D 那里访问。)