互联网的刻耳柏洛斯:GFW的DNS审查系统


https://yangxiamao.github.io/2021/09/30/%E4%BA%92%E8%81%94%E7%BD%91%E7%9A%84%E5%88%BB%E8%80%B3%E6%9F%8F%E6%B4%9B%E6%96%AF-GFW%E7%9A%84DNS%E5%AE%A1%E6%9F%A5%E7%B3%BB%E7%BB%9F/

刻耳柏洛斯是希腊神话中看守冥界入口的恶犬,它允许每一个死者的灵魂进入冥界,但不让任何人出去,同时也不允许活人进入。

纽约大学石溪分校的 Nguyen Phong Hoang 和多伦多大学的 Arian Akhavan Niaki 等人,建立了一个名为 GFWatch 的网络平台,对中国网络长城(俗称 GFW)的 DNS 审查系统进行了探测和实验,最后写出了一篇论文发表在历史悠久的 USENIX(高等计算系统协会)上。文章名为《How Great is the Great Firewall ? Measuring China’s DNS Censorship》,您可通过链接 https://www.usenix.org/system/files/sec21-hoang.pdf 获得论文原文。

在 GFWatch 工作的九个月时间里,它测试了5.34 亿个域名。论文展示了一组触目惊心的数据:至少有 31.1 万个域名被 GFW 的 DNS 过滤系统干扰。并且 GFW 还主动出击,在世界范围内污染了公共 DNS 解析服务(pub- lic DNS resolvers)中至少 7.7 万个域名的数据,其中包括谷歌和 Cloudflare 的 DNS resolvers。

他们在论文中说:

“These techniques will not only help public DNS resolvers and other DNS-related services to sanitize tainted records , but can also assist future development of circumvention tools tobypass the GFW’s DNS censorship .”

他们的研究不仅可以帮助清除 DNS resolver 和其他 DNS 相关服务中污染了的 DNS 数据,还可以帮助今后的开发人员去开发绕过 GFW 的 DNS 审查系统的工具。

How GFW fuck DNS

DNS (Domain Name System)的作用是根据域名查出IP地址。它是一个将域名和IP地址相互映射的分布式数据库,你可以把它想象成一本巨大的电话本。

举一个例子,如果我们要访问域名 www.baidu.com ,首先要通过 DNS 查出它的IP地址 183.232.231.172。下图是 DNS 查询的一个简单示意图。

论文中提到,由于 GFW 是一个通路的(on-path)/人在侧面(man-on- the-side)的系统 ,所以它没办法通过修改或者简单丢弃互联网上传输的那些被封锁的域名的 DNS 查询响应。但是由于 DNS 使用无状态、未加密的 UDP 协议进行传输,所以 GFW 可以通过可以实时监测互联网上的流量,当在用户的 DNS 查询中检测到受审查的内容时,注入错误的响应。

由于 GFW 的相关设备通常离客户端更近(就物理/网络距离而言),所以被检测的响应通常会比合法的响应更早到达,从而达到让用户无法获得正确的域名的 DNS 的目的。

利器:观测 GFW 的平台 GFWatch

当你凝视深渊时,深渊也在凝视着你

GFWatch 的设计要求中,有一点就是要可以探测到尽可能多的被 GFW 阻断的网站。GFWatch 从 超过 1500 个TLD zone file 处获得实时更新的域名列表,平均每天会对 4.11 亿个网站进行监测,截至 2020 年总共探测了5.34 亿个网站。发现至少有 31.1 万个域名被 GFW 的 DNS 过滤系统干扰。

GFWatch 同时被设计以可以实行长期探测。一旦它探测到某个网站被封锁,GFWatch就会持续对这个网站进行观测,观察这个网站是否会在某个时间点被 GFW 解封。

同时,GFWatch 还被设计来收集统计 GFW 返回的虚假 IP 地址。

接下来我们来看看 GFWatch 的实验和探测手段。

GFWatch 的主要探测器位于没有 DNS 审查制度的美国,从这台机器发送 DNS 查询消息前往位于中国的两台主机。但是位于中国的那两台主机并没有 DNS 解析能力,因此,主探测器的任何 DNS 响应都应该是来自 GFW。

由于 GFWatch 被设计为使用 UDP 进行探测,而UDP是一个无状态和不可靠的协议,数据包可能会由于不受控制的因素(例如,网络拥堵)而丢失。为了尽量减少这些因素对数据收集的影响,GFWatch 每天至少对每个域名进行三次测试。

很妙的一个实验方法!一个优秀的猎手往往以猎物的姿态存在。虽然你耗费了电费和带宽,但是你可是钓上了 GFW 这条大鱼啊!

中国的两台主机位于两个不同的自治系统(AS)中。但是从探测结果来看,发往这两台中国主机的 DNS 查询所接受的封锁政策是相同的,故研究人员猜测 GFW 应该是采用中心化政策(centralized blocking policy)的一个系统。

在位探测仪完成每个探测批次后,被检测到的受审查域名被转移到中国主机上,

接着,研究人员又控制位于中国境内的主机向位于美国的主机发送网站的 DNS 查询信息。研究人员观察到从美国发往中国的 DNS 查询时会被审查的域名在中国发往美国时同样会被审查。

通过两个探测路径探测到了相同的被审查的域名名单。

截至论文发表时,GFWatch 仍在运行,每天都在收集数据。

从 GFW 封锁网络清单中反推规则

无论多么天衣无缝的犯罪,只要是人作的,就没有解不开的道理。

如果 subdomain.example.com 和 example.com 的所有子域都被封锁,研究人员就将 example.com 视为一个被封锁的域名(blocked domain)。最短的审查域名便称为 “基础域名”(base domain)。通过对 GFWatch 发现的 31.1 万个被审查的域名进行分析,研究人员发现了13.87 万个基础域名。截至 2020 年 12 月 31 日,仍存在 12.6 万个被封禁的基础域名。

但是研究人员同时注意到,当一个子域名被封锁时,基础域名可能不会被封锁。例如,cs.colorado.edu 被封锁了,而 colorado.edu 没有被封锁,这说明 GFW 没有简单地采用一刀切的封锁措施。于是研究人员进一步的进行了分类,对于一个给定的域,研究人员测试了每个审查的域和随机字符串的以下排列组合。

  • Rule 0 censored_domain
  • Rule 1 censored_domain{.rnd_str}
  • Rule 2 censored_domain{rnd_str}
  • Rule 3 {rnd_str.}censored_domain
  • Rule 4 {rnd_str}censored_domain
  • Rule 5 {rnd_str.}censored_domain{.rnd_str}
  • Rule 6 {rnd_str.}censored_domain{rnd_str}
  • Rule 7 {rnd_str}censored_domain{.rnd_str}
  • Rule 8 {rnd_str}censored_domain{rnd_str}

在 138.7 万个基础域名中,有 11.8 万个域名根据规则 0 进行是独立审查的。换句话说,这些域名是被审查的,但在与随机字符串连接时不会触发GFW的DNS审查。

在这些规则中,只有规则 1 和 3 是基础域名的子域名的正确存在形式。研究人员把规则 1、3 以外的规则与较短的域名字符串组合在一起的被审查的域名称为被过度封锁(overblocked)的域名。

按照封锁严重程度的升序,研究人员发现在规则2、3、4、6和8下,分别有4、11.38 万、1.09 万、1400 个和 696 个不同的基础域名被封锁。

对 GFW 过度封锁的研究

有超过 1.3 万个基础域名被过度封锁。在发现的 33.1 万个被审查的域名中,有 41000 个域名是过度封锁的。

论文中举了一个例子:GFW 将 torproject.org 进行了严格审查,对其进行了过度封锁(overblocked)。包括 mentorproject.org 在内,任何包含了 torproject.org 字段的网站都被 GFW 封锁,令人啼笑皆非。(Tor 是一个旨在实现匿名通信的自由软件(free software),Tor 用户的互联网活动相对较难追踪。)

919.com、jetos.com 和 33a.com 这三个域名共造成15000个不相关的域名被过度封锁,如果有朋友打算购买域名,请注意避开包含有相关子字符串的域名。以避免被 GFW 不明不白的封锁了。

对被封域名种类的研究

研究人员使用了 FortiGuard 提供的服务,进行域名分类。

统计发现, “商业”(business)、”色情 “(pornography)和 “信息技术 “(imformation technology)这三种网站是 GFW 封锁的主要类型(除了未分类的网站外)。

另外一项没有没有统计子域名的研究则发现,”代理 “(proxy avoidance)和 “个人网站和博客 “(personal websites and blogs)是被封锁最多的网站类型。

虽然 “教育 “不是被审查的首要类别,但研究人员同时发现了许多与教育有关的域名被封锁,包括 mit.edu、umich.edu、gwu.edu、armstrong.edu、brookings.edu、citizenlab.ca、feitian.edu、languagelog.ldc.upenn.edu、pori.hk、soas.ac.uk、 scratch.mit.edu、cs.colorado.edu……

这是 GFW 滥封网站的又一个证据。

covid-19、自动化工具与雇员

GFWatch 检测到大量与 COVID- 19 有关的域名被 GFW 通过 DNS 篡改进行审查,包括 covid19classaction.it、covid19song.info、covidcon.org、ccpcoronavirus.com、covidhaber.net以及covid-19truth.info 等网站。

虽然大多数 COVID-19 相关的网站在出现后很快被 GFW 发现并封锁,但研究人员发现 GFW 无法做到实时封禁相关网站。

ccpcoronavirus.com 和 covidhaber.net 于 2020 年 4 月首次出现在 GFWatch 的测试列表上,但分别直到 7 月和 9 月才被 GFW 封杀。同样的,covid-19truth.info 在 2020 年 9 月出现在研究人员的数据集中,但直到 10 月才被审查。

GFW 审查不同域名所需时间的巨大差异表明,封锁网站名单很可能是由自动工具和人工共同完成的。

伪造的 IP 与被蒙蔽的人们

真理是永远蒙蔽不了的。

了解 GFW 伪造的 IP 和它们被注入的模式(如果有的话)是至关重要的。

研究人员分析了 GFWatch 收集的 IP,以研究是否存在任何特定的注入模式,在此基础上,我们可以制定策略来有效地检测和绕过 GFW 的 DNS 审查制度。

伪造的 IP 的数量随时间流逝增加

研究人员从 GFWatch 捕获的所有中毒的 DNS 响应中发现了 1781 和 1799 个伪造的 IPv4 和 IPv6 地址。

研究人员发现所有被 GFW 注入的 IPv6 地址都是假的,因此,研究人员把分析的重点放在伪造的IPv4地址上。

从 2020 年 5 月份开始,GFWatch 监测到 GFW 使用的伪造 IP 数量开始增多,在2020年的最后四个月,伪造的 IP 数量增长到 1700 个左右。

有迹可循:伪造 IP 的注入模式

通过分析每个伪造 IP 地址的注入频率,我们发现并不是所有的伪造 IP 都有同样的机会被注入到被审查的回应中,也就是说,他们的注入模式并不是完全随机的。

