如何测试VPN安全与否


原文链接:

https://zh.vpnmentor.com/blog/%e5%a6%82%e4%bd%95%e6%b8%ac%e8%a9%a6vpn%e7%9a%84%e5%ae%89%e5%85%a8%e6%80%a7/

一般人使用VPN服务的主要目便是对数据安全的考量。但是您如何确定您的VPN能确实保护您?,即使您正连接到至VPN,在安装VPN时,有几个步骤可能会出错并因此泄漏您的数据和暴露您的IP地址。

在本文中,我们将帮助您搞懂数种可用于测试VPN连接以防止各种泄漏的工具。本文所提到的所有测试工具都能让您知道您的VPN是否真的在保护您。

DNS泄露测试


DNS说穿了就是网域名称系统(Domain Name System)。借由将网域名称转换为相应的IP地址,它能使访问网站更为容易。举例来说,vpnmentor.com被分配的IP地址是104.25.7.109。

在一般情况下,将网域名称转换为相应IP地址的工作乃由互联网服务供应商(ISP)提供。然而,在您使用VPN时,您的真实IP地址将被隐藏,从而阻止其他人追踪您的位置。

有时,VPN通道会泄露转换的请求,您的互联网服务供应商的IP地址和所在位置也会因此暴光。而您若想要进行DNS泄漏测试,只需连接至位于您所在国家以外的VPN服务器。接下来,您可以使用像dnsleaktest.com这类的工具。如果其中的IP地址、位置和其他详细资讯与ISP的IP地址、位置等细节吻合,就表示您的DNS被泄漏了。

请注意,DNS泄漏不会导致您的IP地址曝光。其泄漏的是您的互联网服务供应商的IP地址和位置,而这些资讯可以轻易被用来追踪您的IP地址。

要防止DNS泄漏,请使用本身拥有加密DNS系统的VPN。

IP地址泄漏测试


多数VPN都声称能保护您的IP地址,但事实却非如此。根据一项针对Android VPN应用程序的研究发现,有84%的VPN泄露其用户的真实IP地址。

要测试您的VPN服务是否泄露您的IP地址,只需使用我们的IP泄露测试工具

必须注意的是,VPN连接处于活动状态以及处于重新连接阶段时,是最有必要进行IP地址泄漏测试的时刻。 多数VPN会在连接断开后的重新连接时间内泄漏您的IP地址。

为防VPN失去连接,VPN通常有一个完全阻止所有互联网流量的杀死键

以下为在重新连接阶段进行VPN的IP地址泄漏测试的步骤:

  1. 断开互联网,并同时保持VPN的连接及运转
  2. 一旦失去连接,便重新连接并执行连续性的IP测试。此步骤可以通过打开IP测试网页的多个标签页来完成,之后再尽快更新每个标签页。
  3. 一旦VPN重新连接后,便请停止刷新并检查测试结果。
  4. 如果您的真实IP地址出现在几个标签页中,便表示您有重新连接泄漏的情形。

欲防止IP地址泄漏,您必须确保使用一个安全的VPN。如果您有IPv6泄漏的情形,您可以手动卸除您的装置上的IPv6连接。此外请注意,如果您的VPN支持IPv6,您也会自动获得针对IPv4的防护。

WebRTC泄漏测试


WebRTC是个主要可在像Firefox、Chrome和Opera等网络浏览器中看到的API定义,其可允许P2P文件共享以及Web浏览器中的语音和视频聊天,并无需任何外部附加元件或扩充程序。市面上有各种可用于Internet Explorer和其他浏览器以支持WebRTC的附加元件。

当您的IP地址经由WebRTC API泄露时,便会发生WebRTC泄漏。您可以借由访问网站Perfect Privacy WebRTC Test来测试您的VPN WebRTC泄漏。

您可以在您正在使用的浏览器中停止使用WebRTC以防止其泄漏。

VPN速度测试

除了隐私和安全性外,速度也是VPN服务中最重要的面向之一。影响VPN速度的因素很多。以下是其中的几个因素。

  1. 受到您的互联网服务供应商的限制


无论您的VPN有多快速,其速度永远不会超过您的互联网服务供应商所提供的速度。您的互联网服务供应商控制您的互联网的整体速度。

  1. 加密的層級


隨著加密級別的增加,VPN的速度會相對下降。 L2PT協議比PPTP協議更安全,但速度明顯更低。如果您在互联网上執行的多數工作項目不需要高級別的加密,則我們更建議您使用較低級別的加密。

  1. 用户与VPN服务器之间的物理距离


这是影响VPN速度最常见的因素。如果您在印度使用位于美国的VPN服务器,则您便需要忍受较慢的网络速度。选择位于您所在地附近的VPN服务器将能解决这个问题。

  1. VPN服务器上的使用人数


