網友討論: 如果GFW消失,大家觉得中国的互联网会发生怎么样的变化?

 https://ourcoders.com/thread/show/74054/

如题,大家随意发挥,我说一下自己的看法

1.百度大概率会边缘化,被Google,Wikipedia等挤死

2.微信,QQ不太会受到太大影响,但facebook,instagram等会抢得不少流量

3.youtube,netflix等会使得国内的视频网站生存空间变小,尤其是排名靠后的视频网站

4.知识产权的保护会加强不少

发了这么久,大家好像也没什么反应,那干脆换一个问题。

如果GFW消失,大家觉得要多长时间?

備份香港,不能只用家中硬碟

 https://matters.news/@edmond/%E5%82%99%E4%BB%BD%E9%A6%99%E6%B8%AF-%E4%B8%8D%E8%83%BD%E5%8F%AA%E7%94%A8%E5%AE%B6%E4%B8%AD%E7%A1%AC%E7%A2%9F-bafyreidrmylae546jge4st3ti5ctg6gq52mmxdk4fzzu2g5s4q63w5ofjy

IPFS 只保證內容仍然存在於網絡上,卻不保證能被找到。如果沒有一個索引機制,讓 IPFS 上的檔案能有效率地被發現,等於說「已把內容備份到宇宙某處了」一樣。

有人不喜歡過去發生過的歷史,尤其有關政策和執法者做過的壞事,落空的承諾,及累積了百多年的香港人的身份認同,想將之抹去再重新建立有利管治的論述。已把香港故事印在腦中那幾代香港人他們不管了,卻準備對一張白紙般是小朋友洗腦,向教育領域磨刀霍霍。

其中一件最近發生,挑動香港人神經的事件,便是有人企圖把過往作惡的證據消滅,從互聯網下架有關香港真相的內容。以後再 Google 不到,日子久了便貌似沒發生過一樣,就像三十二年後內地民眾根本不知道什麼是「坦克人」一般。

認識歷史不但是彰顯公義的必要一步,同時也是身份認同的重要基礎。香港人當然知道這個與民為敵的老大哥想搞什麼鬼,紛紛購買外置硬碟,把將要下架的史料備份下來。然而備份資料到家中硬碟只是基本步,若資料一直無法在公共空間流傳,最終跟埋在地底沒有兩樣。何況,真理部正以公帑大量生產他們認為的正確的「真相」,這些內容將會佔據點搜尋器首頁的結果,真相將會愈埋愈深。

將來孩子們會接觸到怎樣的歷史?百度一下,你就知道。例如「五大訴求」的搜尋結果首位是:

  1. 支持香港特区政府和警队严正执法;
  2. 在社会秩序恢复之前暂停批准一切公众游行集会活动;
  3. 劝止学生参与违法活动;
  4. 严惩暴力和骚乱的违法行为;
  5. 严惩政府任何传媒透过发放失实报道及混淆视听。

身處香港的人切勿以身試法

好吧,那我們把資料重新放上網不就行了?少年你太年輕了。

首先,若老大哥是版權持有人,他可以要求平台如 YouTube 和 Facebook 等把內容下架。他還可以控告上載這些資料的市民侵權。還有山雨欲來的「假新聞法」也正是為此而立,因為民眾上傳對政府不利的內容都是假新聞,立法便可據此控告資料上傳者。還有不誠實使用電腦這萬能 key,及包羅萬有的宇宙國安大法,都是老大哥控制言論的強力武器。

所以,我嚴肅地奉勸身處香港的人,千萬不要以身試法。


把內容存到星際

就算真的把政府看不順眼的資料上傳到網絡,也不代表人們便能看到。目前老大哥用得最熟的方法是散佈他們口中的「真新聞」,你發一則他發十則,溝淡網絡上的訊息,即所謂的 disinformation 是也。這一點很棘手,日後有機會再談談。

Disinformation 以外,最常見的手法是屏蔽,像 hkchronics.com 的例子,封域名、封個別 IP 地址、封整個 IP 地址段,使用戶訪問不到,內容便會像在世上消失了一般。這不是什麼新事物,先進的祖國「網絡長城」正是領導全球的代表,香港也快要跟上了。中國網民若要接觸海外的「不良資訊」,要用 VPN 服務避過審查的封禁,俗稱「翻牆」,這方面的經驗祖國的網民比香港人何止領先了一個十年,我們一定要急起直追才行。

根據內容的網絡位置去訪問的方法稱為 location addressing,老大哥就是封禁通往那個位置的路徑;但有另一種訪問內容的方法叫 content addressing,用戶根據的是內容的獨一指紋 (fingerprint),而這內容的檔案則可以分散地儲存於多於一個網絡位置,令老大哥無法輕易地靠封掉某個網域或 IP 來令內容消失,這用 content addressing 的網絡檔案系統叫星際檔案系統 IPFS (InterPlanetary File System)

然而,IPFS 只保證內容仍然存在於網絡上,卻不保證能被找到。如果沒有一個索引機制,讓 IPFS 上的檔案能有效率地被發現,等於說「已把內容備份到宇宙某處了」一樣。其中一個可以考慮的索引方法當然是建一個儲存了所有 IPFS 版本內容的網站,讓用戶可輸入條件搜索資料,但這網站會立即進入了老大哥的雷達範圍,網域和 IP 地址不被封才怪。避開雷達的方法可以是:索引檔案本身便是分散地儲存在 IPFS 上的檔案,如此便很難完全封禁,除非老大哥把全世界所有的 IPFS 網關都封掉 – 雖然以他現在的瘋狂霸度,做得出這種鎖港行為也不出奇。但由於人人都可以成為 IPFS 節點,搭建 IPFS gateway 也不是什麼難事,民眾可以名副其實 be water,跟老大哥爭持。