尽管 GFW 伪造的 IP 数量迅速增加,但最初的 200 个伪造的 IP 仍然对 99% 的 DNS 注入负责。从 5 月到 8 月发现的新的的 1300 个伪造 IP 位于长尾部分,研究人员只在 1% 的 GFW 伪造的 DNS 响应中发现了它们。

根据这一试验结果,我们或许获得了些许反制 GFW DNS 污染的灵感。

围城:双向拦截

城外的人想进去,城里的人想出来。

因为有时 DNS 查询的信息不可避免的会经过中国网络,触发 GFW 的双向 DNS 过滤行为,故先前研究人员曾认为 这是中国境外的公共 DNS resolvers 缓存被污染的原因。

经过进一步的研究,研究人员发现许多域名的权威名称服务器(authoritative name servers)位于中国境内是另一个主要原因,这些中毒的 DNS 缓存借此玷污了世界各地的许多公共 DNS resolvers。

GFWatch 发现的被审查的域名和 GFW 伪造的 IP 的数据集有助于检测和净化公共 DNS resolvers 缓存中的中毒资源记录。

GFW 对中国域名的地理封锁

2020 年 8 月 8 日,GFWatch 检测到 GFW 一个奇怪的封锁行为:GFW 对中国政府网站进行了审查阻断。

www.beian.gov.cn 名为“全国互联网安全管理服务平台”,由中国工业和信息化部管理。这个域名有两个权威的名称服务器,dns7.hichina.com 和 dns8.hichina.com,它们被托管在 16 个不同的中国境内的 IP 地址上。一旦在中国境外发出向针对该网站的 DNS 查询,GFW 便会对查询进行污染与注入。但位于中国境内的主机仍然可以正常访问这个网站。

因此,这是一个明显的地理封锁案例。GFW 不仅仅封堵了主机从中国向境外被审核网站的访问,也污染了境外主机向中国境内部分网站访问时的 DNS 查询。

从中国境外访问 www.beian.gov.cn 会间歇性地成功,因为 GFW 的 DNS 注入有时会比正确的响应更晚到达使用终端。

GFW 大炮

研究人员提到了 GFW 发动资源耗尽攻击(resource exhaustion attacks)的可能性。 一旦 GFW 将 DNS 查询的结果大量导向某个 IP 地址,受影响的组织将在服务器上付出不可忽视的开销。

GFW 甚至可以针对一个 DNS 查询发出多达三个伪造响应。从GFW的角度来看,注入多个虚假响应不仅增加了成功污染查询结果的可能性,也使检测和规避 DNS 污染的成本增高,难度增大。

如烛者,思至则见,不思不见

你就是这道黑暗中强烈的光束,从属于你的夜晚中,照亮了他们曾经看不见的白天。

一旦 GFWatch 检测到有域名被 GFW 封锁,研究人员就向公共的 DNS resovlers 查询它们。最终,研究人员发现了公共 DNS resolvers 的缓存中,有 7.7 万个被 GFW 审查的域名被污染。下图显示了数据被污染得最多的前十个公共 DNS resolvers。

这一发现显示了 GFW 在世界范围内的广泛影响,使得公共的 DNS resolvers 的操作者必须有一个有效的机制来防止这些中毒的资源记录污染他们的缓存,以保证他们的DNS服务质量。

现在,研究人员将展示如何根据前文展示的 GFW 的特点和 GFWatch 获得的浩如烟海的数据制定策略,以有效和高效地规避GFW的DNS审查制度。

当收到一个以上的 IPv6 回应时,客户端可以根据 GFW 伪造的 IPV6 的显著特点排除掉被污染的 IP 地址。对于 IPv4 答案,客户端可以根据前文中发现的 GFW 伪造 IP 的注入模式和伪造的 IPv4 特点来检查它们。

从下图中,我们可以看到 99% 的被 GFW 污染的 DNS 响应比正确的响应提前 364ms 到达我们的机器(这个延迟时间根据终端和 GFW 之间的相对距离的不同而可能会有所不同)。换句话说,在查询一个受审查的域名,收到 DNS 响应时,客户端最多应该多等 364ms,以等待合法域名的到来。

愿我们能够在没有黑暗的地方相遇

人类收到火的礼物之后,国王会用它征服世界,厨师会用它喂养世界,工程师会用它移动世界。小丑只会用它玩杂耍。

研究团队开发了 GFWatch,监测并统计了 GFW 基于 DNS 审查的封锁行为。然而,DNS 审查并不是 GFW 使用的唯一的封锁技术,还有其他许许多多的技术被采用来防止信息在互联网间自由的流通。例如,基于SNI的封锁、基于关键字的过滤、针对特定 IP 的封锁、使用深度包监测识别异常流量……

今后我也会继续关注这方面的内容,但是在顺利前去留学之前(现大三在读),我会尽可能的专注于学习。同时,由于撰写这篇文章时时间仓促,也因为我本人学术水平有限,如有错讹,欢迎您和我联系。

您可以通过以下方式找到我:

同时感谢群友、推友们在我撰写文章时的鼓励与交流,没有你们,就没有这篇文章。

本篇文章以 MIT 协议开源,欢迎任何人转载、引用。祝您生活愉快、学业、事业顺利。

有效避免 GFW 的 DNS poisoning


https://weidi.medium.com/%E6%9C%89%E6%95%88%E9%81%BF%E5%85%8D-gfw-%E7%9A%84-dns-poisoning-351f3d0b3102 

在這篇 Tweet 看到有趣的 Paper How Great is the Great Firewall? Measuring China’s DNS Censorship ,透過在美國及中國的實驗找出 censored domains,進而實作出可以有效避免 GFW DNS poisoning 的方式。

GFW 如何運作?

GFW 是 on-path injector,並且不會丟棄或修改由 resolver 或是 authoritative name server 的回覆。因此只有在路徑上會經過 GFW 時才會觀察到此行為,例如日本客戶端透過中國 resolver 查詢 www.google.com 

// 中國聯通的 DNS resolver 
// 解析 Google 網站回傳的 IP 地址卻指向 Microsoft 的網站
$ dig www.google.com @202.102.224.68 +short 173.244.217.42

如何知道一個域名可能被污染?

比較 client — resolver — authoritative name server 路徑經過與不經過 GFW 的回覆,例如:

// suspicious$ dig mentorproject.org @202.102.224.68 +short
203.161.230.171
// looks fine$ dig mentorproject.org @1.1.1.1 +short
23.236.62.147
$ dig mentorproject.org @8.8.8.8 +short
23.236.62.147
$ dig mentorproject.org @168.95.1.1 +short
23.236.62.147

所以,如何預防?

因為 GFW 不會丟棄或修改由 resolver 或是 authoritative name server 的回覆,我們只要 讓客戶端等待足夠長的時間 ,確保所有的回覆都收到再採用即可。

實驗時間

中國聯通跟 Cloudflare resolver 給了不同的答案:

$ dig mentorproject.org @202.102.224.68 +short
64.33.88.161
$ dig mentorproject.org @1.1.1.1 +short
23.236.62.147
$ sudo tshark -i any -f 'port 53' -n// 中國聯通  1 0.000000000 172.31.37.101 -> 202.102.224.68 DNS 90 Standard query 0x89c6  A mentorproject.org
2 0.154465529 202.102.224.68 -> 172.31.37.101 DNS 95 Standard query response 0x89c6 A 64.33.88.161
3 0.154511590 202.102.224.68 -> 172.31.37.101 DNS 95 Standard query response 0x89c6 A 203.161.230.171
// Cloudflare 4 12.710885026 172.31.37.101 -> 1.1.1.1 DNS 90 Standard query 0x9e3d A mentorproject.org
5 12.886210394 1.1.1.1 -> 172.31.37.101 DNS 106 Standard query response 0x9e3d A 23.236.62.147

评估苹果的iCloud Private Relay的抗封锁能力

https://gfw.report/blog/private_relay_censorship/zh/

苹果公司于2021年9月20日,发布了一项名为iCloud Private Relay (archive)的新服务,包含在iOS 15, iPadOS 15和macOS Monterey中。

尽管苹果公司没有将它的翻墙功能作为卖点,在这篇报告中,我们试图理解iCloud Private Relay的翻墙价值。首先,基于我们的测量和对苹果文档的理解,我们介绍Private Relay的工作原理。接着我们通过在中国进行的测量实验实证性地评估Private Relay的抗封锁能力。截止2021年9月23日,我们尚未发现Private Relay被防火长城审查的迹象。我们还将讨论Private Relay面对常见的审查方式(如DNS劫持,SNI过滤,IP封锁,主动探测,和自我审查)时的抗封锁能力。最后,我们将提出一些关于Private Relay的重要但还未解决的问题。

我们无意将这篇报告作得面面俱到。而仅想抛砖引玉地介绍我们的测量方法、观察及想法。我们鼓励更多的互联网审查爱好者做更深入的研究。

主要发现

  • 截止2021年9月23日,我们尚未发现Private Relay被防火长城审查的迹象
  • Private Relay可以很容易地被常见的审查方式封锁,包括DNS劫持,SNI过滤,IP封锁,主动探测,和自我审查。主动探测Priavte Relay服务器也许也是可行的。
  • Private Relay这项服务已被苹果在包括中国在内的许多国家和地区自我审查。但用户报告只需使用相应的国外iCloud账户即可绕过禁用。

介绍

以下介绍基于我们的测量和对苹果的文档的理解。简而言之,Private Relay采用两跳结构,由一个入口节点和一个出口节点组成:


  ------------
 | DNS 服务器  |
  ------------
       ^
       |
    A mask.icloud.com?
HTTPS mask.icloud.com?
       |
       0
       |
    ------           -------------           ------------           ------
   |客户端 | <==1==> |   入口节点   | <==2==> |   出口节点   | <==3==> |目标网站|
    ------           -------------           ------------           ------
  • 第0步: 客户端发送两个明文的DNS请求到DNS服务器。请求的类型为AHTTPS,请求的域名为mask.icloud.commask-api.icloud.com。目的是得到入口节点的IP地址。
  • 第1步: 客户端选取其中一个DNS服务器返回的IP地址,并发送QUIC初始包到入口节点的443端口。
  • 第2步: 根据文档,“出口节点由第三方运行,会生成一个临时IP地址,解密得到请求的目标网站地址,并与网站进行连接”。
  • 第3步: 出口节点和目标网站间的流量与,不启用Piravte Relay时,客户端和目标网站间的流量完全相同。

捕获iPhone与入口节点间的流量

一种自然想到的捕获和分析移动设备流量的方式是,在手机上建立起工作在网络层的VPN,把所有传输层及更上层的流量都转发到一个(本地的)服务器上,再在服务器上运行tcpdump或者wireshark。然而我们发现在VPN打开的状态下,iCloud Private Relay是无法启用的。

作为替代方式,我们在电脑上建立起无线热点,并让iPhone连上去。我们这样就可以在电脑上捕获并分析流量了。我们用了以下脚本搭建无线热点,脚本借用了这个教程里的知识。