许多受欢迎的VPN服务供应商的服务器超载,因而导致速度缓慢。在购买VPN之前,请确保其提供一个服务器状态的页面以显示即时的频宽资讯。

  1. 防火墙设定


您的防火墙设置不能影响VPN流量或CPU性能,因为其可能因此大为减低速度。

  1. 装置的处理能力


每当您的计算机或移动装置上的VPN处于启用状态时,您的装置便会不断在后台运作以加密和解密一封又一封的资讯。 此过程耗用相当大的处理能力。 而更快的互联网速度,也需要更强大的处理能力。

因此,即使您的VPN速度很快,而且您也有高标准的互联网连接,您的CPU仍可能会抑制速度的表现。

若想测试您的VPN速度,可参考Speedof.me的网站。



进阶必读:代理协议 UDP 全方位透彻解析

原文链接:https://v2xtls.org/%e8%bf%9b%e9%98%b6%e5%bf%85%e8%af%bb%ef%bc%9a%e4%bb%a3%e7%90%86%e5%8d%8f%e8%ae%ae-udp-%e5%85%a8%e6%96%b9%e4%bd%8d%e9%80%8f%e5%bd%bb%e8%a7%a3%e6%9e%90/

绝大多数人对代理协议中的 UDP 部分完全没概念,目前很多经验丰富的使用者甚至是开发者一遇到 UDP 就变成小白,导致大多数关于 UDP 的问题悬而不决。鉴于 UDP 正扮演着越来越重要的角色,却没有一篇文章讲代理协议中的 UDP,我干脆写了这篇文章。

这篇文章的目的就是扭转现状,让大家完全参透 UDP,以便更游刃有余地使用 Xray-core 或其它代理类软件。 —— RPRX

简单理解 IP Packet、TCP Connection、五元组、端口、User Datagram Protocol

这些是必须掌握的基本概念,实际上非常简单。

IP Packet:一个个符合 IP 协议的数据包,允许丢包,允许乱序(即接收时的顺序不同于发送时的顺序),属于非可靠传输。

它不是最底层的形式,这里无需深究,重点是知道它的特性。IP 数据包无法直接提供可靠传输,这对应用来说当然是很不方便的,于是就有了面向连接的 TCP 协议,它基于 IP 数据包,但实现了一套连接和可靠传输机制,大多数其它协议直接放 TCP 上面即可。

确定一个 TCP 连接的是“五元组”:

  1. TCP 协议本身的标识
  2. 自己的 IP 地址
  3. 自己使用的一个端口(Port)
  4. 对方的 IP 地址
  5. 对方使用的一个端口

TCP 连接建立后,双方便可从自己的端口向对方的端口发送应用数据,这是全双工的,即双方都可以一边发送数据、一边接收数据。

“端口”这个概念各位都不陌生,它常和 IP 一起出现,但实际上它不属于 IP 协议(没想到吧.jpg),它属于更上层的 TCP、UDP 协议。TCP、UDP 是分别实现了“端口”这一标识方式,所以这两个协议的“端口”不会互相影响。 ping 用到的协议是 ICMP,它也是基于 IP 数据包,与 TCP、UDP 是类似的,但 ICMP 就没有“端口”这个概念。顺便提一句,常见的代理协议只能代理 TCP 或加个 UDP,不能代理 ICMP,所以就无法 ping,有此需求请用传统的 VPN。

接下来终于轮到我们的主角登场了:UDP(User Datagram Protocol)

虽然 UDP 和 TCP 一样是基于 IP 数据包的,但它异常简单,直接完全继承了 IP 数据包的特性:

  1. 允许丢包
  2. 允许乱序
  3. Apparently,属于非可靠传输

你可以这样简单理解:UDP 协议就只是在 IP 协议的基础上加了一个端口机制和校验而已。

对于 UDP 而言,TCP 的“连接”机制也是不存在的,即你申请到一个本地 UDP 端口后,不需要握手/建立连接即可直接向任意 IP 的任意 UDP 端口发送应用数据。 不需要关心对方有没有收到数据,对方也不会告诉你有没有收到数据。(需要指出:存在一种 connected UDP 的中间状态,这只是在发送数据前确定一下目标地址,并没有真正去握手)

UDP 的这些特性催生了三种应用方式:

  1. 注重效率,比如 DNS 查询(不需要先握手)
  2. 注重实时,比如直播、语音等(允许丢包,不需要等重传)
  3. 两者皆有 + P2P,比如一些联机游戏、语音等。注意这就是充分利用了上面加粗的那种 UDP 特性,也是本文的重点。