對 Odysee 美麗的誤會

有些師兄把資料備份到 odysee.com 這個去中心化影片網站,這確是不錯的一招,但政府要拆解卻不難。政府最簡單的做法向 Odysee 提出侵權控訴,營運 Odysee 的是一家美國公司 LBRY,必須遵守當地法律,因此會查明屬實後把侵權作品下架,所以上傳到 Odysee 跟上傳到 YouTube 的效果從這個角度看是一樣的,因為他們都是中心化營運的平台。

被 Odysee 下架的內容,長這樣:

然而 Odysee 去中心化之處,在於上傳到 Odysee 的資料會儲存到 LBRY 的分散式檔案系統及區塊鏈上,就算影片在 Odysee 網站下了架,也能通過 LBRY 的協議存取檔案,內容不會從網絡上消失。由於 Odysee 是開源的,任何懂技術的人若有興趣可以隨時複製一個相同的網站,展示任何在 LBRY 網絡上的資料。對於侵權控訴,LBRY 會做的是向用戶公佈這些「問題內容」的名單,勸喻用戶不要瀏覽那些內容,但技術上無法阻止有人根據 LBRY 技術協議訪問那些已在網絡公開了的內容。

同樣是提供去中心出版 (Decentrailized Publishing #DePub) 基建讓出版民主化,LikeCoin 的核心應用 ISCN (International Standard Content Number) 也是把內容 metadata 儲存在區塊鏈,並把檔案儲存在分散式網絡,跟 LBRY 的做法差不多;最主要分別在於前者使用的是 IPFS 技術,而且積極發展內容社群的流動民主治理機制。目前 LikeCoin 網絡正由 40 名分佈全球各地的驗證人共同營運。


由民眾自行定義內容價值

在香港正在發生的是:發佈最多虛假資訊的人賊喊捉賊,企圖以「假新聞法」把所有反對自己的所謂「假新聞」杜絕,說白了就是藉此按己意打擊言論自由。這是一個極端的社會狀況,因為在一個正常的社會,民眾對所謂真假的定義能透過機制取得共識,而不是由誠信為負值的老大哥「真理部」定義。新聞、歷史確有需要弄清真假,核心價值的定義也理應基於公民共識,這便是為何那麼多人無償自發備份香港史料的原因,這些工作本應由民眾委託的政府去做。

LBRY 沒有這種由民眾賦權判定價值的民主治理機制,只提供技術上的資料分散保存及流傳方案,唯一能根據的標準只是侵權的法例。但香港人都已親身體會過法律被老大哥濫用的禍害,尤其當立法與執法機關的基礎不基於「公意」,只為維護管治權力之時。歷史真偽的話語權,必須由大眾自己話事,其中一個方法是利用區塊鏈達到「冇大台,有共識」,如水份子各自獨立卻自然向著某個方向流,或所謂的「流動民主」。期待將來發展出能由民眾授權判定內容價值的仲裁機制,這種去中心治理機構 (Decentralized Autonomous Organization,DAO) 的議政模式現在已具鶵形。

 

最近是不是电信移动都扩容了。。。

https://v2ex.com/t/767650

 

这次的扩容不是传统的扩容了,而是将国际出口局分为两个局

上海 1 为原来的国际出口局,负责上海、江苏、浙江、山东,新增上海 2 国际出口局,安徽 福建 江西的业务接入新的国际出口,不是所有的省共享一个出口了,所以分在不同出口局的省,出口质量也会不一样

广州局没有统计详细情况,目前可以确定四川和广东不在同一个局。

更像是按省分配资源了,某些超级大省无法独占更多资源。现在四川已经有充足的国际出口,但是广东仍然不足

指 C-I 段。国际出口本身不堵的线路,比如电信到美西,移动到香港 CF,这两天晚高峰都能跑 100M 了。。。当然国际链路段本身堵的线路,比如电信到 NTT 还是那样

 

 

揭示和规避中国对加密SNI(ESNI)的封锁

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

 

iyouport于2020年7月30日报告 (存档)中国封锁了带有ESNI扩展的TLS连接。 iyouport称初次封锁见于2020年7月29日。

我们确认中国的防火长城(GFW)已经开始封锁ESNI这一TLS1.3和HTTPS的基础特性。我们在本文中实证性地展示如何触发审查,并研究"残余审查"的延续时长。 我们还将展示7种用Geneva发现的基于客户端或服务端的绕过审查策略。

什么是加密服务器名称指示(ESNI)?

TLS是网络通讯的安全基础(HTTPS)。TLS提供的认证加密使得用户可以确定他们在与谁通讯, 并确保通讯信息不被中间人看到或篡改。 虽然TLS可以隐藏用户通讯的内容,但其并不能总是隐藏与用户通讯的对象。 比如TLS握手可以携带一个叫做加密服务器名称指示(SNI)的扩展, 这个扩展帮助客户端告诉服务器其想要访问的网站的域名。 包括中国在内的审查者利用这一扩展来检查并阻止用户访问特定的网站。

TLS1.3引入了加密SNI(ESNI)。 简而言之就是用加密了的SNI阻止中间人查看客户端要访问的特定网站。 (更多ESNI的益处请见Cloudflare的介绍文章)。 ESNI有让审查HTTPS流量变得更加困难的潜能; 因为不知道用户使用ESNI访问的网站,审查者要么不封锁任何ESNI连接,要么封锁所有的ESNI连接。 我们现在确认中国的审查者选择了后者。

主要结论

  • GFW通过丢弃从客户端到服务器的数据包来阻止ESNI连接。
  • 封锁可以从GFW内外双向触发。
  • 0xffce扩展标识是触发封堵的必要条件。
  • 封锁可以发生在1到65535的所有端口上。
  • 一旦GFW阻断了一个连接,残留的审查就会继续阻断与(原IP,目标IP,目标端口)三元组相关的所有TCP流量,持续120或180秒。
  • 我们已经发现了6种可以部署于客户端和4种可以部署于服务端的规避策略。

我们是怎么知道的?

我们写了一个简单的Python程序,它可以:

  1. 完成与指定服务器的TCP握手;
  2. 然后发送一个带有ESNI扩展名的TLS ClientHello消息;ClientHello的指纹和Firefox 79.0所发送的一样正常。

我们让程序发送带有ESNI的ClientHello消息。我们既尝试了从墙内向墙外发送,也尝试了从墙外向墙内发送。我们同时采集客户端和服务端两边的流量进行分析,我们确保发送ClientHello的服务器会完成TCP握手,但不会向客户端发送任何数据包,也不会首先关闭连接。所有的实验都在7月30日到8月6日之间进行。

关于封锁的细节

通过丢弃数据包来阻止,而不是注入RST

对比两端捕获的流量,我们发现GFW通过丢弃从客户端到服务器的数据包来阻止ESNI连接。

这与GFW对其他常用协议的阻断方式有两点不同。 首先,GFW审查SNI和HTTP的方式是向服务器和客户端注入伪造的TCP RST。但是我们没有观察到GFW注入任何数据包来阻断ESNI流量。其次,GFW通过丢弃服务器到客户端的流量封锁Tor和Shadowsocks服务器的端口和IP;然而,GFW会丢弃客户端到服务器的ESNI流量。

我们还注意到,GFW在丢弃TCP包时,并不区分TCP包的标志。(这与伊朗的一些审查系统不同,后者不丢弃带有RST或FIN标志的数据包。)

封堵可以双向触发

我们发现封堵是可以双向触发的。 换句话说,从防火墙外向防火墙内发送一个ESNI握手,和从防火墙内向外发送一样,都可以触发审查。

得益于这种双向性,人们可以在不控制任何位于中国的服务器的情况下,从GFW外部远程测试这种基于ESNI的审查。 我们指出,除了ESNI审查外,GFW对DNS、HTTP、SNI、FTP、SMTP和Shadowsocks的审查也可以从墙外进行测量。

GFW对ESNI进行审查,但不封锁没有SNI扩展的ClientHello

我们确认没有ESNI和SNI扩展的TLS ClientHello不能触发封锁。 换句话说,encrypted_server_name 扩展的 0xffce 扩展标识是触发封堵的必要条件。

我们将ClientHello中的0xffce替换为0x7777然后进行测试。替换后,发送这样的ClientHello就不能再触发封锁了。

这个确认是很重要的,因为有人观察到其他审查者可能会屏蔽任何没有SNI扩展的ClientHello消息,这将导致ESNI和无SNI都会被屏蔽。

新的扩展值还未被封锁

riseup pad上的匿名人士指出, 现有的ESNI使用0xffce作为扩展值(详见 Section 8.1)。 但时新的ECH使用0xff020xff030xff04作为扩展值(Section 11.1). 我们确认这些新的扩展值还未被封锁。

具体而言, 我们把一个能够触发审查的ClientHello的0xffce替换为了0xff020xff030xff04。 发送修改后的ClientHello不能触发审查。

GFW需要看到一个完整的TCP握手以触发ESNI封锁

我们发现GFW需要看到一个完整的TCP握手以触发ESNI封锁。

我们从外部对中国的服务器进行了两次实验。在第一个实验中,在没有发送任何SYN包的情况下,我们的客户端每2秒发送一个带ESNI扩展的ClientHello消息。在第二个实验中,我们的客户端每2秒发送一个SYN数据包和一个带ESNI扩展的ClientHello消息;但服务器不会响应任何数据包(也不会发送SYN+ACK来完成握手)。

在每次实验中,我们都发送了10条ClientHello消息。结果发现没有触发过任何审查或残余审查。所有的ClientHello消息实际上都到达了服务器。这个结果表明,在触发基于ESNI的审查之前,TCP握手是必要条件。 这也表明,与GFW基于SNI的审查机类似,ESNI的审查机也是有状态的。

封锁发生在所有端口上

我们发现ESNI封锁不仅会发生在443端口,也会发生在1到65535的所有端口。

具体来说,我们从外部向中国服务器的1-65535的每个端口连续发送了两次ESNI握手。 对于每个端口,我们先发送一次ESNI握手;然后在连接超时后(20秒后),我们再尝试与服务器完成一次TCP握手。如果第二次没有收到服务器发来的SYN+ACK,我们就认为该端口被封锁了。 结果是,在1到65535的所有端口上都观察到了对ESNI的封锁。这个特性可以让我们高效地测试ESNI封锁,因为我们可以对同一IP地址的多个端口进行同时测试。

审查残留

我们发现在阻断ESNI握手后,GFW会继续阻断与(源IP,目标IP,目标端口)3元组相关的任何连接一段时间。确切的审查残留时间可能会有所不同。我们观察到它有时持续120秒,有时持续180秒。我们注意到,在残留审查时间内发送额外的ESNI握手不会重置审查持续的定时器。这与之前观察到的基于SNI的拦截GFW的残余审查类似;而且它与伊朗的残余审查不同,在伊朗,定时器将被重置

这些发现部分基于以下实验。从外部,我们每秒向中国服务器的443端口发送一条ClientHello消息。 第一秒,第二秒和第121秒的TCP握手被接受。其他所有的握手尝试都不成功,因为由于残留的审查,SYN包甚至没有到达服务器。

这个结果表明,与之前发现的GFW对SNI的残留审查类似,GFW也对ESNI也采用了残留审查。此外,第二秒的握手可以完成,意味着GFW至少需要1秒的时间来反应并启用拦截规则。

如何规避封锁?

**Geneva(Genetic Evasion)**是我们中位于马里兰大学的研究人员开发的一种遗传算法,它在进化过程中自动发现新的审查规避策略。 它在不影响原始连接的前提下,通过注入、替换、分割或丢弃数据包流来迷惑审查者。 与大多数反审查系统不同的是,它不需要在连接的两端都进行部署:它只在一方(客户端或服务器)运行。

Geneva利用审查机器来实时地训练自己的遗传算法。 截至今日,其已经找到了许多可以规避不同国家审查的策略。 Geneva的审查规避策略描述了应该如何修改流量。 由于Geneva将不断发展这些策略,因此它们用领域特定语言(domain-specific language)来表达,这些语言构成了每个策略的 “DNA”。(关于Geneva的完整代码及文档,请参见我们的Github页面)。

要了解更多关于Geneva(或Geneva策略引擎)工作原理的信息,请参阅我们的论文关于页面。

为了让Geneva能够直接利用GFW对ESNI审查进行训练,我们写了一个自定义的插件来执行以下步骤。

  1. Geneva在位于墙外的TCP服务器上随机开放一个端口。随机开放端口是为了避免此前审查的残留。
  2. Geneva驱动一个位于中国境内的TCP客户端连接到服务器。
  3. 客户端发送一个带有加密SNI(ESNI)扩展的TLS 1.3 ClientHello。
  4. 客户端休眠2秒,等待GFW审查机制启动。
  5. 客户端发送一个简短的测试消息"test"来测试是否已经被审查。
  6. 重复步骤4和5。
  7. 服务器确认是否收到了客户端发送的完整的TLS ClientHello以及测试消息。如果收到了,该策略就会得到正向的适合度奖励;如果没有收到(或者客户端在发送测试消息时超时了),该策略就会受到惩罚。

利用这个适合度函数,Geneva可以直接针对ESNI审查制度测试和训练策略。 在短短几个小时内,它就发现了多个绕过审查的策略。在本节中,我们将详细描述它们。

Geneva策略引擎在我们的Github上是开源的,所以所有这些策略都可以被任何人部署和使用。由于它们在 TCP 层运行,因此可以应用于任何需要使用 ESNI 的应用程序:随着 Geneva 的运行,即使是未经修改的网络浏览器也可以成为一个简单的审查规避工具。

请注意,Geneva不是通用的翻墙软件,也不提供任何额外的加密、隐私或保护。它是一个测试版的研究原型,而且它并没有针对速度进行优化。使用这些策略,风险自担。

策略

我们在48小时的时间里,从客户端和服务器端对Geneva进行了训练。我们总共发现了6种策略来打败对ESNI的封锁机制。其中有4个可以在服务器端使用,所有6个都可以在客户端使用。

以下是TCP层的策略,只需部署在客户端,即可击败针对ESNI的封锁。

策略 1: 三重 SYN

第一种客户端策略的工作原理是用三个SYN数据包启动TCP的三次握手,这样第三个SYN的序列号就是错误的。

在Geneva的语法中,这个策略是这样的:

[TCP:flags:S]-duplicate(duplicate,tamper{TCP:seq:corrupt})-| \/

这种策略是对于GFW的跳出同步攻击(synchronization attack)。GFW会转而追踪这个新的错误序列号,而错过ESNI请求。

这个策略也可以部署在服务端:

[TCP:flags:SA]-tamper{TCP:flags:replace:S}(duplicate(duplicate,tamper{TCP:seq:corrupt}),)-| \/

虽然这种策略使得服务器永远不会发送SYN+ACK数据包,但这并不会破坏三次握手。在三次握手过程中,服务器没有像往常一样发送一个SYN+ACK数据包,而是发送三个SYN数据包(第三个数据包的校验和是错误的)。

第一个SYN数据包的作用是启动TCP的同步打开(Simultaneous Open),这是所有主流操作系统都支持的一个古老的TCP功能,用于处理两个TCP栈同时发送SYN数据包的情况。当客户端收到服务器发送的SYN时,客户端发送一个 SYN+ACK 数据包,服务器响应一个 ACK 来完成握手。这样就有效地将传统的三次握手改为四次握手。带有损坏序列号的SYN使GFW跳出同步(但被客户端忽略),成功地击败了封锁机制的同时并不伤害到原有连接。

策略2:四字节分割

我们发现的下一个策略也可以从客户端或服务器使用。在这个策略中,客户端将ESNI请求分为两段TCP发送,第一段TCP的长度小于或等于4个字节。

客户端策略的Geneva语法是这样的: [TCP:flags:PA]-fragment{tcp:4:True}-| \/

这已经不是Geneva第一次发现分段策略,但令人惊讶的是,这种策略在中国竟然有效。毕竟防火长城拥有著名的TCP重建能力已经有近十年了(见brdgrd)。TLS头是5个字节长,所以我们推测,像这样将TLS头分割到多个数据包中,打破了GFW将包含ESNI的数据包识别为TLS的能力。这对GFW如何通过指纹识别连接有有趣的影响:它表明GFW中负责识别的组件并不能从TCP层面中重组所有的上层协议。这一理论得到了Geneva过去所发现的其他基于分段的策略的支持(详见这篇论文)。

这个策略也可以从服务器端触发。通过在三次握手期间减少TCP窗口大小,服务器可以强制客户端分割请求。在Geneva的语法中,可以通过以下方式实现:[TCP:flags:SA]-tamper{TCP:window:replace:4}-| \/

策略3:TCB Teardown

下一个策略是经典的TCB(TCP Control Block)Teardown:客户端向连接中注入一个带有错误的校验和的RST数据包。这将欺骗GFW,使其认为连接已被中断。

在Geneva的语法中,这个策略看起来是这样的: [TCP:flags:A]-duplicate(,tamper{TCP:flags:replace:RA}(tamper{TCP:chksum:corrupt},))-| \/

TCB Teardowns并不是什么新鲜事:Khattak et al.在几乎十年前就已经演示过了,Geneva过去也多次发现了针对GFW的Teardown攻击

令人惊讶的是,这种策略也可以从服务器端诱导。 在三次握手过程中,服务器可以发送一个带有错误ACK的SYN+ACK数据包,从而诱导客户端发送RST。这将导致RST的序列号不正确(ACK为0,但仍足以引起TCB Teardown)。

策略4:FIN+SYN

下一个策略似乎是另一种角度的跳出同步攻击。在这一策略中,客户端(或服务器)发送一个数据包,在三次握手过程中同时设置 FIN SYN。 客户端的Geneva语法是[TCP:flags:A]-duplicate(tamper{TCP:flags:replace:FS},)-| \/ 服务端的Geneva语法是 [TCP:flags:SA]-duplicate(tamper{TCP:flags:replace:FS},)-| \/

在过去,我们发现GFW在对其他协议进行审查时,对FIN数据包有特殊的处理。 似乎FIN的出现会使GFW立即同步到对当前连接的跟踪,但SYN的出现会使它认为实际的序列号与实际值相差+1,使GFW与实际连接偏离1。

我们对以上假设进行了测试:在这个策略运行的时候,将客户端实际请求的序列号增加1后,连接被阻断了。

在服务端,这个策略不需要FIN就可以运行。

策略5:TCB Turnaround

TCB Turnaround策略很简单:在客户端发起三次握手之前,首先向服务器发送一个SYN+ACK数据包。SYN+ACK使让GFW混淆了客户机和服务器的角色,从而使客户端能够不受阻碍地进行通信。TCB Turnaround攻击在哈萨克斯坦仍然有效,但在GFW上,TCB Turnaround攻击对其他协议不起作用。

在Geneva的语法中:[TCP:flags:S]-duplicate(tamper{TCP:flags:replace:SA},)-| \/

该策略只适用于客户端,因为当SYN数据包到达服务器时,GFW已经知道哪一方是客户端了。

策略6:TCB 跳出同步

最后,Geneva发现了简单的基于载荷的TCB跳出攻击。从客户端,注入一个带有载荷和错误的校验和的数据包就足以使GFW跳出对当前连接的同步。 Geneva在研究GFW对其他协议的审查时,已经发现过这一策略了。

Geneva的语法是这样的 [TCP:flags:A]-duplicate(tamper{TCP:load:replace:AAAAAAAAAA}(tamper{TCP:chksum:corrupt},),)-|

这个策略不能在服务器端使用。

对审查规避策略的总结

我们已经找到6种可以部署在客户端,和4种可以部署在服务端的审查规避策略。 每一种都有近乎100%的可靠性,并可以用于规避针对ESNI的审查。 遗憾的是,这些策略并非是一劳永逸的:就像猫捉老鼠一般,防火长城也会继续提升其审查能力。

未解决的问题

我们仍不清楚为何会观察到不同的残余审查时长。 与所有类似研究一样,在与我们所用节点不同的中国地区,可能存在着不同于我们所观察到的审查方式。 如果你观察到了不同于上述的审查方式,或者我们的审查规避策略对你并不奏效, 尽请联系我们。

鸣谢

我们想在此感谢所有在riseup留言板上提问,反馈和建议的匿名人士。 这些评论帮助我们给予社区所最关心的问题更高的优先级,并从而加速了我们的研究。

我们还感谢OONI和OTF社区所有人的支持。

联系我们

Geneva 团队:

GFW Report:

iYouPort:

这篇报告首发于censorship.ai。我们在iyouport.orggfw.reportnet4peoplentc.party上同步更新了这篇报告。

如何部署一台抗封锁的Shadowsocks-libev服务器

source: https://gfw.report/blog/ss_tutorial/zh/#comments

这篇教程记录了如何安装,配置并维护一台Shadowsocks-libev服务器。 这篇教程的亮点在于, 按照这里的配置建议,你的Shadowsocks-libev服务器可以抵御各种已知的攻击, 包括来自GFW的主动探测和封锁以及partitioning oracle攻击。 我们还在教程的最后加入了常见的有关Shadowsocks-libev部署的常见问题。

我们致力于更新和维护这篇教程。如果今后发现了新的针对Shadowsocks-libev的攻击,我们将在第一时间在这篇教程中加入缓解攻击的办法。 因此请考虑将这个页面加入到你的收藏夹中。 另外,我们希望这篇教程对技术小白同样友好,因此如果你在任何步骤卡住了,请联系我们,或在下方评论区留言。我们会对教程作相应改进。

安装

安装Snap应用商店

通过Snap应用商店安装Shadowsocks-libev是官方推荐的方式。

  • 如果你的服务器运行Ubuntu 16.04 LTS及以上的版本,Snap已经默认安装好了。
  • 如果你的服务器运行了其他的Linux发行版,你只需跟着对应的发行版安装Snap core

现在来检测一下你的服务器已经安装了需要的snapd和Snap core:

sudo snap install core

安装Shadowsocks-libev

现在我们安装最新的Shadowsocks-libev:

sudo snap install shadowsocks-libev --edge

配置

下面是我们推荐的Shadowsocks-libev服务器配置:

{
    "server":["::0","0.0.0.0"],
    "server_port":8388,
    "encryption_method":"chacha20-ietf-poly1305",
    "password":"ExamplePassword",
    "mode":"tcp_only",
    "fast_open":false
}

注意,你需要把里面的ExamplePassword替换成一个更强的密码。 强密码有助缓解最新发现的针对Shadowsocks服务器的Partitioning Oracle攻击。 你可以用以下命令在终端生成一个强密码:openssl rand -base64 16

你还可以考虑将server_port的值从8388改为102465535之间的任意整数。

现在打开通过Snap安装的Shadowsocks-libev默认的配置文件:

sudo nano /var/snap/shadowsocks-libev/common/etc/shadowsocks-libev/config.json

将上方替换过密码的配置信息复制粘贴到配置文件后, 按Ctrl + x退出。 退出时,文本编辑器将问你"Save modified buffer?",请输入y然后按回车键。

可以看到,通过Snap安装的Shadowsocks-libev默认的配置文件路径太长了,不便于记忆。同时默认配置路径又没有在官方文档中标出。 我们因此建议你收藏此页面,以备今后查找。

防火墙

我们使用ufw来管理Shadowsocks服务器的防火墙。

在基于Debian的服务器上,可以通过如下命令安装ufw

sudo apt update && sudo apt install -y ufw

然后开放有关sshShadowsocks-libev的端口。 请注意,以下命令假设你在/var/snap/shadowsocks-libev/common/etc/shadowsocks-libev/config.json中的server_port的值为8388。 如果你的server_port用了其他的值,请对以下命令作相应的修改:

sudo ufw allow ssh
sudo ufw allow 8388/tcp

现在我们启动ufw:

sudo ufw enable

启动时如果弹出Command may disrupt existing ssh connections. Proceed with operation (y|n)?,请输入y并按回车键。

最后,请用sudo ufw status检查一下你的配置是否和下面的一样:

Status: active

To                         Action      From
--                         ------      ----
SSH                        ALLOW       Anywhere
8388/tcp                   ALLOW       Anywhere
SSH (v6)                   ALLOW       Anywhere (v6)
8388/tcp (v6)              ALLOW       Anywhere (v6)

运行Shadowsocks-libev

现在我们启动Shadowsocks-libev:

sudo systemctl start snap.shadowsocks-libev.ss-server-daemon.service

记得设置Shadowsocks-libev开机自启动:

sudo systemctl enable snap.shadowsocks-libev.ss-server-daemon.service

维护

检查运行状态和日志

以下命令可以查看Shadowsocks-libev的运行状态:

sudo systemctl status snap.shadowsocks-libev.ss-server-daemon.service

如果你看到绿色的Active: active (running),那么你的Shadowsocks-libev服务器就在正常的运行; 如果你看到红色的Active: failed,请用跳至如下命令journalctl -u snap.shadowsocks-libev.ss-server-daemon.service的尾部查看问题出在哪里了。

重新加载配置文件

每当你修改过配置文件后,请用如下命令重启Shadowsocks-libev以加载修改后的文件:

sudo systemctl restart snap.shadowsocks-libev.ss-server-daemon.service

常见问题

Q:为什么我用了教程里的配置,服务器还是被封了?

A: 通常来讲,这种事情不会发生,因为通过这篇教程配置的Shadowsocks-libev服务器已经可以抵御已知的所有来自GFW的主动探测。但如果你的服务器确实被封锁了,那么很有可能审查者使用了未知的攻击手段。请将你的封锁情况汇报给我们,我们会认真地调查。

Q: 我应不应该从发行版的仓库下载安装Shadowsocks-libev?

A: 发行版仓库里的Shadowsocks-libev不一定是最新版的。比如,截止2021年1月,Debian buster仓库的Shadowsocks-libev的版本为v3.2.5。而这个版本的Shadowsocks-libev是不够防御来自GFW的主动探测的(详见Figure 10)。

Q: 我应该怎样更新用Snap安装的Shadowsocks-libev?

A: 因为Snap会每天自动更新通过其安装的软件,因此通常情况下你不需要手动更新。如若需要手动更新,请用: sudo snap refresh

Q: 为什么用chacha20-ietf-poly1305作为加密方式?

A: 因为它是其中一种AEAD ciphers。而AEAD ciphers可以抵御来自GFW的主动探测。它同时也是Shadowsocks-libev及OutlineVPN的默认加密方式。

Q: 我应该用Shadowsocks的stream cipher吗?

A: 完全不应该。因为Shadowsocks的stream cipher有着不可接受的安全隐私漏洞,并且可以被准确的主动探测。如Figure 10所示,即使是最新版的Shadowsocks-libev,在使用stream cipher时同样可以被准确识别。更具灾难性的是,在不需要密码的情况下,攻击者可以完全解密被记录下来的Shadowsocks会话

Q: 但为什么我用的机场仍在使用stream cipher?

A: 这清楚地说明你的机场缺乏安全意识和安全措施。请把这篇教程这个演讲,和这篇总结,分享给你的机场主。

Q: 我应该把配置中的server_port改为像443这样的常见端口吗?

A: 不应该。因为不论你使用哪个端口,GFW都会检测并怀疑你的Shadowsocks流量。

Q: 为什么配置文件使用tcp_only模式?

A: 这是为了缓解最新发现的Partitioning Oracle攻击,文中指出 “Shadowsocks的开发者们已经采取措施,禁用了本默认开启的UDP代理模式(“the Shadowsocks developers took immediate action to disable UDP proxying where it was enabled by default.")。当然,如Vinicius所指出的,如果你使用了长的随机密码,那么partitioning oracle攻击就不能成功。因此也就不需要禁用UDP代理模式。开启UDP代理模式可能会让经过Shadowsocks代理的视频通话质量更佳。

Q: 为什么配置文件禁用了fast_open?

A: 我们推荐你阅读这里的讨论

联系

这篇报告首发于GFW Report。我们鼓励您或公开地或私下地分享您的评论或疑问。我们私下的联系方式可见GFW Report的页脚。

 

我家电视机正在监视所有连网设备

source: https://www.v2ex.com/t/772523#reply87

之前觉得电视有点慢,看了一下都有什么后台服务开着。发现有个东西叫”勾正数据服务”,完全不知道是干什么的。

Picture1.png

电视是安卓系统,抓包研究了一下,发现这东西每隔 10 分钟扫一遍我全家连网的设备,把 hostname 、mac 、ip 甚至网络延迟时间全传回去了,还探测周围的 wifi SSID 名称、mac 地址也打包传到这个 gz-data .com 的域名。

也就是说,家里有什么智能设备、手机在不在家、谁来家里连网了、周围邻居 wifi 叫什么名,随时采集上传,确定这不是间谍服务???

Picture3.png

Picture4.png



代码分析如下:

这个勾正数据服务 app 对应 TVAC.apk ,解开看功能基本都在这个动态加载的 jar 里面:

Picture2.png

里面代码挺多,有个逻辑是 arp 扫描局域网、上报所有联网设备信息:

Picture5.png

Picture6.png

Picture7.png

Firefox 火狐瀏覽器打開 DoH 解決 DNS 污染問題教學

近年 DNS 污染問題日趨嚴重,Firefox 火狐瀏覽器針對這問題,可以從核心 DoH (DNS over HTTPS 縮寫) 給啟用,並且以加密方式針對 DNS 進行請求,解決網址域名被 DNS 汙染而無法訪問情況,若有遇到這問題朋友來參考教學讓你免翻牆造訪無法打開網站。

 

打開 Firefox 火狐瀏覽器,直接於網址列輸入 about:config 按下確認鍵,並且出現黃色驚嘆號告知“我發誓,我一定會小心的”警告標語,確認沒問題按下「接受風險並繼續」進入設定頁。

 

Firefox 火狐瀏覽器打開 DoH 解決 DNS 污染問題教學

 

接著於頁面頂部搜索框輸入 network.trr 找到「network.trr.mode」默認是 0 改為 2 (表示使用 DoH 否則退回傳統連線方式),下方的「network.trr.uri」可改為支援 DoH 未污染伺服器位置,或採用下列網址預設進行連線 https://mozilla.cloudflare-dns.com/dns-query。

 

Firefox 火狐瀏覽器打開 DoH 解決 DNS 污染問題教學

 

依據上方步驟做表示已經將火狐瀏覽器 DoH 功能打開,就可以免翻牆造訪因為 DNS 汙染問題無法打開網站,但切記網址前方要添加 https:// 加密連結否則無法使用 DoH 功能。

港版國安法︱台灣民進黨及國防部招募軍人官網疑被封

再多至少2個台灣網站以香港伺服器瀏覽時無法進入,其中一個為民進黨官網。

昨日台灣基督長老教會網站懷疑被封,今日(25日)再有至少兩個台灣網站以香港伺服器瀏覽時無法進入,其中一個為民進黨官網。中共喉舌《文匯報》今引述消息指,台灣基督長老教會曾涉網台D100主持傑斯的「國安法」案件。

台灣基督長老教會 被指助抗爭者逃亡

台灣基督長老教會網站昨晚起無法經香港伺服器連結。《文匯報》引述消息報道,警方在調查傑斯案件時懷疑基督長老教會也牽涉其中,其中傑斯發起的「千個爸媽台灣助學」計劃,以眾籌方式幫助逃台示威者,資金來源模糊但金額驚人,短短數月透過眾籌取得逾千萬元資金,當中有400萬元被轉到台灣基督長老教會戶口。原名尹耀昇的傑斯去年11月及今年2月,兩度因洗黑錢及資助分裂國家等罪名,遭警方國安處拘捕,早前申請保釋被拒,至今仍還柙。

使用 Docker 快速搭建 Telegram 專用代理 MTProxy-Go

來源:https://www.jkg.tw/p3526/

之前有一篇使用一鍵快速腳本搭建 Telegram 專用代理 MTProxy-Go,不過好像原作者被抓去喝茶還是什麼鬼的 🥸

反正那個腳本已經年久失修,不太能正常使用了,有些上游路徑已經改過,於是另外找了 Docker 版本

Docker 版本跟之前腳本相比起來搭建出錯機率小很多,因為別人都包好了,日後更新起來也很容易

另外可能還會有人問 Telegram 不就直接可以正常使用嗎?為什麼還要翻牆代理?

在台灣確實可以正常使用,但是台灣連去 Telegram 新加坡機房的速度時好時壞,有時候圖片或者影片會跑好久

為了要有更好的使用體驗,如果能自己搭一個海外 VPS 會改善非常多,像是 GCP 的台灣或者 AWS 的日本都能有不錯的連線穩定度


安裝 Docker Community 穩定版

雖然這安裝 Docker 的部分已經講過很多次,不過還是再寫一遍

如果你已經有 Docker 執行環境就可以跳過



一樣先 SSH 連到伺服器上,安裝 Docker 跟需要的軟體,以下適用於 Debian 與 Ubuntu
# 先完整更新一下系統 $ sudo apt update && sudo apt full-upgrade -y # 安裝一下等下會需要用到的軟體 $ sudo apt install curl -y




更新好以後,使用 Docker 官方的一鍵安裝腳本
$ curl -fsSL https://get.docker.com/ | sh


接著稍等片刻,他會自動安裝到最新穩定版的 Docker

安裝完畢後,設定一下權限
# 將你帳號加入 docker 群組 $ sudo usermod -aG docker $USER # 退出重連一次 $ exit




以上就完成執行 Docker 基本環境安裝


MTProxy-Go 無廢話直接跑起來 Docker 版

MTProxy-Go 相關的在 Docker Hub 上面有很多,後來看到以下這個版本沒太多廢話

直接兩條指令就可以跑起來,舒舒服服,所以就直接用它啦!

https://hub.docker.com/r/p3terx/mtg


$ docker run --rm p3terx/mtg generate-secret tls -c shopee.tw


上面這條指令可以幫你快速產生註冊一組 Secret Key 並開啟 TLS 混淆,讓你假裝好像在連 shopee.tw

當然你也可以改成其他網站,像是如果你要在中國使用,就不要填 facebook.com or google.com 之類的

輸出的 Key 請拷貝起來,下面馬上就會用到


$ docker run -d \ --name mtg \ --restart unless-stopped \ --dns 1.1.1.2 \ -p <PORT>:3128 \ p3terx/mtg \ run <SECRET>


上面這行指令要自己改的只有 PORT 與 SECRET 兩個參數需要改掉

PORT 就填自己要開的伺服器連接埠,SECRET 就是從上面指令產生的 Secret Key 拷貝過來即可

實際指令大概會長下面這樣:
$ docker run -d \ --name mtg \ --restart unless-stopped \ --dns 1.1.1.2 \ -p 9958:3128 \ p3terx/mtg \ run ee78442ab5f0965ae521b60b691e46b932351f75796562652e146f2d


以上一行指令一按下去就會直接跑一個 MTProxy-Go 的代理伺服器起來了,非常的方便!



接著記得開個防火牆連接埠
# Port 請改成你自己實際使用的 $ sudo iptables -I INPUT -p tcp --dport 9958 -j ACCEPT # 裝個 iptables-persistent 保存規則 $ sudo apt install iptables-persistent -y



給 Telegram 連線的連結

而要丟給 Telegram 連線的連結可以套用以下規則https://t.me/proxy?server=<YOUR_IP>&port=<PORT>&secret=<SECRET>


YOUR_IP 請改為你的伺服器外網公共 IP

PORT 跟 SECRET 就如上個步驟你設定的那樣填,你實際多少就填多少

實際完成後大概會是長下面這樣:
https://t.me/proxy?server=101.101.101.101&port=9958&secret=ee78442ab5f0965ae521b60b691e46b932351f75796562652e146f2d




完成後的連結直接丟到 Telegram 裡面,按一下即可新增連線

日後要更新也很簡單,建議可以另外新建一個 WatchTower 全自動無人值守升級



以上搭一個私人 Telegram 專用代理 MTProxy-Go 就是這麼簡單 🖖

如何测试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的网站。