#!/bin/bash

set -x
set -e

## Source: https://computingforgeeks.com/create-wi-fi-hotspot-on-ubuntu-debian-fedora-centos-arch/

## 记得将IFNAME替换成你的Wi-Fi network interface的名字: `ip link show`
IFNAME="wlp4s0"
CON_NAME="MyHotSpot"
PASSWORD="77fdda98a6feaf6cc9"

nmcli con add type wifi ifname "$IFNAME" con-name "$CON_NAME" autoconnect yes ssid "$CON_NAME"

nmcli con modify "$CON_NAME" 802-11-wireless.mode ap 802-11-wireless.band bg ipv4.method shared

nmcli con modify "$CON_NAME" wifi-sec.key-mgmt wpa-psk
nmcli con modify myhotspot wifi-sec.psk "$PASSWORD"

nmcli connection show "$CON_NAME"

nmcli con up "$CON_NAME"

nmcli connection show "$CON_NAME"

在观察DNS和初始的QUIC流量时,我们发现以下过虑条件很好用:

quic.long.packet_type == 0 or udp.port == 53

测量当前的审查并评估潜在的审查成本

在这一节中,我们将测量中国当前对于Pirvate Relay的审查,并讨论审查者采用常用审查方法检测并封锁Private Relay的成本。

DNS劫持

前面提到客户端会通过DNS查询得到一个入口节点的IP地址,然后用QUIC协议与其建立连接。因为这些DNS请求(很有可能被故意设计成)是明文的,因此容易受到DNS劫持攻击。事实上,苹果公司自己就建议使用DNS劫持来“最快速和稳定”地封锁Private Relay:

The fastest and most reliable way to alert users is to return a negative answer from your network’s DNS resolver, preventing DNS resolution for the following hostnames used by Private Relay traffic. Avoid causing DNS resolution timeouts or silently dropping IP packets sent to the Private Relay server, as this can lead to delays on client devices.

mask.icloud.com

mask-h2.icloud.com

我们观察到客户端有两种获得入口节点地址的方式。第一种方式是:

  1. 客户端首先发送两个DNS查询,查询类型为AHTTPS,查询的域名为mask.icloud.com。DNS应答包含一个CNAME答案mask.apple-dns.net,以及多个A答案。
  2. 客户端选择DNS应答包中的第一个答案,即那个CNAME答案。客户端因此需要再次发送两个DNS查询,查询类型还是AHTTPS,查询的域名为mask.apple-dns.net
  3. 客户端接着还会选取DNS应答包中的第一个答案,这次是A答案。

第二种方式是:

  1. 客户端首先发送两个DNS请求,查询类型为AHTTPS,查询的域名为mask-api.icloud.com。DNS应答包含一个CNAME答案mask-api.fe.apple-dns.net,以及多个A答案。
  2. 客户端选择DNS应答包中的第一个答案,即那个CNAME答案。客户端因此需要再次发送两个DNS查询,查询类型还是AHTTPS,查询的域名为mask-api.fe.apple-dns.net
  3. 客户端接着还会选取DNS应答包中的第一个答案,这次是A答案。

我们没有观察到客户端会查询文档中记录的mask-h2.icloud.com。这篇报告也提到没有观察到包含mask-h2.icloud.com的DNS查询。

测量中国当下的DNS审查

虽然污染上述提到的域名对GFW来说小菜一碟,但是我们还并未观察到GFW真的采取审查。具体而言,我们从中国发送上述DNS请求到国外,也从国外发送请求回中国,来让GFW的设备看到我们的请求。你即使不在中国,也同样可以利用GFW不区分DNS来源于国内或国外的特性,来测量DNS污染。需要注意的是,dig命令尚不支持发送HTTPS类型的DNS请求。如果使用dig @1.1.1.1 mask.icloud.com -t HTTPS +timeout=2这样的请求,它会自动回落到发送A类型请求。因为回落警告不足够明显,大家要当心回落带来的测量失误。

我们因此在从国外发DNS请求往国内时,使用了以下脚本,调用Scapy发送DNS请求。这里我们用到的104.193.82.0是一个中国的IP地址,而且这个中国的IP地址没有运行DNS服务,这样如果我们收到了任何DNS答复,那么一定是GFW或其他中间人伪造的。我们因此也就可以判断GFW是否审查了相应的域名。

#!/usr/bin/env python3

# 这个脚本只负责发送DNS请求,不负责接收DNS应答。
# 如果想观察DNS应答,请使用tcpdump或者wireshark。比如:
# sudo tcpdump host 104.193.82.0

from scapy.all import *

# https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-07.html#name-the-svcb-record-type
TYPE_HTTPS=65

CHINESE_IP="104.193.82.0"

for qname in ["mask.icloud.com",
              "mask-api.icloud.com",
              "mask.apple-dns.net",
              "mask-api.fe.apple-dns.net",
              "mask-h2.icloud.com"]:
    for qtype in [TYPE_HTTPS, "A", "AAAA"]:
        send(IP(dst=CHINESE_IP)/UDP(dport=53)/DNS(rd=1, qd=DNSQR(qname=qname, qtype=qtype)))

SNI过滤

正如这个答案所介绍的,虽然QUIC中的Clienthello消息是加密的,但密钥是由固定的salt和明文的Destination Connection ID导出的。QUIC的初始包因此也就可以被很容易的解密。事实上,新版的Wireshark就可以自动地解密客户端发出的QUIC初始包。

审查者也因此可以加密QUIC初始包并检查其中的SNI值是否为mask.icloud.com

测量当下中国的(QUIC-)SNI审查

我们测试的方法是抓取客户端发送的初始包,然后在中国的服务器上重放。我们观察到服务器会回以QUIC握手包。我们还没有观察到审查者阻断这一过程。

举例来讲我们首先将以下十六进制流存入名为quic.hex的文件:

c80000000108bec8eac6d55fe88a08e87fe5dfa21d247700452c6a2a855275bb191ffe213c2ad1e07467f9ed24956172c4bee69e8446049a94fbae38973cf11ce80cc1379237e4a0f610ae2408ac096635b3978dcf21b4c81d96a2e53d9a9b04dc234341869f7ea85dc99e2ea028827257c4b6993a29ae07e9368c22426d1780abcf8c4b5ab8b2e3ba4de878306ecf4a4e5851c2168b8412f9a55fa5971520914f13c4a86106161e19bfa1eff9c08a9b566e1656ebceeb7184d60a0328203e5e66fc16ad8452343dee5e2ad22ba0ef80b978ba62c64ac75826b79d119c5a7bf9859655d79116e3f4069e87269bab7f9d0373d8e98e4c4891eaf621ce073c61f59eeddd828c96d785ff3155083f5ac93263e5496a6a38a2a2e0bbf64041e76a500bf4748143f2b8705c3732dc12b218f428eeadd02c50e71c5ffaa1ca14c483ac44c75d10e98d38ddaa38f38c0ba7af20108967541586c51bccd2765781b123b4a91fed0f32f0b11bfc4ff5beaccb023f7d977787a0d09942f5159da772b9ca5a7c512a8644bb399858cc6ee2a5d5c099be6780a619cbadc6407db320d34179bf1ff94401ef0e134d0d8ae705a468b5dcd7b9c078e72ddba146e947dca7d4968b3fc892e425ef60bec05df120b20f26f340ed134b064b4fddd194fee666ff49c943b82f812c6f57daaa70ef5aa7b511e8d9501a447783a4e7eee709499161c4055941d516f16bc4ed114d90f6d49c1a297484749fa99f84eb309c2743018eeebb71c6050061e4899b94ecc746fb98174ce383a9d250f61d3aca4db9249122763ca03c41a67b616e722f5171e34a610aeb9cfb6c74f8bdd549d1b0fbd4a766dd66dc355de7f55d55e029d495687c149d9bac0eba89276a0c8048a97545c08597ea836917ceaebe2e334d9376f3c3dc29ee6df84508558d2c77a1139907aba7735945846e3a8c4675845e01c7e2cb1370b31221f95e1bd0c8e5ecc9e86bf5658859379e3c752e34d6bf9e0e9481cf9ed5df79b9c756cb904603eaab2478b6aaa5740b28213f2716b2b4769e21d9c7e2d62e9708de9644a3de048745f079717e0a565475d0684be9cb13c261f55832953c37078cde29894b2176eab5157e4262dbba7919ef2c66d0cf86d7de93059e9f013e2e82544dc803dea878e184d248065454c65c26d8c67b7778e229390de7560815e6cdc53cce1fb11d62d9b0ecea890b4310ffcf7cd544ca8d6a1b9eed7b92a93fd6c00d0a2338f66ad77c9220c69437b3651b18899c68a8e59f12dc2f014d70a6ca5b4aa419516fde01079a1f76c3198db4f6229641e5e89b1b6aa9797c27b55f439e98858f9d3eef1ffff6f5e52e9e94468d21e8ab965abb864836be07016fdbb63a24e954b863a98d590033bd163df6a7740d256a0bbaa910e45a8f40877b6b84fd2d8f57604d236e4351bd228dc707fe3538440b2796dbab58183f306912c6104d13ea96c649fd338994b4a2d5ecbfdd66b69b5245763371cc38c92774723f546a27519db4660f5dc6312f5f56edad2dcb77bd3034c8a4a084ee7e57016fea8a5fcb114ee5ae97d55b177dd8b1ccd0508fb6baee6244ccedf2705ba35a760b944acb4b3e0394b5add44e851d18e0400d99b4910cd4cb63311727f4a98289ce4ee960c506b72243fde14cf5d3185cc4b598f080faf9ebc75847dc7126bb90c47368c5408898e7bdaf9cde4f04299043600dcdf850c306c737d4be37c316eed63718804e9972f6c95d79771ada173293b06037f1282f4e79f8116e3d4c5fed2ec6db335faf2b0481b3aa3a0192f9ff3fea35ae1bafe71bbcd07a301fe11638a180b6b202c29dea331ac6a2527587a82175cd7b96033b165b88580e83df7759ebe6586d68d4efe6028403d5d0d700e967ca4908bbd8e4

我们再将其发送到入口节点,并得到了回应:

xxd -r -p quic.hex | nc -u mask.icloud.com 443 -v

注意从生成这个十六进制荷载的大约两天后,发送它已经不能再能得到入口节点的回应了。如果重放刚生成的初始包,应该还可以触发入口节点的回应。

(Quic-)TLS指纹过滤

如上所述,QUIC初始包可以被很容易的解密得到ClientHello。这就给了审查者采用基于TLS指纹的审查的可乘之机。

我们对Private Relay的TLS指纹的观察于这篇报告基本一致:

The connection to the relay uses QUIC to port 443/UDP and TLS 1.3. The clienthello includes the server name extension and the server name “mask.icloud.com.” Only 3 cipher suites are offered (TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256). The server ends up selecting the AES128 suite. Application Layer Protocol Negotiation (ALPN) is also used, with unsurprisingly HTTP/3 being the only option.