当然还有另一种对 UDP 的应用方式:基于 UDP 造新的通用可靠传输协议,比如 KCP、QUIC。为什么这些新协议不直接基于 IP 协议而要基于 UDP 协议?因为前者往往需要各级运营商进行设备、系统改造来支持,这显然不太现实,所以 UDP 成了更合适的选择。

那么 FullCone、Symmetric 又是什么?

这两个指的都是 NAT 行为,NAT 的全称为 Network Address Translation,就是你家路由器、各级运营商做的事情:地址转换。NAT 的广泛存在是因为 IPv4 地址不足,另一方面它还可以保护局域网中的设备。

对于 TCP 而言,NAT 行为是什么并不重要,因为 TCP 是双向的流,本机每发起一个 TCP 连接往往会使用一个新的临时端口,从而对应一个新的五元组。

但对于 UDP,NAT 行为可太重要了,因为 UDP 是方向不定的包,使用同一个本地 UDP 端口向不同的目标二元组发包十分常见。

二元组:IP 和 Port,任一不同即视为不同的二元组

那么这种情况下 UDP 数据包到达路由器后,路由器要怎样转发它呢?这就取决于路由器的 NAT 行为了。

其实 NAT 行为多种多样,这里先举例介绍最具代表性的情况。首先有以下情景:

  1. 本地来源二元组 A 向远端目标二元组 M 发若干个包
  2. 本地来源二元组 A 又向远端目标二元组 N 发若干个包

如果由于目标二元组不同,路由器把 A->M、A->N 分别映射成了自己的 A1->M、A2->N(一般为分别使用两个不同的端口发包),且严格限制回包来源,就属于 Symmetric。不难发现,这时候实际上变成了类似 TCP “连接”的通信模式,也是大多数运营商的做法。

而若路由器只看来源二元组 A,始终映射成自己的 A1 向 M、N 发包,就属于 Cone NAT;更进一步,如果 A1 收到了回包,路由器不管来源,直接把这个包发回给 A,就属于 FullCone,也是代理类软件能实现的最佳 NAT 等级、P2P 游戏必备神器(GTA NAT 开放)

上面是简单举例,现实中运营商大概率不会主动分配给你一个公网 IP,也就是说还需要经过层层 NAT,最终得到 Symmetric 很正常。所以为什么你用了代理协议,比如 Xray-core 的 Shadowsocks、Trojan 就可以获得 FullCone?

很简单,因为此时用到的是你的 VPS 的公网 IP,和你本地的 NAT 环境没有任何关系。

这就是为什么要特殊设置 VPS 的防火墙:它默认会过滤返回的包的来源,导致你只能得到某种 Restricted Cone 而不是 FullCone。

对于简单的 UDP 需求比如 DNS 查询,Symmetric 也不是不能用。但对于复杂的 UDP 需求,比如各类 P2P 场景,实现 FullCone 就非常重要了,因为应用程序需要对外使用一个固定的端口,通过这个端口不受限制地往任何目标发包、从任何目标收包(至少别测错了当前的 NAT 类型,后文会说明)。如果你主要是为了打游戏,可以让 UDP 走 SS 协议,因为它拥有原生 UDP 的特性。

这里提一下,Xray-core 正计划着推出更适合打游戏的协议。

Xray-core 和一些代理协议中的 UDP 细节讲解

前面都是铺垫,终于到主菜了。

Xray-core 同时支持 FullCone 和 Symmetric 两种模式,且对协议的支持也非常全面,是很理想的例子。

完美支持 FullCone 的有:

  • Shadowsocks 入站、出站
  • Trojan 入站、出站
  • Socks 入站、出站
  • Dokodemo-door TPROXY 入站(透明代理)
  • Freedom 出站,支持域名解析

仅支持 Symmetric 的有:

  • VMess,因为协议结构不支持,后面会说原因
  • 当前的 Mux,同样是协议结构不支持
  • VLESS(FullCone 在路上了)

众所周知 v2ray 对 UDP 的支持一言难尽,所以 Xray-core 是重构了相关架构和各个出入站的代码,外加反复测试和对很多细节问题的定位、修复,才实现了全面 FullCone 化(除非协议不支持,这种情况会为它准备没问题的 Symmetric,Clash 的 VMess 存在问题)

Xray-core 的 release note 都很有营养,再摘抄一段:

  1. Socks5、Shadowsocks 都是原生 UDP,它们的 UDP 不走底层传输方式
  2. VLESS、Trojan、VMess、Mux 都是 UDP over TCP,且走底层传输方式
  3. HTTP 出入站不支持代理 UDP,Socks 版本 5 之前也不支持 UDP
  4. 这里的 FullCone 指的是 UDP 的 NAT 行为,配置时尤其注意防火墙
  5. 链式代理若要实现 FullCone,一般来说所有环节都要支持 FullCone
  6. Docker 若要实现 FullCone,相关容器的网络模式需要是 Host

