差别
这里会显示出您选择的修订版和当前版本之间的差别。
两侧同时换到之前的修订记录前一修订版后一修订版 | 前一修订版 | ||
activitypub-security [2021/09/01 16:00] – Replentish shykana | activitypub-security [2021/09/11 08:12] (当前版本) – shykana | ||
---|---|---|---|
行 13: | 行 13: | ||
(“本站”这个词会有歧义吗?因为是您在阅读这篇文章,所以“本站”是指**你**所在站点的站长。站长这一词指的是对服务器本身有管理员权限的用户,虽然在技术上,对服务器本身有权限,以及对服务器软件有权限,这两者是不同的。(一般认为前者权限更高。)但因为目前大多服务器“站长”都同时具有这两者权限,这里简单起见,我们把两者统称为“站长”,权限取二者之和。) | (“本站”这个词会有歧义吗?因为是您在阅读这篇文章,所以“本站”是指**你**所在站点的站长。站长这一词指的是对服务器本身有管理员权限的用户,虽然在技术上,对服务器本身有权限,以及对服务器软件有权限,这两者是不同的。(一般认为前者权限更高。)但因为目前大多服务器“站长”都同时具有这两者权限,这里简单起见,我们把两者统称为“站长”,权限取二者之和。) | ||
- | 下面的论述均建立在实例“正常”运作的前提下。这里的“正常”指的是至少遵守 ActivityPub 标准。若要考虑最坏情况,也即对方站点不遵守标准、竭尽全力剥夺信息的情况,请参考“外站站长”一节。 | + | 下面的论述均建立在实例“正常”运作的前提下。这里的“正常”指的是至少遵守 ActivityPub 标准。(因为 ActivityPub 根据在不同服务器软件中可能用不同的变种,这里的 ActivityPub 把一些未严格规定的、但广为应用的规范也纳入了考虑。)若要考虑最坏情况,也即对方站点不遵守标准、竭尽全力剥夺信息的情况,请参考“外站站长”一节。 |
+ | |||
+ | 另外,就算是一般意义下正常运作的站点,也可能出现不符合下述描述的情况。例如,维护中或是更新中的站点无法与其它站点通信,因而从另外一个站点出发的屏蔽请求可能会被暂时错过,从而没有成功屏蔽。(事实上,一般这种情况下,服务器会继续间断地发出屏蔽请求,直到对方服务器维护或更新完毕或是判断对方服务器断线过久为止。) | ||
==== 没有账号的普通人 ==== | ==== 没有账号的普通人 ==== | ||
行 19: | 行 21: | ||
额,这个普通人可以注册账号……当然,在没有账号的情况下,TA 还是可以: | 额,这个普通人可以注册账号……当然,在没有账号的情况下,TA 还是可以: | ||
* 查看你公开主页的活动(一般包括公开嘟文以及转发)、用户名、账号简介; | * 查看你公开主页的活动(一般包括公开嘟文以及转发)、用户名、账号简介; | ||
- | * 如果你是 Mastodon 用户,并且站点开启了 RSS 功能:订阅你账号的 RSS; | + | * 如果你是 Mastodon |
- | 这里需要提一句:技术上,**没开安全模式的情况下**,就算你所在实例有“公开主页只显示 10 条”等的功能,在比较坏的情况下,一个没有账号的普通人**仍然**可以看到你公开的所有嘟文。方法我不打算说,但可以说是非常简单。当然,服务器理论上也可以对此进行应对。**就算开了安全模式**,只要这个普通人找到一个没有被屏蔽的实例,例如 mastodon.social 等开放注册的实例(假设这个实例没有被本站实例屏蔽),那么他就可以升变为“有(可能许多)账号的普通人”,即下一节的内容。 | + | 这里需要提一句:技术上,**没开安全模式的情况下**,就算你所在实例有“公开主页只显示 10 条”等的功能,在比较坏的情况下,一个没有账号的普通人**仍然**可以看到你公开的所有嘟文。方法我不打算说,但可以说是非常简单。当然,服务器理论上也可以对此进行应对。(这里对站长说一句,真的想弄的话最简单的是把 outbox 节点直接在 nginx 里屏蔽。)**就算开了安全模式**,只要这个普通人找到一个没有被屏蔽的实例,例如 mastodon.social 等开放注册的实例(假设这个实例没有被本站实例屏蔽),那么他就可以升变为“有(可能许多)账号的普通人”,即下一节的内容。 |
==== 有(可能许多)账号的普通人 ==== | ==== 有(可能许多)账号的普通人 ==== | ||
行 75: | 行 77: | ||
* 我们的用户名、个人简介、头像; | * 我们的用户名、个人简介、头像; | ||
- | 在本站屏蔽了这个外站后,外站上仍然有可能留下屏蔽前的信息。 | + | 在本站屏蔽了这个外站后,外站上仍可能: |
+ | * 留下屏蔽前的信息; | ||
+ | * 没有开启安全模式时: | ||
+ | * 主动获取上面提到的“对方站点主动获取的内容”; | ||
+ | * 经由双方实例都加入的 “中继”(relay)获取信息。 | ||
我们的邮箱、IP 地址不会被外站知道。 | 我们的邮箱、IP 地址不会被外站知道。 | ||
+ | |||
+ | ==== 微博对微博用户的权限? ==== | ||
+ | |||
+ | 可以把上面的“本站站长”权限与法律取一个大致的交集。 | ||
===== 屏蔽(Block)有什么作用? ===== | ===== 屏蔽(Block)有什么作用? ===== | ||
行 109: | 行 119: | ||
实际上,一般来说(对大多情况下的 c 来说),c 的“转发”实际上进行了如下操作:c 所在的实例 C 对实例 B 说“我转发了 https:// | 实际上,一般来说(对大多情况下的 c 来说),c 的“转发”实际上进行了如下操作:c 所在的实例 C 对实例 B 说“我转发了 https:// | ||
- | 但是,一个人可以有多个账号,这方面不多说,而身份信息的欺骗从技术上大概也只需要多一个没有被屏蔽的域名而已,只要实行的不是密不可透的**白名单**,那么还是会有风险。 | + | 但是,一个人可以有多个账号,这方面不多说,而身份信息的欺骗从技术上大概也只需要多一个没有被屏蔽的域名而已,只要实行的不是密不可透的**白名单**,那么还是会有风险。(但有时候可能增加哪怕那么一点安全性也是好的?无论如何还是不要放松警惕。) |
注:这里的身份信息的校验大概过程是: | 注:这里的身份信息的校验大概过程是: | ||
行 115: | 行 125: | ||
- A 再去问 B “这个访问是不是你的呀”,得到回应(其实是密码学校验,不是回应)后,放行/ | - A 再去问 B “这个访问是不是你的呀”,得到回应(其实是密码学校验,不是回应)后,放行/ | ||
- 但如果 B 说自己是 D,同时 B 有 D 的控制权,那么欺骗 A 从技术上说是可能的。(但这样子倒不如直接从 D 那里访问。) | - 但如果 B 说自己是 D,同时 B 有 D 的控制权,那么欺骗 A 从技术上说是可能的。(但这样子倒不如直接从 D 那里访问。) | ||
- | |||
- | (有时候可能增加哪怕那么一点安全性也是好的吧……但是如果实在在意的话,不要放松警惕。) |