除了引文中提到的3种密码套件外,我们还观察到了第四种Grease ciphersuit (0x2a2a)。

作为旁注,我们还观察到了ClientHello中包含了两个GREASE extensions:0xAAAA0X3A3A。他们不太可能是被用于验证相关的目的(如果真的是被用作验证目的,那就是很不服合标准的做法)。GREASE extensions其实并不罕见;浏览器也会发送它们。正如这篇文档所解释的,它们被用来“保证TLS实现可以正确的处理不认识的值”。换而言之,因为GREASE的存在,TLS实现就不能假设只会收到和处理某些特定的值了。

我们很好奇tlsfingerprint.io是否能告诉我们这些(或者任何)(QUIC) ClientHello的指纹有多特殊?(@sergeyfrolov, @ewust)

主动探测入口节点

我们发现在大约两天之内重放QUIC初始包到入口节点,入口节点都会回以发送握手包。我们还尝试使用quic-gocurl --http3对入口节点进行典型的Quic握手,SNI为mask.apple.com。但入口节点并不回应。我们怀疑这与合法客户端发送的ClientHello的ALPN extension有关。但入口节点是否回应也可能还与其他的验证信息有关。

封锁入口节点的IP地址

如前所述,从中国发送的QUIC握手包可以得到入口节点的回应。这说明,至少我们测量的IP地址还没有被封锁。

但是仍有很多方法封锁入口节点的IP地址,比如审查者可以:

  1. 封锁所有解析mask.icloud.commask-api.icloud.commask-h2.icloud.com时返回的IP地址。
  2. 观察QUIC链接中SNI为mask.apple.com的服务器IP地址,然后用主动探测确认入口节点。确认后封锁相应IP地址。

基于出口节点的IP地址歧视用户

如Tor出口节点一样,苹果也有一个实时更新的出口节点IP段列表 (存档)。这个列表可以方便网站基于出口节点的IP地址来歧视Private Relay用户,正如Tor用户所遭受的歧视一样

还未解决的问题

苹果是如何实现自我审查的

除了上述的种种审查方式外,苹果公司还通过自我审查的方式阻止在本就身处受到严格审查地区的用户使用Private Relay。因此了解并绕过苹果公司的自我审查尤为重要。

具体来讲,苹果公司承认

Private Relay isn’t available in all countries and regions. If you travel somewhere Private Relay isn’t available, it will automatically turn off and will turn on again when you re-enter a country or region that supports it. Private Relay will notify you when it’s unavailable and when it’s active again.

根据相关的新闻报道, 苹果在以下地区禁用了Private Relay:中国、白俄罗斯、哥伦比亚、埃及、哈萨克斯坦、沙特阿拉伯、南非、土库曼斯坦、乌干达、菲律宾和俄罗斯。

苹果自我审查的实现机制还有待研究。我们的测试显示,入口节点似乎并不基于用户IP地址来拒绝服务。但是我们仍不清楚苹果公司是如何判断用户是否身处被禁止使用Private Relay的国家。

一项报告(存档)声称苹果公司是根据用户访问特定的一组苹果服务器时的IP地址,来判断用户位置的;使用境外代理访问这组苹果服务器即可激活Private Relay功能。

而另一个用户报告(存档)只需将iCloud的地区设置为非禁用地区,就可以启用Private Relay了。但同一个帖子中的另一用户声称使用了非禁用地区iCloud但仍然无法开启Private Relay。我们欢迎中国的用户分享你的经验。

另外作为一点背景介绍,对于中国的iOS翻墙用户,拥有一个非中国iCloud账户并不罕见。这是由中国的App Store对翻墙软件的严格审查导致的。

苹果是如何验证Private Relay用户的?

苹果公司声称

Private Relay validates that the client connecting is an iPhone, iPad, or Mac, so you can be assured that connections are coming from an Apple device.

All connections that use Private Relay validate that the client is an iPhone, iPad, or Mac and that the customer has a valid iCloud+ subscription. Private Relay enforces several anti-abuse and anti-fraud techniques, such as single-use authentication tokens and rate-limiting.

我们好奇苹果是如何验证Private Relay用户的。

苹果的Private Relay是如何加密解密的?

前面我们介绍Private Relay采用两跳结构。除此之外我们并不了解更多的技术细节。比如说,这两跳是否采用了如onion-routing的结构?Amir Houmansadr表达了对Private Relay协议不透明的关切。Private Relay的协议和工作原理因此有待更多的调查。

致谢

我们感谢一位把iPhone手机借我们测试的人。

中文维基百科上的7个用户被永久禁制(附:關於一系列重大基金會行動的說明)

维基媒体基金会今天的大动作:WMC在中文维基百科上的7个用户被永久禁制(包括Techyan和WG),12个管理员权限被剥夺

 https://i.redd.it/izorje812fn71.png

 

https://meta.wikimedia.org/wiki/Office_actions/September_2021_statement/z

 各位好,

我是維基媒體基金會法務部門的副總瑪姬·丹尼斯(Maggie Dennis),目前專門負責社群穩定及發展(Community Resilience & Sustainability)。[1]此信是為了要向大家說明為了保護全球社群,維基媒體基金會採取的一系列行動。

在此先向各位致歉——這封信內容非常長,且部分內容較為含糊。本信所述之大量議題相當複雜,我會儘量簡單總結其中對大家來說可能較不熟悉的資訊。在條件允許的情況下,我會儘量回覆相關問題,在數個星期之後我們的部門將會舉辦公聽會,到時我們可以更深入的討論本案相關議題。具體時間和詳細訊息會於跟工作人員協調好之後,盡快公告於Wikimedia-L和元維基。

也許您們之中許多人已經注意到,最近維基媒體基金會修改了保密協議(Non-disclosure agreements,NDA)政策。在元維基上已經有針對這些政策改變的討論,我不會在此信中複述相關討論內容。[2]簡而言之,基于潜在威脅的可信資訊,維基媒體基金會改變了個人接受保密協議的相關方針。这些安全威脅是有关于對維基媒體的滲透(infiltration)的資訊,包括对能够接触個人身份資訊以及当選的有影響力人物的职务的威脅。由于担心可能触发我们被警告的相關風險,我們無法預告我們此次的行動——即便是對我們所信任的社群成員(如監管員等)我們也不得不保密。我們立即限制了可能受影響的人士對此類工具的使用權限,並正在與相關用戶積極溝通,以核實他們是否確切受到危险。

我想要在此強調我們無意指责因此政策改变而權限受到限制之用戶有任何不良企圖。上述的渗透有多種渠道。我們既发现有用戶為了取得相關權力來刻意试图融入社群——然而他們的最終目的與維基媒體基金會開放知識之目標相左。同時我們也注意到部分受信任的社群成員,可能已成為外部團體利用和伤害的危险目標。这项政策主要為了解決后者,減少相關成員被招募或脅迫的可能性。除了这项政策改变中被除權的用戶能获得的個人資訊可能被洩露之外,我們相信这些用户中的部分也可能面臨危险。

本日,維基媒體基金會已经推出第二阶段的方案著手處理關於滲透的顧慮。我們在兩大受到影響的轄區之一內採取行動。在深入調查未獲認可的組織「中國大陸維基人(用戶組)」(Wikimedians of Mainland China,以下簡稱WMC)部分成員之相關行為後,我們決定全域禁制7位用戶,並將12位管理人員除權。[3]同時,我們向部分編輯者告知了拉票以及人肉搜索的相關政策,要求他們改变行為。

通常來說,維基媒體基金會不會對於自身之行動做過多的解釋,但此次破例是因为此次受影響範圍之大前所未見。為了保護在特定國家,及未受認可之用戶組的用戶之隱私及安全,我們無法透露過多訊息。我承认這些行動实属激進,然而此決議并非轻易。我們並不想要打擊及摧毀那些積極為開放知識奮鬥的诚信的包含WMC成員的中國編輯者的努力。我們不希望他們擔憂他們的貢獻會不受歡迎。可是,我們也不能在明知他們的安全可能遭受威脅的前提下,放任他們暴露在危險之中,而不採取任何保護措施。

  1. 在此之前,我們已經限制了對中國大陸地區用戶的個人資訊存取,我們知悉到上述的威脅存在於我們的專案之中。我們了解到已有用戶因此受到人身傷害。在確認案件真實性後,我們不得不立即採取相應措施。

    在我的維基生涯裡面,此次的事件是一場挑戰,同時是一場勝利——維基百科已從一個受怀疑的非主流網站變成了全球高度信任普遍仰仗的網路百科。我在2007年第一次編輯專案時,就覺得維基媒體有成為世界最偉大的成就之潛力:大众的知识唾手可得。這是全體編輯者偉大的善舉。但是我在我开始編輯之后很快地意識到在如何呈现資訊上的角力之激烈,且有人利用该争端來達成其目的。在此,我並不是要說我有先见之明——我相信有許多維基成員在我之前早就意識到了相應的風險。我相信當今天的維基媒體專案備受信任,而外部勢力控制維基媒體資訊對他們能帶來前所未有的好處的时候,我們面臨的風險之大也是前所未有的。

    「掌控」社群的威脅是實質存在的。數年來,維基媒體基金會一直知道克羅埃西亞語維基百科(Croatian Wikipedia)有面臨相關的挑戰——當中的相關檔案可以追溯至近十年前。維基媒體基金會近期設置了打擊虛假訊息團隊,他們在評估相關風險、尋找適當的方式、並已聘僱外部研究人員來審查專案的相關資料,以幫助我們更好地理解在面臨相似情況時可以使用怎樣的解決方案,以及該情境的起因[4]。最近,我們也成立了人權團隊,專門處理这些因有组织的控制訊息的尝试而造成的緊急人權威脅。我們今天所處理的案件展示了作為一個全球媒體活動,我們多么需要積極地處理面對的威脅,既要保证任何人在任何地方都可以编辑,又要保證这些人免受想让他们噤声的人的伤害。

    關於除權,我們希望可以於可見的未來跟國際中文社群作近一步的溝通,探討我們對於選舉制度的計劃,以避免相關的維基媒體基金會專案被不合理的控制,並確保人们可以感觉安全并确实安全地編輯維基百科。我們需要確保我們的社群可以舉辦公正的選舉——沒有拉票或欺詐的行為。同時,我們希望對於選舉制度的改變可以幫助我們恢復(中文維基百科之)使用者查核員(Checkuser)權限。

    在本信的結尾,我想要对你们当中被驚擾到人被表達我最真摯的歉意。这些人无疑包括那些擔心個人資訊是否已被洩漏的(我們並不認為有這樣的問題。我們已經及時採取行動避免了此事。)以及那些擔心更多此類的維基媒體基金會行動可能影響他們正常編輯和他们的社区的用戶(我們認為我們目前的行動已經在中短期遏止了相關的風險)。我對於受到相關威脅的社群表示抱歉。維基媒體基金會將繼續加強建設,以支持所有需要我們支持的社群,我們也仍然在學習如何能做得更好。同時,我們將繼續改进我們在这两方面的認知:我们在人權領域的影响以及我們解决相關挑戰的能力。您們值得有更好的服務——我們無法馬上解決所有的問題,但我們將积极努力专注地提升改進。

    在此,我想要對在全球活躍貢獻的为五洲四海的读者服务的四千多名中文維基人表達歉意和遗憾。[5][6]我向你們保證,我們將會做得更好。您們向在世界各地的中文維基讀者分享知識是非常有意義的善舉——我們保證會持續支持您們的付出,為您們提供所需工具,使您們在一个安全、有效的环境心想事成。

    在此重申,我會在法務團隊及其他相關團隊的幫助下,盡力回答你們的問題。我們會在元維基上設立一個專頁,以討論此系列的行動,並於幾週之後,我會主持公聽會,讓我們能更深入的討論本案相關議題。

    致以最誠摯的問候, Maggie Dennis (WMF)留言) 2021年9月13日 (一) 16:13 (UTC) 瑪姬


  2. Community Resilience and Sustainability

  3. Talk:Access to nonpublic personal data policy § Policy adjustment on behalf of Legal

  4. Wikimedians of Mainland China

  5. m:Croatian Wikipedia Disinformation Assessment-2021

  6. https://stats.wikimedia.org/#/zh.wikipedia.org

  7. https://stats.wikimedia.org/#/zh.wikipedia.org/reading/page-views-by-country/normal%7Cmap%7Clast-month%7C(access)~desktop*mobile-app*mobile-web%7Cmonthly