补充:Socks、SS 是原生 UDP,套 TLS/WSS 后它们的 UDP 并没有被特殊处理,除非开了 Mux。SS 的 SIP003 插件也不管 UDP。

UDP over TCP 简称 UoT,特别注意,即使你用 mKCP、QUIC 作为底层传输方式,UoT 的也并不会表现出原生 UDP 的那些特性。

v2ray-core 存在的问题

这里主要是解惑,让 UDP 不再玄学。

  1. v2ray-core 架构上只支持 Symmetric 路由,所以你用 v2ray-core 的任何协议都只能 Symmetric
  2. v2ray-core 各出入站对 UDP 的处理和 TCP 是类似的逻辑,不可能实现 UDP 特有的 FullCone
  3. v2ray-core 的 Freedom 出站收返回的包时却没有按 Symmetric 过滤来源,这是玄学的根本原因
  4. v2ray-core 中各处维持 UDP 映射关系的不活动超时时间都很短,所以很容易出现断流等情况

对于第 3 点,简单来说是这样:

  1. 正常的 Symmetric NAT,A 对 M 发过包,只能收到从 M 返回的包,其它的会被过滤掉
  2. 如果中间插一个 v2ray,即使 A 没对 N 发过包,A 也能收到 N 发过来的包
  3. 重点是此时 N 的地址被丢掉了,A 会以为这个包是 M 发给它的,绝无仅有的迷惑行为

这种行为是预期之外的,再加上一些不标准的测试服务器,就会导致能给 v2ray、VMess 测出 FullCone,实际上却完全不起作用。

去年七月底我在某个开发者群内说过这个问题(不标准的测试服务器比如 Google 的那些,以及 v2ray UDP 的迷惑行为),随后 NatTypeTester 的更新只保留了五个标准的测试服务器,并特意验证了返回的包的源地址,测 v2ray 会显示 UnsupportedServer。

此外,Google 的一些应用会先自己测一下当前网络的 NAT 类型,若测出了假的 FullCone,就会导致奇奇怪怪的问题。

NAT 行为进一步探究

相信你已经发现了,NAT 行为并不只有 FullCone、Symmetric 这两种(但这是最极端的两种),实际上 NAT 行为由“发包时映射”和“收包时过滤”这两个行为来共同确定,FullCone 就是两者都最开放,Symmetric 就是两者都最严格,引用一张图:

Fig5 STUN


可以看到,RFC 3489 定义了四种经典的 NAT 行为,v2ray 实际上不属于其中的任何一种,但它最接近 RFC 5780 的 Address and Port-Dependent Mapping 加 Endpoint-Independent Filtering,即图中的 NAT Type 7,只是可能会把返回的包的来源搞错。

Xray-core 的代理协议如何实现 FullCone

这是本文的核心内容,其实原理很简单:把你本地的一个 UDP 端口映射为 VPS 的一个 UDP 端口,并使它们具有相同的效果。

拿一个最简单的场景举例:Socks 入站 + Freedom 出站

  1. Socks 入站收到二元组 A 发来的 Socks UDP 包,其中包含原始载荷与其原始目标 M,路由到 Freedom
  2. Freedom 出站使用一个随机端口将原始载荷发到其原始目标 M,这里认为 Freedom 使用了二元组 A1
  3. 映射关系已经建立,一段时间内 Socks 入站又收到了 A 发来的代理包,Freedom 还会用 A1 发到目标
  4. 同样地,如果 Freedom 的 A1 收到了 N 发回的包,Socks 就会把原始载荷同 N 这个信息一起发回给 A

当然,FullCone 还需要调用方按常理使用 Socks 代理协议,诸如各种 tun2socks 实现一般是没问题的。

下面插一个 Shadowsocks 出入站进来:

  1. 路由到 Shadowsocks 出站,它也是使用一个随机端口,将加密后的“载荷与目标”发到服务端的 SS 入站
  2. 服务端 SS 入站收到了客户端 SS 出站发来的 Shadowsocks UDP 包,解密,剩下的流程和上面没有区别

Trojan 协议的 UDP 也是类似的原理,不同之处是每个来源二元组都会对应一条 TCP 连接,在 TCP 上传输 UDP 的“载荷与目标”。

那么为什么同样是 UoT 的 VMess 却无法实现 FullCone?

根本原因是 VMess 的 UoT 协议结构只能在最开始时传一个“目标”,后面的多个数据包只能传“载荷”而不能带“目标”,服务端会把后续的数据包都发往最开始的“目标”。服务端向客户端返回数据包是同理的,协议结构只有“载荷”,客户端会认为返回的数据包都来自于最开始的“目标”,这和 v2ray 设计上的问题倒是一脉相承的,自带的 Mux 当然也是这样。(VLESS 也没有幸免,不过在改了)