全局 HTTPS 是势在必行

https://seo.g2soft.net/2017/01/20/full-https.html

很多站长应该收到 Google 发来的 email 了。从 Chrome 56 开始,任何网页,如果有输入密码或者信用卡资料的,却没有使用 HTTPS,将被 Chrome 浏览器标识为不安全。

其实这只是第一步,之后,任何没有使用 HTTPS 协议的网页都会被标识为"不安全",或者 "Not Secure"。

之前 DavidYin 就建议过,要使用 HTTPS,而且过去我也认为只有在有支付等需求的网站才需要上 HTTPS,现在看来还不够,从2017年1月开始,任何网站都要考虑到上 HTTPS了,新网站从设计,从买域名开始就要考虑到这一点。现有网站也要尽快加上 HTTPS。

google-warning-https.jpg

过去用 HTTPS,买 SSL 证书都是一个比较大的成本。从去年的 Let's Encrypt 可以免费签发证书后,这就不再是一个费用的问题了,而且网上有不少自动签发证书以及续签的脚本,找一个用上就是了。还有一些虚拟空间的服务商,比如 Dreamhost , 也免费提供 Let's Encrypt 的自动签发服务,你都不用去找脚本了,直接在管理后台改一个设置就成了,以后每三个月自动给你续签。

如果想要用付费的域名,我推荐使用 gogetssl ,他们的 SSL 证书价格有优势,而且验证域名所有权以及签发的速度都是非常快的,一般我都是在一个小时内都可以完成了。

Gogetssl 的证书价格,就举几个最低的好了。

  • Comodo Essential SSL,3年USD$25。
  • Comodo PositiveSSL, 3年USD$11.25。
  • GGSSL Domain SSL, 3年USD$9.65。

这三个是 DV 证书而已,我都有买过,用过。可以签发 ECC 证书。

这里 DavidYin 总结一下目前对于 HTTPS 的形势,告诉你如何做好 HTTPS 的8点。

  1. 所有网站都要加上 HTTPS。
  2. SSL 要用 ECC 证书,即使因为某种原因必须要用 RSA 证书的,那么也要用双证书,就是 ECC + RSA两个证书。
  3. 沃通已经信用破产,哪怕以后改个名字再来,也不要用。
  4. 有条件上 HSTS 的,那就加上,这无疑会更加安全。
  5. 只使用 TLS 协议,包括 TLSv1.0, TLSv1.1,TLSv1.2。禁止 SSL 协议。
  6. 在加密算法上,要去掉 RC4。
  7. SSL 证书的签名算法,要使用 SHA-2,不要使用已经被证明有严重缺陷的 SHA-1了。
  8. 前向安全性,Forward Secrecy,就是说要使用 DHE 或者ECDHE 密钥交换。

V2Ray、trojan、NaiveProxy代理的异同及相关问题

https://allinfa.com/reviews-v2ray-trojan-naiveproxy-self-built-proxy.html?utm_source=feedburner&utm_medium=twitter&utm_campaign=Feed%3A+allinfa+%28%E7%BE%8E%E5%8D%9A%E7%BF%BB%E5%A2%99%29

一、北理工破解V2Ray的专利之乱

先说说一年前北京理工大学破解V2Ray的专利一事。2019年3月,北理工的三人(二位教师一位在读硕士生)申请了“基于长短期记忆网络的 V2Ray 流量识别方法”专利,2019年7月公布,发布一种识别V2Ray的特征信号的方法,一时引起一阵小小的骚动。这个事要真成了,中共邪党可高兴了,可是大家也没见到它表现出高兴来,倒是网友担心V2Ray步ss后尘而多了一份担忧。

美博此文讨论这一点就是要让网友放心,一是从道理上来讲,魔高一尺、道高一丈,这才是真理。相生相克,有墙,就一定有破墙的技术,这就是人世间的理。二是,中共还没有办法破解和识别V2Ray的VMess协议,至今如此,那个专利毫无技术水准(下面会分析),以后中共能不能破解VMess协议这也很难说,说不定在破解它的技术出现之前,GFW就随着中共一起下地狱了。退一万步说,即使是中共能找到V2Ray某些特称,也一定会有v3、v4……等等的其他翻墙技术出现来克制中共GFW,邪不胜正,这在封锁网络与翻墙的现实中表现的淋漓尽致,网是封不住的,中共只是领着一帮小鬼如方滨兴、江绵恒等在瞎折腾,耗费民脂民膏,它也从来没有封住过网络。

该专利申请原文在网上也可查到,有兴趣的网友可以去查看,当然是不值得一看的:https://files.catbox.moe/vmzj04.pdf

言归正传看看该专利的专业水准。专利内容是使用LSTM识别V2Ray流量,这不是具有新意或者创造力的技术,从专利本身来看,其权利要求(专利原文):

1.基于长短期记忆网络的V2Ray流量识别方法,其特征在于所述方法包括如下步骤:
步骤1,从交换机设备中获得数据链路层数据包并标注为V2Ray流量或其他流量;
步骤2,去除数据中不包含有用信息和冗余的数据包,去除TCP三次握手数据包,去除DNS域名解析数据包,保留每次通信的前16个数据包,并将这16个数据包作为数据集中的一条数据;
步骤3,对数据链路层数据包进行处理,去除数据链路层报头获得网络层数据包,对UDP报头进行填充使其长度与TCP报头保持一致,去除网络层数据报头中的表示IP地址和端口的信息,对数据包长度进行调整,使其保持一致;
步骤4,使用这些预处理过的数据训练长短期记忆网络。

从专业角度来评审,这个专利基本上就是来吓唬非专业人员的,了解中共高校运作的人就会知道,这样的专利多半是滥竽充数,一般是用来抢站研究位置并获取研究经费的手段、或者评职称需要而已,其技术水准离真正的实际应用和破解或识别还差十万八千里都不止。

既然他们申请了专利,并经过网络转载发酵,当然也引来众多专业人员的评审。我们简单摘录几条。

约翰霍普金斯大学计算机科学李博士说:
步骤1,2和3基本上是标准操作,该专业本科生就知道,没什么可以解释的。步骤四,就是把处理过的包扔进长短期记忆网络里训练,然后用模型匹配数据包。唯一的创新点可能就是V2Ray的前16个包比较有特征吧,具体什么特征还不知道。遇事不决机器学习呗。这个东西不就是把抓来的数据包修修剪剪,不做任何处理,不考虑后续数据包各种加密,然后扔到模型里训练么??坏人打不死,好人误伤一大片吧。。而且就算真的有效果,V2Ray稍微修改下特征,估计整个方法都能废了吧。
Ivlianvs对此专利的分析:
首先,技术错误:
步骤3里提到获得网络层数据包,然而后面跟的是UDP和TCP头。然而UDP和TCP头属于传输层(OSI模型第4层)而不是网络层(3层)。
其次,授权风险:
A) 缺少必要技术特征:该方法是一个流量识别方法,然而最后一步只是训练记忆网络,没有识别任何流量,因此不能解决技术问题。 
B)公开不充分:说明书只给了训练方法,没有详细说明如何识别流量。
第三,商业价值:
A)保护范围过小,易于规避:
最明显的是“保留每次通信的前16个数据包”,任何潜在侵权者可以修改为16之外的任何数量就可以规避专利。
B)只有方法权利要求,只能针对使用者。
C)难以搜集侵权证据:
除非得到源代码,否则无法证明潜在侵权者使用了该专利。D)缺少直接侵权者:流量识别方法的使用者和模型的训练者可能不是同一主体,因此没有人直接侵权。

结论:总之:垃圾专利

V2Ray官方网站的评论:

# 关于某专利
首先,专利并不会保证方法的有效性,专利仅仅是保护方法本身。
其次,该专利的描述存在一些问题:
1. 专利中提到:“V2ray服务端与客户端进行每次通信时需要预先交换密钥,因而每次通信较为靠前的数据包具有显著特征”。
实际上,VMess 协议并不存在“预先交换密钥”这个步骤。
即使将 V2Ray 与需要进行“预先交换密钥”的协议配合使用,那么进行“预先交换密钥”时的数据包也不会有 V2Ray 的数据特征,因为此时还没有开始发送有效数据,即使有特征也是配合使用的协议的特征。
2. 专利中将 V2Ray 拼写成了 V2ray。

北京理工大学的背景

据悉,该专利于2019.07.05公布,三个专利人,依次是罗姓教授、读研一的王同学、潘姓副研究员,都来自北京理工信息与对抗技术研究所。随后这个专利申请的截图被贴在了微博上,并在一些人士的渲染、关心和转发下迅速发酵。更有消息指出,最初的这项研究来自几位本科生的毕业论文,之后再被读研究生一年级的王同学(专利申请人第二位)承袭。按照中共高校的体制,专利申请人第一位的罗姓教授应是其指导教师。

再说说北京理工大学,其前身叫做延安自然科学院。在中共阅兵的30个方阵中,北京理工大学参与了22个方阵的装备的设计和研制,参与数量和深度位居全国高校第一。由此可见,其与红魔的关系要搞出这种荒诞事,也就不奇怪了。

这个专利的最后结果:

大概是因技术含量实在low,所说方法实在太普通,被专业质疑太多,该专利已经悄悄的被撤回。并且连这位申请教授也关闭了微博评论区和私信。一场闹剧结束。

二、V2Ray 的优势与其方案的选择

V2Ray为大家提供了一个平台,支持多种协议,有强力的研发team。V2Ray有别于 trojan、NaiveProxy 的最大特点是 V2Ray有独创的VMess协议。VMess 协议是由 V2Ray 原创并使用于 V2Ray 的加密传输协议,为了对抗墙的深度包检测而研发的。VMess 是一个加密传输协议,它分为入站和出站两部分,通常作为 V2Ray 客户端和服务器之间的桥梁。VMess 依赖于系统时间,请确保使用 V2Ray 的系统 UTC 时间误差在 90 秒之内。

V2Ray的加密形式并不局限于一种协议, VMess 加密在各个传输协议中均是存在的。对于一个内容, VMess 会根据客户端支持的加密方式进行加密,在服务端进行解密,这是基础的一层加密,如果使用WS+TLS的协议进行传输这些内容时,会在内容加密的基础上再进行一次 TLS 加密,也就是说, VMess 会加密两次。因此,即便在传输过程中遭到中间人攻击,导致传输内容变成明文及 TLS 加密失效,V2Ray传输的内容依旧能一定程度保持安全。

V2Ray团队也在及时推行混淆策略,即使是上面专利谈到的”深度学习“,策略制定的复杂度和更新速度就可以克服。在反主动指纹识别上,彻底避免主动指纹识别的方法是用一个真的常见应用(例:nginx)作为前端。

独创的VMess协议优势在于此,其弱点也“可能"在于此。

优势是:独创的VMess协议,可以自行完善,V2Ray团队会想办法让其优于HTTPS,同时克服有特征被识别,也就是说,在VMess被邪党GFW破解之前,这个V2Ray就是安全最好的;
弱点是:也如上述,因使用其独特的VMess协议,这个独特也成为GFW的攻击重点,只要破解协议,或者找到其特征信号,中共GFW就有可能封杀。不过,美博认为至今这个弱点并没有显现。

V2Ray的若干代理方式简评

利用V2Ray核心程序,用户可以开发出多种翻墙方式,而这些方式也各有其特点,常见的:

1)V2Ray + mKCP
特点:连线延迟低,速度更快,但流量大,iOS不支持;有可探测特征信号;不建议使用。
2)V2Ray + TLS
特点:伪装 HTTPS 连线,仅是伪装,有可探测特征信号;不建议使用。
3)V2Ray + Caddy(NGINX等前端)+ ws + TLS
这个有美博教程:自建最强科学上网2:V2Ray+Caddy+Tls+WebSocket
特点:这种方法引入了前端处理,将代理服务器隐藏于真正的网页浏览之中,是网友期待已久的一个完美的翻墙办法,因为即使是中共发疯,也不至于疯狂到全网封杀最常用的 port 80、443 的连线。这种方式的优势就在于只要能通过 端口80, 443 的连线,就能翻墙;而理论上 GFW 要封亦极困难,基本上没可能在不杀错“良民”的情况下禁止 HTTPS 连线。ws(WebSocket)是一种在单个TCP连接上进行全双工通信的协议,解决了HTTP协议的部分问题。ws用在V2Ray上时,请求与应答的效率要远高于HTTP,而V2Ray的请求本就远高于普通的请求,ws对V2Ray就是一个很好的搭配,而且ws已经很成熟,Cloudflare等云服务商也支持基于WebSocket流量的CDN服务,进一步增进了服务器的安全性。由于WebSocket基于TCP协议,保证了链接的可靠性,但也有TCP效率和带宽较低的问题,但是,我们在建立V2Ray代理时开启了BBR加速也可弥补这方面的缺失。WebSocket还有一个缺点是明文传输,与服务器的通信内容可能被第三者探测或攻击,但我们的V2Ray开启了前端网站,也就避免了只做纯代理的这个问题。
4)V2Ray+h2+TLS
这个有美博教程:自建最强科学上网5:V2Ray + Caddy + Tls + HTTP/2
这个方法类似 3),h2本质是HTTP协议,比传统http1.1协议传输速度快,较之类似的WebSocket协议,传输效率略逊于WebSocket。h2+TLS这种协议能使V2Ray流量伪装在正常流量中更难以察觉。
从理论上讲:websocket是http1.1,HTTP/2协议包含了websocket的功能,而Caddy支持HTTP/2代理,所以,自建5略优于自建2,当然这是理论上,从实际使用上美博觉得自建2还要稳定一些,所以二者可等同使用。
5)V2Ray+QUIC/HTTP3
QUIC是谷歌制定的一种基于UDP的低时延的互联网传输层协议。QUIC融合了包括TCP,TLS,HTTP/2等协议的特性,基于UDP传输,UDP效率更高,但可靠性比不上TCP。若作为代理,由于协议本身太新,目前这类流量在网络并不太多,若大量流量指向一个IP会不会被觉察?V2Ray的QUIC、HTTP3,有没有一些兼容问题,美博还没有测试,等测试后若真的效果好,我们再补充教程。

关于caddy

美博这几种自建教程中后来选择使用Caddy,Caddy和常用的Nginx、Apache等Web服务器相比,最大的特点就是部署简单,它拥有基本的apache或者nginx有的web server模块,同时还有一些很有特色的功能,比如: HTTP/2、Automatic HTTPS、Multi-core、Websockets、Markdown、IPv6等等。用来作为搭建代理的前端是很好的选择。

不过,Caddy正在大改版,从v1跳升到v2,但是它的糟糕之处在于v2并不兼容现在广泛使用的v1,对于正在广泛使用v1的用户,Caddy也是不太负责任的,其v2与v1路径、命令等都有差异,使v1用户原本的应用在不知道的情况下被官方改变(删除)而不能使用,这导致全网v1用户都出现问题,并非只是美博遇到,它这个实际上不是v2,是一个全新的版本。本来Caddy_v1很多人觉得好用的命令和设置,在 v2版给删除了,其配置命令更趋近于Nginx,简直是倒车、用户体验也不太好,有网友是其想可能是要靠近Nginx,争夺Nginx的前端大饼。

所以,美博的自建教程在本次修改之前出现了一个空窗期(大约一个多月),里面的配置链接被Caddy官方改变了,不能使用,导致网友建立代理出现问题。

美博这次(2020-05-18)已经修改了教程,去掉了对官方配置下载的依赖,直接在自建时设置。

尽管有上面的变故,Caddy v1 用来与这几个代理搭配仍然不失为目前的最佳选择。

我们利用Caddy只是作为前端网页反代和SSL证书申请及续签,Caddy v1已经足够,如果没有大的变动,美博不考虑升级v2。

V2Ray小结

也就是说,目前V2Ray的最好的常用稳定的方式是: V2Ray + Caddy(NGINX等前端) + ws + TLS 或 V2Ray + Caddy + h2 + TLS,也就是美博教程中介绍的方法。

使用 ws (WebSocket)或 h2 + TLS + Caddy等 伪装的好处:从外面看完全属于通过443端口访问正常的HTTPS网站,websocket、h2的path(即美博教程中的/vv22)被TLS加密不能被探测到,TLS不是伪装、也不是混淆,而是真正的HTTPS,看似浏览网站其用途合理就不会被封锁探测到。从上网记录上来看,代理流量被识别为正常的应用和通讯。

V2Ray代理的安全禁忌:一定要保密!

既然V2Ray可以把代理隐身于茫茫网络数据大海之中,而不被探测、被封锁,这是其技术优势,那么这个代理的创建者和使用者要对其保密也就是至关重要和基本前提,有网友时不时来信希望美博帮忙做一些大家都可以使用的V2Ray代理。

美博要在这里提醒大家的是:只要V2Ray代理公开,你的代理IP和域名就会被人知晓,那么这个代理通过最简单封锁ip和域名的方式就可以被封杀、或者置于不安全的被监控的境地,这对于一些安全要求高的网友要特别注意这一点,一定要保密你的V2Ray,这是基本和前提。

一旦ip和域名被人知晓,通过查询ip和域名等信息,就可能了解到代理拥有人的一些基本信息。

三、trojan的特点及与V2Ray的异同

请注意网上关于trojan搭建代理,也有不同方式,美博介绍的 trojan+caddy 这种方式是目前最好的trojan应用方式。

概括而言,trojan就是V2Ray这种方式(V2Ray+Caddy+ws+TLS)的简化版。

v2ray是一个网络框架,功能齐全;trojan是一个绕过防火墙的工具,轻量级、功能单纯;若二者都使用TLS加密,理论上trojan比V2ray性能更好,所以很多网友觉得trojan代理速度比较快。

v2ray内核用go语言开发,trojan是c++实现;v2ray和trojan都能实现https流量伪装。

详细来说,trojan 采用常见的协议HTTPS,没有使用特别的协议。trojan在建立连接的过程中考虑了现行加密协议的不足,也参考了传统网站服务器的连接过程,trojan似乎有意识的将它trojan服务器伪造成只处理 HTTPS 流量的Caddy/Nginx服务器,这很好。trojan默认监听443端口,其思路是把 trojan代理数据伪装成正常的 HTTPS 通信,对于任何其他访问数据则直接转发到80端口,通过caddy、Nginx等web服务器提供网页访问服务,其他人访问你这个443端口就会跳到你设置的网页页面。当trojan客户端连接到服务器时,首先执行真正的 TLS 握手,若握手成功,则所有后续流量都将受到保护TLS; 否则服务器就立即关闭连接,就像任何HTTPS服务器一样。这样VPS更像一个正常的web服务器,使得 GFW 认为是 正常HTTPS。trojan反侦查采用主动检测与被动检测,而不会被识别出来。caddy+trojan一起合用是很好的组合,trojan绑定在0.0.0.0:443上,转发非trojan流量到 caddy 达到掩护的目的。caddy绑定在0.0.0.0:80上,并自动重定位到https加密浏览。

trojan的方法类似于上面介绍的 V2Ray+ws+TLS,其协议差异并不大。两者建立连接的过程有区别,从流量本身是难以发现区别的。也就是说,对于第三者的监听,这两类协议与普通流量表现均一致,这是两者的共性。

V2Ray是Caddy/Nginx侦听443,数据 → Caddy/Nginx → V2Ray;trojan是自己侦听443,都是伪装成网站。准确的说,以前的ssr是伪装,而trojan和V2Ray的ws+tls其实已经不是伪装,是完整的真正的tls。

V2Ray更专业,功能全面,套两层加密更安全(前提是服务器和本地数据不泄露,使用强root密码/仅使用公钥登录),能套CDN,相对的的速度较慢;trojan更简单、少一层加密,所以理论上速度会快一些。

trojan默认使用tls1.3,V2Ray自 4.18.1版后也支持 TLS1.3 ,传输层加密都支持tls1.3,这一点二者没有区别。

trojan有多线程,V2Ray 在客户端可选择 Mux(多路复用 multiplexing)使所有流量走单线程。所以有人发现长时间的高能使用trojan,服务器的trojan线程越来越多,服务器CPU越来越高,最后可能会死掉。当然,作为代理服务器,除非是商用,个人使用很少出现这种情况。