所以对于 VMess、Mux、VLESS,Xray-core 目前是按 Symmetric 来路由的。否则如果是 FullCone 模式,后面的包都会被发到第一个包的目标地址,这就是 Clash 的 VMess 存在的问题,但并不好解决。此外,存在此问题时 VMess 又会被测出 FullCone,假的。

透明代理 TPROXY UDP 的原理

为了让游戏机用上 Xray-core 实现 FullCone,通常需要一个 Linux 设备来透明代理,一个树莓派就可以搞定。

为什么透明代理 UDP 只能 TRPOXY 而不推荐 REDIRECT?

  1. REDIRECT 会修改 UDP 包的目标二元组,并且此时 Linux 没有提供一个配套的机制让代理软件获知 UDP 包的原目标地址
  2. TRPOXY 则完全相反:它不会修改 UDP 包,Linux 还提供了简单的配套机制让代理软件获知 UDP 包的原目标地址

等需要往回发包时,代理软件会先在本地伪造出“返回的 UDP 包的来源二元组”的 socket,用这个 socket 把包发回去(这个原理就是可能会遇到 too many open files 的原因)。相比于其它软件,Xray-core 对这里有专门的优化,更优雅且有更好的性能。

若你在用 Windows 测透明代理的 NAT,一定注意要把当前网络设为 专用网络,这是很多人踩过的大坑,我也踩过。

提一下 QUIC:启用了 Xray-core 的 XTLS 时,通往 UDP 443 端口的流量默认会被拦截(拦截 QUIC),这样应用就不会使用 QUIC 而会使用 TLS,XTLS 才会真正生效。实际上,QUIC 本身也不适合被代理,因为 QUIC 自带了 TCP 的功能,UoT 就相当于两层 TCP 了。

斯坦福大学SIO|CLUBHOUSE在中国:它的数据安全吗?

原文链接:https://chinadigitaltimes.net/chinese/662679.html

该报告的英文版本

语音社交App “Clubhouse”,在中文听众中爆红。斯坦福大学网络观测平台(SIO)调查了这个App的数据是否保护它的用户数据,以及用户数据为何需要被保护。

Jack Cable, Matt DeButts, Renee DiRestaRiana PfefferkornAlex StamosDavid Thiel, Stanford Internet Observatory

上周,在中国大陆的iPhone用户在新兴的语音社交App“Clubhouse”展开了少见不受约束的讨论。这股在“Clubhouse”上使用中文母语的讨论风潮持续到了2021年2月8日被墙的那天。

除去一般关于旅游和健康的闲聊,一些用户也选择讨论一些涉及新疆再教育基地,1989年春夏政治风波以及少数个体遭遇部分警察不公正对待的“敏感”问题。中国官方一般会限制公开讨论这些议题,同时也使用技术手段(在外媒一般称为Great Firewall)限制国内的用户访问部分国外的App以及网站。即使在上周,Clubhouse尚未被墙,部分网友也担心官方会监听这些对话,对自己造成不便。

近些年,伴随着新一届以习近平为核心的领导班子,对网络舆情的引导和控制与日俱增。Clubhouse当中的语音信箱,相比于Twitter来说不会留下公共的记录,导致了北京需要更复杂的技术手段实现监控需求。

斯坦福大学网络观测平台(SIO)确认了一家位于上海的研发实时音视频互动技术企业,声网Agora。这家公司为Clubhouse提供了后台的技术支持(参见附录)。这层合作关系被广泛的猜测过,却从未被公开确认。此外,SIO还认定,Clubhouse的用户以及聊天室的ID都是用未被加密的明文传输的,同时声网Agora有很大的可能有访问用户语音原始数据的权限,并且有可能把这些权限转让给政府机构。SIO在至少一起事件中,观察到聊天室的元数据(Metadata,译者:描述数据的数据,例如一张电子照片的拍摄时间,相机参数就是属于元数据)被传送到我们认定的位于中国大陆的服务器中。同时语音文件也被传输到由中国企业管理的服务器,而后被Anycast发布到全世界。这一过程中,Clubhouse的用户ID可能和用户信息联系在一起。

SIO决定揭示这些安全隐患,因为它们相对明显而且有可能在短时间内对百万计,尤其是在中国国内的Clubhouse用户造成数据安全的威胁。SIO同时发现了其它安全漏洞,并且私下和Clubhouse的开发商取得了联系。在适时会想公众提供相关信息。

在这篇文章中,我们调查了中国政府通过声网Agora以及Clubhouse获取其中音频数据的潜在可能性。我们同时尝试揭示为何这件事很重要。我们将解释以下几个核心议题:

  1. 声网Agora是家怎么样的公司,我们是如何发现他们为Clubhouse提供技术支持,以及这一切意味着什么
  2. 中国政府如何获取储存在Clubhouse里的音频数据
  3. 中国大陆的用户有可能“因言获罪”吗
  4. 为何大陆官方要禁止这款App

声网Agora是家怎么样的公司,我们是如何发现他们为Clubhouse提供技术支持,以及这一切意味着什么

声网Agora是家怎么样的公司?

声网是一家位于上海,美国总部坐落于硅谷的初创企业。它出售“实时音视频互动”平台服务给其他软件公司。换句话说,通过使用这样平台技术,像Clubhouse这样的App开发商,可以专注于界面设计,特别功能,以及用户体验。一般来说,用户很有可能没有意识到,自己使用的App运行在声网的平台上。

我们是如何发现他们为Clubhouse提供技术支持?

SIO的分析员使用例如Wireshark的公开网络分析工具,观察Clubhouse的网络流量。基于分析我们发现:流出的网络被引导到了声网运营的服务器上,其中包含“qos-america.agoralab.co.” 。用户加入Clubhouse的一个频道,就会生产一个数据包并传输到声网的后台。这个数据包中包含每一个用户的ID以及访问房间ID的元数据。这些元数据使用未加密明码传输,这意味着任何第三方,只要获得网络权限,就可以调阅这些数据。这种情况下,任何监听着可以通过调查在同一频道的参与者,确认谁和谁在进行交流。

SIO深挖声网平台文档,发现声网可能有获取Clubhouse中原始音频文件的权限。除非使用端到端加密end-to-end encryption (E2EE) 技术,声网可以截取,破译以及储存这些数据。而现实情况是,Clubhouse使用端到端加密技术的可能性微乎其微。

附件中包含更多这些分析中的技术细节。

为什么我们关心Clubhouse使用声网的托管服务

声网在中美都有业务,所以他们需要遵守《中华人民共和国网络安全法》。根据他们提供给美国证券交易委员会的档案记录,声网公司承认,他们必须遵照中国的法律,为涉及国家安全和犯罪调查提供必要的辅助和支持。如果中国政府确认某条音频文件威胁国家安全,声网有法律义务帮助政府找到并储存这条音频。

根据前例,涉疆涉港,涉及八九政治风波的对话有可能被定性为违法犯罪行为。

声网声称,除去用于网络连接质量检测以及向客户收费,他们不会储存用户的音频和元数据。如果一切属实,中国政府无法在现有法律框架下,向声网索取那些从未被记录下的数据。可是,理论上来说,政府依然可以选择监听声网的网络并记录下所需要的数据。又或者,声网对数据处理的描述和实际操作不符(华为,一个被指责与中国军方有联系的大型通信软件公司,声明从未把数据提供给政府,即使很多西方专家对这个声明表示怀疑)。

此外,中国政府可能获取任何在中国大陆服务器上未经加密的数据。考虑到SIO观测到房间元数据被传送到我们认为位于中国境内的服务器,中国政府可能可以绕开声网的网络,并收集这些元数据。

总而言之,如果中国政府可以通过声网获取用户数据,位于大陆的Clubhouse用户可能会面临不必要的麻烦。但是,我们也需要指出,拥有潜在获取数据的途径不等同于实际获取数据。中国政府有着庞大而冗余的官僚,如同大洋彼岸的美国政府。政府内部很可能有不同声音以及组织之间的掣肘。

中国政府可以获取Clubhouse储存的用户音频文件吗?

简短的答案是,只要这些数据储存在美国,就不太可能。

Clubhouse的用户隐私权协议中指出,用户的音频将短暂储存下来用于信任和安全调查(例如恐怖主义威胁,仇恨言论,出售未成年人个人信息等)。如果没有提交信任和安全调查报告,Clubhouse声称这些音频数据将被删除。该协议未指定“临时”存储的持续时间。临时可能意味着几分钟或几年。Clubhouse的隐私政策未将声网Agora或任何其他中国公司列为数据二级处理者。

如果Clubhouse将音频存储在美国,则中国政府可以要求美国政府根据《中美互助法律援助协议》(MLAA)要求Clubhouse传输数据。但是,由于MLAA的规定允许该美国拒绝侵犯用户言论自由或人权的请求,例如涉及会所政治性言论的请求(六四风波,涉港涉疆等),该请求可能会失败。 )。 (由于美国联邦法律禁止此类披露,因此中国政府不能直接向Clubhouse索要音频剪辑。)