trojan不能用CDN,不要开启CDN。V2Ray可以使用CND。

一台VPS上可以同时安装 V2Ray ws+tls 和 trojan,但要注意端口控制和传输阻塞。但美博还是不建议同时安装。现在的VPS已经很便宜,建立个人代理买最便宜的VPS都行。

理论上来说,trojan可以永久地穿越Great FireWall,而不会被识别出来。

四、NaiveProxy的独到之处

正如美博教程所述:NaiveProxy是比较新的代理项目,与trojan类似也采用HTTPS协议,但有其独到特点,NaiveProxy可减轻流量指纹识别(特征)、主动探测和数据包长度分析的GFW审查带来的风险,就是说更难被墙检测和封锁。而且,设置比v2ray、trojan还要简略一些。

据官方介绍:NaiveProxy 使用Chrome的网络堆栈来伪装流量,与自定义的网络堆栈(如:Shadowsocks、V2Ray,手工Golang堆栈)相比,具有更强的抗审查能力和更低的可检测性。复用Chrome堆栈使得NaïveProxy在(代理)性能和安全方面有最佳的表现。

NaïveProxy可缓解以下几种方式的流量攻击:

# 网站指纹识别/流量分类:通过HTTP/2中的流量复用来缓解。
# TLS参数指纹识别:因复用Chrome的网络堆栈而不能识别。
# 主动探测:被前端应用所克制,即将代理服务器隐藏在具有应用程序层路由的常用前端后面。(美博注:这应是指反向代理)
# 基于数据包长度的流量分析:通过长度充填来减免。

NaiveProxy 使用Chrome的网络堆栈,GFW墙(审查器)拦截的流量行为与Chrome和标准前端(例Caddy,HAProxy)之间的常规HTTP/2流量相同,没有特征信号。前端还会将未经身份验证的用户和活动探针重新路由到后端HTTP服务器,从而使得无法检测到代理的存在,即:探测Probe → 前端服务器 → index.html(网页)。(美博注:这个部份在v2ray、trojan也都有实现)

正因为其抗指纹识别的独到之处,有人测试比较过几种代理的TLS指纹,结果NaiveProxy独领风骚。

所以,美博教程的NaiveProxy+Caddy,我们也推荐大家与v2ray、trojan等同使用。

总之,trojan、NaiveProxy的出现,借用广泛普及使用的HTTPS协议本身来隐身翻墙,置翻墙于无形,这是重大的技术突破。

五、关于代理性能与速度

谈到这三种代理的性能和速度,网上有一些网友進行了一些零星的测试。美博认为,翻墙技术最重要的在于安全,因为现在的服务器性能提升很快,一年一个样,基本上建立的代理性能即使是比较差一点,服务器都能完全承受并良好运行,至于各个代理的速度,美博也测试过,其实差别也不大,而对于网友上网来讲的感觉并不很明显,而且各个地区也有差异。而且,这些代理与以前的很多代理方法相比,已经都算是相当快了。所以,这些方面不是我们关注的重点。建成、实用、安全,对于代理来讲才是最重要的。

六、关于机场

SS(shadowsocks)的出现是当时翻墙方法的一个突破,后因其协议和特称被识别及国内开发者被中共国安抓去喝茶而停止,后来国外网友继续开发这一项目命名为SSR。
SS/SSR的LOGO,是一个纸飞机的图案。那么建立SS/SSR代理的翻墙服务基地(网站)就被形象的称为“机场”(纸飞机落地的地方)。后来,把提供建立众多SS/SSR、V2Ray、trojan等这些代理服务的场所(网站),概括都叫做“机场”,很显然,这一新名词的流行也是要规避中共关键词的过滤,其准确的含义是“代理服务商或代理服务器提供商”,当然里面有免费的代理提供,更多的是需要付费的,对于用户来讲就是买一个代理来使用。根据“机场”的要求,购买后,填入必要的设置就可以开启代理,可以正常浏览被墙封锁的所有网站了。

对于机场,方便了不会建立代理的网友,有人帮忙建立好了,只是使用即可。

美博建议:

因你无法确认机场背后的主人是谁?在哪里?做什么的?就像是现在已经确认的事实,国外的大多数VPN实际上是中国的,很多是有中共背景的陷阱,若使用到那种代理,就会置自己的安全于危险之中。

当然,如果你能够确认机场主人是可靠的,可信的,没有安全疑虑的,当然那是可以使用的。

总之,对于安全性要求高,或者有安全隐患的网友,美博还是一贯的主张,建议自己学会搭建代理,一生只花几天的时间就学会了自建代理,一劳永逸,很值得呀。而且最重要的是安全。加上美博的代理自建教程写的很详细,一步一步按照教程去做,基本上都能成功搭建自己的代理。

七、更安全的代理使用方法

有些网友要做一些特别的事情,需要特别高的安全保障,如果你已经自建有自己的V2Ray、trojan、NaiveProxy代理,那么这就简单了,用V2Ray、trojan、NaiveProxy作为tor的前置代理,二者配合起来使用,速度虽然会慢一点,但安全、匿名度高,对于安全要求高的网友是目前最安全、稳妥的隐身方法。

当然,安全的基本要求前提是:你的电脑必须是安全的,这是大前提,如果电脑不安全,其他上网代理安全就无从谈起。

八、结论

至今,V2Ray、trojan、NaiveProxy 代理仍然是目前最好的代理,网友若有一些基本的电脑知识,美博的教程写的尽量的详细就是要适合新手操作。美博一直建议尽可能的学会自建这些代理,尽管开始学可能会多花几天时间,但学会以后就几乎是一劳永逸,邪墙再也封锁不了你上网了,而且安全、快速,这几种代理隐藏身份的效果是目前最好的,所以,建议大家都来学学自建。

每多一个人学会自建,共产党的邪墙就多一个崩溃的窟窿,千万人、亿万人都能自建,邪党墙就形同虚设了,不攻自破了。

以前一些著名代理软件,比如利用公共服务等来做代理,早被邪党识别其特征,所以只有不断更新来维持,新版一推出很快又被封杀,所以技术尚待更新。而这几种代理V2Ray、trojan、NaiveProxy 几乎趋近完美,代理服务就像是浏览真正的网站,目前都是安全可靠的,再次建议大家都来学学自建。

首例!违反 GPL 协议致侵权,被判赔偿 50 万元

https://www.oschina.net/news/159435

https://twitter.com/txyyss/status/1436004934697115651?s=20
这是大好事啊,对后续类似案件应该有正面影响。我现在有种我国也是判例法的错觉了。--- Shengyi Wang

近日,一起关于 GPL 版权纠纷案裁判文书公示。一审判决书显示,GPL3.0 协议是一种民事法律行为,合同性质,可认定为授权人与用户间订立的著作权协议,属于我国《合同法》调整的范围。一审判定两侵权被告公司赔偿原告公司经济损失及维权合理费用共计 50 万元,并停止侵权行为。

此判例可以说是中国首个明确 GPL3.0 协议的法律效力的案例。判决书显示,明确违反开源软件许可证的侵权法律责任,一方面可以及时制止侵权行为,防止他人对开源软件的不正当利用;另一方面能够有效保护授权人的利益,使他们保有继续创作的动力,促进源代码共享和知识的传播。

不过值得注意的是,本案中被告的侵权事实成立,是因为违反 GPL3.0 协议导致 GPL3.0 协议自动解除,被告失去了 GPL3.0 协议下的源代码授权保护,进而构成侵权。

判决书中对于违反 GPL3.0 协议的侵权责任明确如下:

关于违反 GPL3.0 协议的侵权责任。

著作权法为了保护权利人的专有权,仅规定非权利人可以在如“合理使用”等范围内使用作品,诸如复制、修改、发行等权利则专属于权利人,任何人非经许可实施这些行为将构成侵权。

根据 GPL3.0 协议第 8 条“终止授权”的约定,授权人许可用户在遵守许可证规定的前提下行使某些权利,但用户必须承担相应的义务。若用户违反 GPL3.0 协议的使用条件来复制、修改或传播受保护的作品,其通过 GPL3.0 协议获得的授权将会自动终止。

对此,我国《民法总则》第一百五十八条规定:“民事法律行为可以附条件……附解除条件的民事法律行为,自条件成就时失效”。

根据开源软件的特性,GPL3.0 协议规定的使用条件(如开放源代码、标注著作权信息和修改信息等)系授权人许可用户自由使用的前提条件,亦即协议所附的解除条件。一旦用户违反了使用的前提条件,将导致 GPL3.0 协议在授权人与用户之间自动解除,用户基于协议获得的许可即时终止。用户实施的复制、修改、发布等行为,因失去权利来源而构成侵权。

本文案件相关内容整理自一审判决书。

案件概况

原告:济宁市罗盒网络科技有限公司

被告:福建风灵创景科技有限公司(以下简称福建风灵公司) 

被告:北京风灵创景科技有限公司(以下简称北京风灵公司)

(福建风灵公司系被告北京风灵公司的全资子公司)

被告:深圳市腾讯计算机系统有限公司(以下简称腾讯公司)

原告济宁市罗盒网络科技有限公司独立开发“罗盒(VirtualApp)插件化框架虚拟引擎系统 V1.0(简称 VirtualApp V1.0)。VirtualApp 从 2016 年 7 月 8 日的版本开始引入开源协议,起初为 LGPL3.0 协议,2016 年 8 月 12 日更换为 GPL3.0 协议。

2017 年 10 月 29 日,原告公司在 VirtualApp 后续开源版本中删除“适用 GPL3.0 协议”的表述。

2017 年 11 月 8 日,原告公司为 VirtualApp V1.0 取得计算机软件著作权登记证书,依法享有 VirtualApp V1.0 软件著作权的全部权利。

2017 年 12 月 30 日由 Lody(原告公司股东、VirtualApp 项目人罗迪) 提交的更新(对应 Git 码为8e6d9cd925af55b53a7e93046c469dd69676c38b)的 CHINESE.md 文件内载明“VirtualApp(中文名为罗盒)2017 年 8 月份正式公司化运作,当您需要将 VirtualApp 用于商业用途时,请务必联系 QQ1*****购买商业授权……VirtualApp 源代码将于 2017 年 12 月 31 日停止更新”。

2018 年 9 月,原告调查发现名为“点心桌面”的软件使用了 VirtualApp V1.0 的代码,将两个软件源代码进行分析比对,两者间 421 个可比代码中有 308 个代码具有实质相似性,有 27 个代码具有高度相似性,有 78 个代码具有一般相似性。因此,被诉侵权软件与涉案软件构成实质相似。

原告向法院起诉,庭审时明确诉请为判令如下:

1.被告福建风灵公司、被告北京风灵公司立即停止侵害原告的计算机软件著作权,即立即停止通过互联网提供所有版本的“点心桌面”软件的下载、安装和运营服务;

2.被告福建风灵公司、被告北京风灵公司赔偿原告经济损失 2000 万元;

3.被告福建风灵公司、被告北京风灵公司赔偿原告为制止侵权行为而支出的合理费用 50 万元;