但是,如果App的创建者Alpha Exploration Co.在中国拥有可以访问数据的合作伙伴或子公司,则中国政府可以合法要求在中国存储的音频(或其他用户数据)。除声网Agora之外,没有已知证据表明Alpha Exploration Co.在中国有合作伙伴或在中国存储用户数据。

总而言之:假设App开发商在中国没有合作伙伴或没有在中国存储数据,那么中国政府可能无法使用法律程序来获取Clubhouse音频数据。根据Clubhouse的“临时”存储量,Clubhouse在任何情况下都可能没有数据可以通过合法程序移交给用户。但是,如果中国政府可以直接从Clubhouse在声网Agora上的后台获取音频,则它可能并不需要求助于国际法律渠道来查找数据。

中国大陆的用户有可能在Clubhouse“因言获罪”吗?

中国政府如果要惩罚在某些敏感话题聊天室中访问过或讲话过的Clubhouse用户,至少需要满足两个条件。

首先,中国政府需要知道哪些用户在哪些聊天室中。如上所述,它可以通过房间中存在的其他用户的报告或通过声网Agora从后端的报告来手动获取此信息。

如果手动收集数据,Clubhouse房间中的某人需要手动记录其他用户的个人资料。他们的公开个人资料有时会显示识别信息,例如照片,电话号码或微信帐户。 (电话号码和微信帐号是在中国的实名注册。可以通过面部识别算法来识别照片。)但是,大多数俱乐部会所的个人资料都不会显示识别信息。在这种情况下,政府将需要通过自己的监视机制或通过声网Agora访问标识信息。

中国的对内监视能力相当强大却不透明。中国政府很可能无需借助Clubhouse或Agora即可访问大陆用户的数据或元数据,如同爱德华·斯诺登(Edward Snowden)透露的美国政府窃听网络流量的方式。如上所述,中国政府可以轻松拦截用户设备发送的纯文本元数据,例如房间ID和用户ID。如果政府无法独立访问用户数据,则需要从声网Agora或Clubhouse请求和接收数据。如上所述,目前尚不清楚政府能否轻易做到这一点。 声网Agora声称不存储用户数据,而Clubhouse极不可能提供它。

其次,中国政府必须要有意愿去惩罚Clubhouse的用户。我们尚未可知这个意愿是否存在。研究表明,中国政府有时可以容忍公众批评,因为这种批评不会引起广泛的关注,也不会造成群体事件。在这些尺度上,Clubhouse是灰色地带。由于邀请制,并且只能在相对昂贵的iPhone上使用(不到所有中国智能手机用户的10%),因此该App可能没有在中国城市精英人群之外广泛使用。此外,每个Clubhouse聊天室最多可容纳五千个用户。即使绝对数量不小,但造成潜在群体事件的几率不大。从政府的角度来看,所有这些因素都可能减轻Clubhouse的“威胁性”。

另一方面事实证明,中国政府对通过线上平台协调线下群体活动十分敏感,如同短命的内涵段子App。Clubhouse是一个独特的空间:它承载着各种“网络聚会”(中国政府不喜欢),但它同时还是半私有的,且尚未在大众间广泛流行(这可能导致更大的政府容忍度)。无论如何,我们只能推测。

如果政府确实想处罚该App的国内用户,那么公众可能对此一无所知-甚至用户本身也不会知情。近年来,中国政府促进了针对黑名单上公民的秘密审查机制的发展,例如,在国内社交媒体 微信上提高用户的敏感度指数。被列入黑名单的用户可能会在向他们的朋友发送消息时,意识到该消息只会出现在他们的屏幕上,而不是他们的朋友的屏幕上。政府还可以采取威胁性措施,而不是直接惩罚行为,例如邀请用户“喝茶”。即使发生这种情况,我们也可能永远不知道Clubhouse的活动是否触发了喝茶邀请。

为何大陆官方要禁止这款App

为什么要完全禁止该应用程序?

多年来,中国政府封锁了不完全符合其宣扬的“网络主权”原则的网站或App,即每个国家都应为其领土内的网络活动设定界限的想法。中国政府通常对非法行为保持宽松的定义,从而在阻止有害内容方面拥有最大的灵活性。

政府很少解释为什么阻止单个App。就Clubhouse而言,政府很可能反对有关新疆,香港,天安门,审查制度等的政治话题。国有的民族主义报纸《环球时报》经常反映政府内部的强硬立场,发表社论时抱怨说,“Clubhouse里的政治讨论通常是单方面的”,而“支持政府的声音很容易被压制。”

为什么现在禁止它?

Clubhouse的大多数大陆用户以及外国记者和分析师都预计该App最终将被禁止。更紧迫的问题是何时。尽管有许多因素可能导致了该应用被禁的时机,以下是三种可能性。

首先,政府网络审查机构工作人员可能没有上班。加利福尼亚大学圣地亚哥分校政治学教授玛格丽特·罗伯茨(Margaret Roberts)进行的研究表明,审查制度在周末和国内法定假期有所下降。周末,检查员不工作时,Clubhouse迅速流行开来。这周同时也是春节假期,大部分公务员在家休息。

其次,中国政府可能希望收集有关其公民的舆情信息。学者们早就注意到“专制的困境”,即专制政府在收集准确的舆论衡信息的时候面临的挑战。因为公民害怕报复,所以他们有可能隐藏自己真实的想法。中国政府实际上有可能会重视Clubhouse之类的网络空间,以便通过这个简短的窗口了解其人民(主要是精英)的真实政治见解。

第三,禁止一个App可能需要很长时间。国家互联网信息办公室(CAC)是一个庞大而复杂的官僚机构,它负责通过国家防火墙(Great Firewall)禁止特定App。该禁令的决定可能被繁文缛节所拖延。国家防火墙本身也是一个庞大而复杂的系统。重整资源可能需要技术劳工。

这些问题的答案可能是所有这些之前的分析,也可能远离之前的分析。本文罗列的只是初步的分析。

附录:技术分析

根据声网Agora的文档,音频使用其实时通信(RTC)标准开发套件(SDK)通过声网Agora进行中继。可以将其想象为一个老式的电话运营商:要与其他人联系,运营商必须连接两个用户。在这种情况下,Clubhouse的App是每个用户的电话,而声网Agora是运营商。

img


Clubhouse application’s property list (.plist) file, bundled with the iOS application, contains its Agora application ID

当用户加入或在Clubhouse中创建聊天室时,该用户的应用通过安全HTTP(HTTPS)向声网Agora的基础架构发出请求。 (通过HTTP进行“请求”是访问网站的最常见方法;很可能您现在就是使用这个方法阅读到这篇文章的。)要发出请求,用户的手机联系Clubhouse的应用程序编程接口(API)。手机将请求 | [POST /api/create_channel]发送到Clubhouse的API。 API返回字段令牌和rtm_token,其中令牌是Agora RTC令牌,而rtm_token是RTM(实时消息)令牌。这些“令牌”然后用于建立通信路径,以确保用户之间的音频流量。

img


The request to create a channel on Clubhouse’s API returns the Agora tokens

然后,SIO观察到用户的手机通过UDP(一种更轻量级的传输机制)将数据包发送到名为“ qos-america.agoralab.co”的服务器。用户的数据包包含有关该频道的未加密元数据,例如用户是否已请求加入聊天室,用户的Clubhouse ID号以及是否已将自己静音。

img


A packet sent to Agora contains, in cleartext, the id of the channel and the user’s ID

用户从Clubhouse收到RTC令牌后,他们的手机将使用该令牌对Agora进行身份验证,以便可以通过相互认可的途径直接与Agora交流聊天室的加密音频。根据Agora的文档,Agora可以访问加密密钥。尽管文档中没有指定使用哪种加密方式,但它可能是基于UDP的对称加密。

Agora无法访问用户原始音频的唯一方法是,如果Clubhouse使用定制的加密方法进行端到端加密(E2EE)。尽管从理论上讲这是可行的,但这样做将需要Clubhouse向所有用户分发公钥。这还不存在。因此,极不可能有E2EE加密。

img


Sequence and content of UDP traffic from a device joining a Clubhouse room* Diagram by the Stanford Internet Observatory

SIO团队收到了Clubhouse的答复,并将其全部包括在内。我们尚未验证Clubhouse的任何声明。[译者注:以下翻译仅供参考,一切以Clubhouse官方英文回复为准]:

Clubhouse致力于数据保护和用户隐私。

我们将服务设计为一个世界各地的人们可以聚集在一起互相交谈,倾听和学习的地方。鉴于中国在数据隐私方面的良好记录,我们在Appstore上推出Clubhouse使其在除中国外的所有其他国家/地区均可使用时做出了艰难的决定。中国的一些人找到了下载该应用程序的解决方法,这意味着-直到该应用程序在本周早些时候被中国阻止为止,他们所参与的对话可以通过中国服务器传输。

在Stanford Internet Observatory的研究人员的帮助下,我们确定了一些可以进一步加强数据保护的领域。例如,对于我们流量的一小部分,包含用户ID的网络ping将被发送到全球服务器(其中可能包括中国的服务器),以确定到达客户端的最快路由。在接下来的72小时内,我们将推出更改以添加其他加密和块,以防止Clubhouse客户端将ping传输到中国服务器。我们还计划聘请外部数据安全公司来审查和验证这些更改。