4.被告福建风灵公司、被告北京风灵公司承担本案诉讼费用。

证据显示,被告福建风灵公司系被诉侵权软件“点心桌面”的著作权人。被告北京风灵公司亦被有关互联网平台标示为“点心桌面”的开发者,并被登记为“点心桌面”软件的著作权人。此外,提供被诉侵权软件下载、安装和运营服务的“点心桌面官网”和“应用宝”网站分别由被告福建风灵公司和腾讯公司经营。

立案之后,经查,被诉“点心桌面”App(V6.5.8)中使用了原告采用 GPL3.0 协议发布的VirtualApp,同时被告对此亦予以确认。

法院观点

法院认为,该案系侵害计算机软件著作权纠纷,涉及开源软件的相关问题。根据双方诉辩意见及举证情况,该案争议焦点有四方面。法院已就焦点问题给出明确观点。

(此部分为法院观点截选,详情可查看判决书原文。)

焦点一:GPL3.0 协议的法律效力。

法院明确 GPL3.0 协议具有合同性质,可认定为授权人与用户间订立的著作权协议,属于我国《合同法》调整的范围

关于违反 GPL3.0 协议的侵权责任,明确若用户违反 GPL3.0 协议的使用条件来复制、修改或传播受保护的作品,其通过 GPL3.0 协议获得的授权将会自动终止。

焦点二:原告是否有权提起本案诉讼。

一是根据代码托管网站上的上传记录及证明等,原告公司可以证明是 VirtualApp 的著作权人。

二是原告提起本案诉讼无需贡献者的同意或授权,即有权提起诉讼。原因包括:原告公司股东罗迪作为项目人已将 VirtualApp 初始版本的源代码共计 31097 行在 Github 网站上公开发布,此系原告主张权利的基础;本案项目人对“主分支”中 VirtualApp 源代码的形成起到了决定作用;贡献者选择在 GPL3.0 协议的 VirtualApp 项目中上传自己的源代码,贡献者亦将按照 GPL3.0 协议许可其贡献,即视为同意将贡献内容许可给项目人及其他用户使用,并且若开源项目的起诉维权需经全体贡献者一致同意或授权,实则导致维权行为无从提起。综上,原告提起本案诉讼无需贡献者的同意或授权。

三是,GPL3.0 协议中仅限制授权人不得向用户主张任何专利权,而并未限制授权人对违反许可协议的用户主张著作权。因此,原告的诉讼行为并未违反 GPL3.0 协议关于争议解决方式的约定。

焦点三:被诉行为是否侵害原告的著作权。

一是原告虽将 VirtualApp 分为开源版本与商业版本,并且在后续开源版本中删除“适用 GPL3.0 协议”的影响问题。

原告在本案中系以 VirtualApp 开源版本而非商业版本作为其权利基础,故本案中不必对VirtualApp 开源版本与商业版本的关联及影响作出认定。而根据 GPL3.0 协议,若先前版本使用了 GPL3.0 协议,则后续版本也必然受 GPL3.0 协议的约束,因此 VirtualApp 后续开源版本仍然受 GPL3.0 协议的约束。

二是 GPL3.0 协议允许用户进行商用,授权人不得对此作出限制。所以原告主张“点心桌面”App进行商用违反 GPL3.0 协议及其附加条款缺乏理据,法院不予支持

三是被诉“点心桌面”App(V6.5.8)本应当遵循 GPL3.0 协议向公众无偿开放源代码,但被告福建风灵公司拒不履行 GPL3.0 协议规定的使用条件。根据 GPL3.0 协议第 8 条自动终止授权的约定及《民法总则》第一百五十八条的规定,被告福建风灵公司通过该协议获得的授权已因解除条件的成就而自动终止。被告福建风灵公司对 VirtualApp 实施的复制、修改、发布等行为,因失去权利来源而构成侵权。

焦点四:若侵权成立,被告应承担的法律责任。

被告福建风灵公司作为“点心桌面”App(V6.5.8)的开发、运营和发布者,依法应承担停止侵害 VirtualApp 著作权的行为。鉴于被告福建风灵公司系被告北京风灵公司的全资子公司的情形,原告指控两被告共同承担侵权责任合法有据,法院予以支持。

被告腾讯公司对其“应用宝官网”上可能存在的侵权行为制定了相关规则、设置了投诉渠道,且对被诉软件作了及时下架处理。原告亦未对被告腾讯公司提出具体诉请。因此,被告腾讯公司无需承担法律责任。

关于赔偿问题,原告主张以被告福建风灵公司、被告北京风灵公司的侵权获利来计算。鉴于开源许可协议缔约方式和缔约主体的特殊性,导致违约或侵权行为更具隐蔽性,相应法律责任的承担应有助于敦促缔约方诚信履行开源义务,确保开源社区规范、持久的发展。开源软件大多都是免费的,但授权人付出的开发成本是必然存在的,按照侵权获利来承担赔偿责任更为公平合理。

最终,法院酌情确定赔偿数额为 50 万元。原告为制止本案侵权行为所支出的合理费用,计算在赔偿损失数额范围之内。

关于此案的更多细节和法院观点,详情可登陆中国裁判文书网查看此案(2019)粤03民初3928号一审判决书。

一审判决书:

https://wenshu.court.gov.cn/website/wenshu/181107ANFZ0BXSK4/index.html?docId=05f553bd178d4354bb48ad5100c1314f(中国裁判文书网地址)

https://www.iphouse.cn/cases/detail/woznd0v9pek4jx35ovdj8y5gxrm371q2.html?keyword=GPL(其他网站地址)

律师解读

我们邀请专注 TMT 领域的知识产权问题的邓超律师(18611123013)就此案件做相关解读。后续邓超律师将发表深度解读文章,敬请期待!

问题一:此案对后续有关开源软件版权纠纷案件有何具体参考意义?

这个案子据我所知,被告上诉了,所以现在这个判决还没有生效,最后法院怎么认定,还没有最终定论。

但毫无疑问的一点是,违反许可证的义务是会遭到权利人的侵权索赔的。

因为以往国内开源主要是拿来主义,使用国外的代码比较多,但随着国内开发者的不断成熟。将来相关的纠纷会越来越多,这就要求法务和开发人员了解开源的相关问题。

问题二:为什么此案件中,“点心桌面”未被强制开源?

没有要求强制开源是因为原告没有提出这样的要求,那么法院是一个被动的审判机关,不告不理,只被动审理原告提出的请求。

在这个案件中,原告没有选择合同,也就是许可证违约,而是选择了版权侵权这条救济途径。一般而言,版权侵权要比合同违约的救济力度要大,无论从各个方面,这在国内和在美国都是如此。

问题三:如果原告提出了开源的诉求,会如何?

如果原告选择了合同违约这条途径,法院是不是会支持被告将代码强制开源这个问题其实很值得探讨,我个人初步的观点是,法院不一定会支持这种诉请。关于这个事情,我准备近期写篇文章,但我现在初步的看法是要求代码强制开源,在法院不太可能得到支持。

所以,如果违反 GPL 许可证的义务,那么将代码全部开源,更多的是一种理论上的可能。在实践中,以中国和美国的法院为例,我理解支持这种诉求的可能性都非常低。

延伸阅读

GPL 解读文章:

人话解读GPLv3https://my.oschina.net/vigor23/blog/4951596

论“GPL就是给软件开发者们准备的坑”https://my.oschina.net/vigor23/blog/4954734

开源软件、自由软件、Copyleft、CC都是啥,傻傻分不清楚?https://my.oschina.net/vigor23/blog/5138356

夜天之书 #6(Copyleft 相关解读):https://my.oschina.net/u/4489239/blog/5252879

4 個你不該使用 Hola VPN 的理由《2021》

https://twhowto.com/hola-vpn/

如果你是 Hola VPN 的用戶,或者是正在猶豫要不要使用 Hola VPN,那麼你一定不能錯過接下來的內容

在這個時代,使用者付費己經是多數人都接受的觀念,連停車都要收費的時代,為什麼 Hola VPN 願意提供免費的服務呢?

在這篇文章我們將告訴你關於 Hola VPN 的優缺點、以及為什麼那麼「佛心」的秘密


目錄


hola vpn

Hola VPN 優點

一、免費又容易使用

Hola VPN 稱自己為「免費的 VPN」,事實上它的確是免費沒錯,但這也伴隨著一點代價,我們在下面 Hola VPN 的缺點中會提到這一點

安裝相當容易,只要在 Google 搜尋一下「Hola VPN」就能夠找到它的瀏覽器套件,安裝後馬上就能使用

二、輕鬆破解部份網站

Hola VPN 的確能解除部份網站的地區限制,像是 Youtube、或是部份的國外網站,不過 Netflix、Amazon Prime Video、Disney+ 這些只在付費功能中才能解鎖

乍看之下 Hola VPN 真的是佛心來著,但接下來我們將告訴你,Hola VPN 不會告訴你的事


hola vpn

Hola VPN 缺點

一、蒐集用戶的資料

和大多數的免費 VPN 一樣,Hola VPN 在隱私權政策裡就有提到,「我們將蒐集使用者瀏覽過的頁面、網站停留時間、IP 位址、姓名、電子信箱、帳單紀錄

而它們再將蒐集到的客戶資訊賣給第三方的廣告公司來換取利潤,藉以維持 Hola VPN 的營運,這也是我們不建議使用 Hola VPN 最主要的原因

如果您希望使用 VPN 的原因是在於匿名性,無日誌紀錄 Surfshark  NordVPN 才是您該選擇的 VPN

二、沒有任何的加密

首先我們得先談談 Hola VPN 的運作原理,和其他 VPN供應商不一樣,Hola VPN 並不需要花大錢去架設伺服器,它透過共享使用者的資源來運作

你所連線到的 IP 其實是另一個 Hola VPN 的使用者,而在連線的同時,或許也有人正連到你的 IP 來解除網站的地區限制

而更可怕的是由於沒有任何的加密,Hola VPN 是沒辦法保證你的電腦安全的,事實上,Hola VPN 的開發帳號也曾經被駭客盜取過,還因此上了新聞

hola vpn

三、成為殭屍網路的一員

如果你不懂什麼是殭屍網路的話,簡單來說就是由於電腦中毒、或是被駭入,透過程式來操控你的電腦來進行其他動作、指令

想像你什麼事情都沒做,卻有警察上門說有網路犯罪事件,而 IP 位址就是在你的住家,這樣子不可怕嗎?

或許你會覺得有點誇張了,但 Hola VPN 也證實了曾經發生過這件事

四、功能不夠完整

如果你不在乎資安的問題,那麼前三點或許無法勸退你,不過你知道 Hola VPN 其實能做的非常有限嗎?

需要跨區看 Netflix、找更快的 BT 種子,這些 Hola VPN 其實並不支援,Hola VPN 並非變更你的 IP,而是讓你使用他人的 IP,即使這次能夠成功,下次同一組 IP 可能己經被網站加入黑名單了