- चीन का Great Firewall(GFW) ने नवंबर 2021 की शुरुआत से पूरी तरह एन्क्रिप्टेड बायपास ट्रैफिक को रीयल-टाइम में निष्क्रिय रूप से पहचानकर ब्लॉक करने की नई सेंसरशिप तकनीक तैनात की
- Shadowsocks, VMess, Obfs4 जैसे ऐसे looks like nothing प्रोटोकॉल भी ब्लॉकिंग के दायरे में आए, जिनमें पूरा payload रैंडम जैसा दिखता है
- GFW एन्क्रिप्टेड ट्रैफिक को डिक्रिप्ट किए बिना, सामान्य प्रोटोकॉल fingerprint, bit ratio, और ASCII अक्षरों के अनुपात व स्थिति जैसे exception heuristics से पहले उन कनेक्शनों को अलग करता है जो सामान्य दिखते हैं
- यदि अनुमानित detection algorithm को वास्तविक ट्रैफिक पर लागू किया जाए, तो लगभग 0.6% वैध कनेक्शन ब्लॉक हो सकते हैं; इससे संकेत मिलता है कि GFW collateral damage कम करने के लिए कुल कनेक्शनों के 26% और केवल कुछ data center IP ranges की निगरानी करता है
- इस विश्लेषण पर आधारित बायपास रणनीतियाँ प्रमुख censorship circumvention tools के साथ साझा की गईं, जनवरी 2022 के बाद व्यापक रूप से तैनात हुईं, और फ़रवरी 2023 तक चीन में अब भी प्रभावी थीं
नवंबर 2021 में सामने आई निष्क्रिय पहचान-आधारित ब्लॉकिंग
- पूरी तरह एन्क्रिप्टेड circumvention protocols, TLS की तरह plaintext handshake से शुरू नहीं होते, बल्कि इस तरह डिज़ाइन किए जाते हैं कि कनेक्शन का हर byte रैंडम से अलग न पहचाना जा सके
- VMess, Shadowsocks, Obfs4 ऐसे looks like nothing approach इस्तेमाल करने वाले प्रमुख प्रोटोकॉल हैं
- 6 नवंबर 2021 को चीन के इंटरनेट उपयोगकर्ताओं ने Shadowsocks और VMess servers के ब्लॉक होने की सूचना दी, और 8 नवंबर को Outline developers ने चीन से आने वाले उपयोग में तेज गिरावट देखी
- यह ब्लॉकिंग 8 से 11 नवंबर 2021 के बीच हुई, जो चीनी कम्युनिस्ट पार्टी की 19वीं केंद्रीय समिति के 6वें पूर्ण अधिवेशन के समय के साथ मेल खाती है
- चीन मई 2019 से Shadowsocks servers की पहचान के लिए निष्क्रिय ट्रैफिक विश्लेषण और सक्रिय probing दोनों का उपयोग कर रहा था, लेकिन यह पहला मामला था जिसमें पूरी तरह एन्क्रिप्टेड proxies को केवल निष्क्रिय ट्रैफिक विश्लेषण से बड़े पैमाने पर रीयल-टाइम ब्लॉक किया गया
GFW की पहचान पद्धति
- GFW “पूरी तरह एन्क्रिप्टेड ट्रैफिक” को सीधे परिभाषित नहीं करता, बल्कि पहले उन कनेक्शनों को बाहर करता है जिनके पूरी तरह एन्क्रिप्टेड ट्रैफिक न होने की संभावना अधिक होती है
- कम से कम 5 समूहों में बँटी हुई साधारण लेकिन प्रभावी exception heuristics इस्तेमाल की जाती हैं
- सामान्य प्रोटोकॉल के fingerprint
- तय किए गए bit ratio का उपयोग करने वाला मोटा entropy test
- पहले TCP payload में printable ASCII अक्षरों का अनुपात
- ASCII अक्षरों की स्थिति
- लगातार आने वाले ASCII अक्षरों की अधिकतम संख्या
- जो ट्रैफिक इन exception rules में नहीं आता, वही ब्लॉकिंग का लक्ष्य बनता है
- क्योंकि GFW एक black-box system है, इसलिए अनुमानित नियम पूरी तरह सटीक न भी हों
मापन परिणाम और collateral damage की संभावना
- शोधकर्ताओं ने internet scanning से जाँचा कि GFW किस ट्रैफिक और किन IP addresses का निरीक्षण करता है
- उन्होंने अनुमानित GFW detection algorithm को CU Boulder के network tap से जुटाए गए वास्तविक ट्रैफिक पर लागू कर उसकी coverage और false positive की संभावना का मूल्यांकन किया
- अनुमानित नियम GFW द्वारा वास्तव में इस्तेमाल किए जाने वाले नियमों से काफ़ी हद तक मेल खाते पाए गए
- यदि इस detection algorithm को व्यापक रूप से लागू किया जाए, तो network tap के कुल कनेक्शनों में लगभग 0.6% वैध internet traffic होने के बावजूद ब्लॉक हो सकता है
- false positive से होने वाली overblocking कम करने के लिए, GFW रणनीतिक रूप से कुल कनेक्शनों के केवल 26% की निगरानी करता है और लोकप्रिय data centers की कुछ खास IP ranges को ही निशाना बनाता है
सक्रिय probing और बायपास रणनीतियाँ
- नई निष्क्रिय सेंसरशिप पद्धति, GFW की मौजूदा active probing प्रणाली के समानांतर काम करती है
- active probing system भी इसी traffic analysis algorithm पर निर्भर करता है और इसके अलावा packet length आधारित नियम लागू करता है
- नई ब्लॉकिंग से बचने वाली बायपास रणनीतियाँ, GFW द्वारा proxy servers की पहचान करने और बाद में active probing करने की प्रक्रिया को भी रोक सकती हैं
- शोधकर्ताओं ने Shadowsocks, V2Ray, Outline, Lantern, Psiphon, Conjure जैसे कई censorship circumvention tools के developers के साथ अपने निष्कर्ष और बायपास सुझाव ज़िम्मेदारी से साझा किए
- ये बायपास रणनीतियाँ जनवरी 2022 के बाद व्यापक रूप से अपनाई और तैनात की गईं, लाखों उपयोगकर्ताओं को नई सेंसरशिप पद्धति से बचने में मदद मिली, और फ़रवरी 2023 तक अपनाई गई रणनीतियाँ चीन में अब भी प्रभावी थीं
2 टिप्पणियां
लगता है कि मूल लेख, टिप्पणियाँ और सारांश वाला लेख एक-दूसरे से अलग हैं।
Hacker News की राय
लेख में VPN का ज़रा भी ज़िक्र नहीं है, इसलिए पहले लगा कि बस VPN इस्तेमाल कर लेना चाहिए। लेकिन Wikipedia के GFW लेख में लिखा है कि चीन में VPN का उपयोग अंतरराष्ट्रीय इंटरनेट तक पहुँच तो देता है, पर इससे कानूनी जोखिम भी हो सकता है।
2017 में चीनी सरकार ने बिना अनुमति वाली सभी VPN सेवाओं को अवैध घोषित कर दिया था, और उदाहरण के तौर पर University of Washington की छात्रा Vera Zhou को तब Xinjiang के एक internment camp में भेज दिया गया था जब वह वहाँ अपने Hui माता-पिता से मिलने गई थीं और VPN के जरिए स्कूल असाइनमेंट तक पहुँच रही थीं। यह अक्टूबर 2017 से मार्च 2018 तक चला, और उसके बाद वह house arrest में रहीं तथा सितंबर 2019 तक अमेरिका वापस नहीं लौट सकीं।
周月明(Vera Yueming Zhou) को शायद University of Washington की वेबसाइट तक पहुँचने के लिए VPN इस्तेमाल करने की वजह से नहीं, बल्कि धार्मिक अल्पसंख्यक होने के कारण चीन के internment camp में भेजा गया था।
उस समय Kuytun पुलिस ने digital surveillance tools के जरिए पकड़ा कि Vera ने VPN का उपयोग करके अपने विश्वविद्यालय के Gmail account जैसी वेबसाइटों तक पहुँचने की कोशिश की थी, और मुस्लिम अल्पसंख्यक समूह की सदस्य होने के कारण इसे “धार्मिक उग्रवाद का संकेत” माना जा सकता था।
वियतनाम में पूरे एक साल के दौरान पुलिस ने मेरा passport अपने पास रखा हुआ था, इसलिए मैं सावधान था। लेकिन कुछ दिन बाद मैंने बस कुछ मिनट के लिए NYT खोला, और इंटरनेट लगभग 3 घंटे के लिए कट गया। अगली बार 24 घंटे के लिए कट गया, तब समझ आया कि यह कोई संयोगवश outage नहीं था।
कनेक्शन तुरंत नहीं कटा; कुछ मिनट लगे, और मुझे काफ़ी यक़ीन था कि मेरे traffic को देखने के लिए कोई dedicated censor बैठा हुआ था।
मैं VPN इस्तेमाल नहीं कर रहा था और जानबूझकर traffic को खुला छोड़ा था, लेकिन मुझे पता था कि VPN से जुड़ने पर और शक होगा, इसलिए बाद में email चेक करने के लिए VPN का उपयोग केवल थोड़ी देर के लिए, वह भी कैफ़े में, करता था।
कुछ लोग विदेशी games खेलते समय latency कम करने के लिए इसका उपयोग करते हैं। असली समस्या यह है कि VPN connection आसानी से block हो जाते हैं; कानूनी समस्या को लेकर बहुत डर का माहौल नहीं होता।
हाँ, “white paper protests” के दौरान शायद कुछ इलाकों की पुलिस लोगों के घर जाकर यह जाँच रही थी कि उनके फ़ोन में VPN है या नहीं।
ऐसा लगता था कि युवा और tech-savvy लोगों में लगभग सभी के पास VPN था, और यह उतना ही आम और हल्की बात थी जैसे highway पर speed limit से 10mph ज़्यादा चलाना।
ज़्यादातर लोगों को सिर्फ VPN इस्तेमाल करने भर से प्रताड़ित नहीं किया जाता; यह ज़्यादा उस बहाने की तरह लगता है जिसका उपयोग सरकार तब करती है जब वह किसी ऐसे व्यक्ति को हिरासत में लेना चाहती है जिसे वह पहले से निशाना बना चुकी हो।
यह मामला VPN के उपयोग से जुड़े कानूनी जोखिम का उदाहरण कम, और किसी दूसरे कारण से पहले से निशाने पर रहे व्यक्ति को सज़ा देने का उदाहरण ज़्यादा लगता है।
यानी VPN प्रतिबंध कानून पूरी तरह हटा भी दिए जाएँ, तब भी व्यवहार में शायद कुछ नहीं बदलेगा।
महामारी से पहले मैं लंबे समय तक चीन में रहा और GFW के खिलाफ काफ़ी प्रयोग किए। मैं हमेशा हैरान होता था कि shadowsocks या मनमाने SSH tunnel को वे कितनी जल्दी पकड़ लेते थे।
आमतौर पर 48 घंटे के भीतर IP बदलना पड़ता था, और यह रिपोर्ट तो अब ऐसा संकेत देती है कि वे तुरंत पकड़ लेते हैं।
सबसे स्थिर तरीका यह था कि Shenzhen से Hong Kong में जाने वाली physical line का उपयोग किया जाए, और चीन के भीतर घूमते समय VPN से उसी Shenzhen gateway से जुड़ा जाए।
मेरी याद के अनुसार यह हमेशा काम करता था, इसलिए मुझे लगता था कि VPN traffic analysis और blocking का ज़्यादातर हिस्सा GFW की सीमा पर होता है और देश के भीतर कम, लेकिन अब यह जानकारी पुरानी हो सकती है।
वह तुरंत block हो गया और client connect नहीं कर पाया। कोशिश करने से पहले भी कई अज्ञात IP उससे connect करने की कोशिश कर रहे थे।
GFW कितनी बारीकी से सब कुछ कवर करता है, यह देखकर हैरानी हुई। अफ़सोस यह है कि अगर आपको स्थिर internet connection चाहिए, तो चीन में काम करते हुए यात्रा करना बहुत मुश्किल हो जाता है।
roaming traffic आपके home carrier तक tunnel होकर जाता है, और किसी वजह से उस tunnel की बिल्कुल जाँच नहीं होती।
eSIM आने के बाद अब कुछ ही मिनटों में roaming SIM खरीदी जा सकती है और फ़ोन में तुरंत इस्तेमाल की जा सकती है।
ऐसा लगता था कि दखल सीमा पर नहीं बल्कि देश के भीतर हो रहा है, लेकिन असल में यह कैसे किया जाता था, पता नहीं।
Hangzhou की तकनीकी क्षमता को देखते हुए, संभव है कि वहाँ का regional ISP ज़्यादा सक्षम था और अधिक आधुनिक countermeasures इस्तेमाल कर रहा था।
लगभग 20 साल पहले मैं एक ऐसी कंपनी में काम करता था जिसके Shanghai साइट पर कर्मचारी थे, और मुझे शुरुआती GFW से जूझना पड़ा था
हर सुबह जब चीनी सहकर्मी अपना mail client खोलते थे, तो वह विदेश में मौजूद हमारे server से connect करता था; पहला व्यक्ति आमतौर पर ठीक रहता था, लेकिन उसके बाद आने वालों का connection fail हो जाता था
उस समय GFW के बारे में लगभग कुछ भी पता नहीं था और यह आज जितना स्मार्ट भी नहीं था, लेकिन हमने देखा कि POP connection कुछ मिनट बाद जल्दी block हो जाता था; लगता था कि बीच में कोई धीमा firewall rule लागू हो रहा है, और यह कुछ हद तक random था, इसलिए हमने अनुमान लगाया कि firewall configuration एकरूप नहीं थी
POPS/SMTPS पर जाने से कुछ समय तक सुधार हुआ, लेकिन random block फिर भी होते रहे; आखिरकार जब server पर well-known ports की जगह कई random ports पर POP/SMTP connections स्वीकार करने लगे, तो कुछ साल बाद system बदलने तक समस्या गायब हो गई
मैंने ज़्यादा गहराई से नहीं देखा, लेकिन मेरा अनुमान था कि inspection के लिए connection reroute किया जा रहा है; अगर यह सच है, तो access किए जा रहे data के साथ industrial espionage भी किया जाए तो हैरानी नहीं होगी
यह दिलचस्प है कि वे obfuscation plugin लगे Shadowsocks पर भी कार्रवाई करते हैं
2017~2019 में जब मैं चीन गया था, तब SS और v2ray का combination लगभग de facto standard जैसा था
उस समय जून की शुरुआत या बड़े सरकारी सम्मेलनों जैसे खास मौकों पर VPN crackdown होता था, और शायद प्रक्रिया के लिहाज़ से सटीक block करना कठिन होने के कारण, वे broadly उन चीज़ों पर रोक लगा देते थे जो VPN जैसी दिखती थीं
आमतौर पर connection हो जाता था, लेकिन speed throttling इतनी होती थी कि व्यावहारिक रूप से कुछ भी नहीं किया जा सकता था
मुझे लगता था कि एक निश्चित स्तर से अधिक complexity वाले VPN को अनौपचारिक रूप से बर्दाश्त किया जाता था, और उनका ज़्यादा ध्यान उन आसान targets को रोकने पर था जिन्हें आम लोग आसानी से इस्तेमाल कर सकें
जो कम संख्या में तकनीकी शौकीन ज़्यादा sophisticated tools इस्तेमाल करते थे, शायद वे पहले से जानते थे कि कौन इस्तेमाल कर रहा है, और मामला बड़ा होने पर सीधे पहुँचने को तरजीह देते थे
लगता है चीन को एहसास ही नहीं कि इस तरह की चीज़ों में बेकार का समय और expertise झोंककर वह खुद को कितना रोक रहा है
आंतरिक दमन तंत्र पर उसका GDP का हिस्सा लगभग उतना ही है जितना अमेरिका military पर खर्च करता है
आंतरिक सूचना विनिमय में inefficiency जोड़ने के लिए इतनी talent और संपत्ति जला देना शायद दुनिया के लिए अच्छी बात भी हो सकती है
शुरू से ही PRC के पास घरेलू information ecosystem इसलिए है क्योंकि उसने दूरदर्शिता के साथ बाहरी content को छाँटा, और वह system कई बार अपनी लागत वसूल कर चुका है
यह भी देखना चाहिए कि PRC GDP के अनुपात में military पर इतना खर्च नहीं करता
अगर इसे बर्बादी कहना है, तो कहना चाहिए कि PRC घरेलू policing पर लगभग अमेरिका जितना खर्च करता है, और अमेरिकी police कितनी militarized हो चुकी है यह सोचकर अच्छा नहीं लगता
दूसरी ओर PRC का defence spending 2% से कम है और अमेरिका का लगभग 3.5%; shadow budget के estimates जोड़ें तो भी यह लगभग 3% बनाम 6% है
बस देख लीजिए कि social media ने दुनिया भर की democracies के साथ क्या किया है
अमेरिकी democracy किसी हद तक एक doom loop में फँसी हुई है: https://www.theatlantic.com/ideas/archive/2021/04/how-stop-m...
मुझे repression पसंद नहीं, लेकिन चीन हज़ारों साल से ऐसा करता आया है, और अब यह कहने का भरोसा कम होता जा रहा है कि हमारे पास उससे बेहतर कुछ है। Citizens United, Roe v. Wade, affirmative action जैसे उदाहरण हैं, और चीन की life expectancy अभी-अभी अमेरिका से आगे निकल गई है
इसका उपयोग सीमित है, लेकिन इस तरह की system के भीतर और बाहर जानकारी ले जाने के लिए chaffing and winnowing का इस्तेमाल किया जा सकता है: https://en.m.wikipedia.org/wiki/Chaffing_and_winnowing
जिन प्रतिक्रियाओं से लगता है कि वे कभी किसी restricted देश में गए ही नहीं, वे काफ़ी मज़ेदार हैं
शायद कुछ VPN providers, जो लगभग approved shadow services जैसे हैं, काम करते हों, लेकिन यह मानना कठिन है कि वे GFW से ज़्यादा स्मार्ट हैं
मुझे पूरा यक़ीन है कि उन्हें बिना दंड के अनुमति दी गई है और उन पर नज़र रखी जाती है
अगर सरकार से आपका कोई मसला नहीं है तो ठीक है, लेकिन मसला है या नहीं, यह असली समस्या आने से पहले पता नहीं चलता
socks5, shadowsocks, WireGuard जैसी चीज़ें बहुत पहले से बेकार थीं
यह वैसा है जैसे आप घर के अंदर हों, किसी को दिखे बिना बाहर निकलना चाहते हों, लेकिन चाहे जितनी अच्छी कोशिश करें, कोशिश करना ही आपको उजागर कर देता है और आप पकड़े जाते हैं
GFW से निकलना भी ऐसा ही है, इसलिए approved VPN या बिना metering के लंबे समय तक चलने वाला RDP सबसे अच्छा विकल्प है
मैं GFW से ज़्यादा स्मार्ट हूँ या नहीं, यह नहीं जानता, लेकिन मेरे खुद के बनाए censorship-evasion tools हर बार अच्छी तरह काम करते हैं, और सबसे lazy तरीक़ा भी चल जाता है
मैंने कभी VPN provider इस्तेमाल नहीं किया
जानकारी के लिए, unmodified WireGuard अभी भी काम करता है, लेकिन लगता है कि इसे खोजने के लिए offline traffic analysis होती है; इसलिए लगभग हफ्ते में एक बार उठकर देखता था कि VPN connection टूट गया है और server का ListenPort बदलना पड़ता है
व्यक्तिगत रूप से सबसे परेशान करने वाली बात यह है कि AWS का egress traffic cost बहुत महँगा है
वे शायद यह जान सकते हैं कि VPN इस्तेमाल हो रहा है, लेकिन traffic के content की निगरानी नहीं कर पाएँगे
यह पेपर अच्छा है, लेकिन इसमें काफ़ी बारीक तकनीकी चर्चा है
यह सीधे GFW के बारे में नहीं है, लेकिन https://github.com/salesforce/ja3 जैसे प्रोजेक्ट बताते हैं कि पूरी तरह encrypted ट्रैफ़िक (TLS/HTTPS) की fingerprinting कैसे की जा सकती है
README का “How it works” सेक्शन इसे अच्छी तरह समझाता है
अगर open source firewalls भी यह करते हैं, तो GFW यह न करता हो तो उल्टा हैरानी होगी
फिर भी क्रम को नज़रअंदाज़ करके और साझा रूप से advertise किए गए TLS parameters से fingerprint बनाया जा सकता है
लिंक किए गए पेपर में cipher suite list के आधार पर Tor-obfs connections detect किए जाने की घटना का हवाला है[2][3]
[1] https://www.fastly.com/blog/a-first-look-at-chromes-tls-clie...
[2] https://gitlab.torproject.org/legacy/trac/-/issues/4744
[3] https://blog.torproject.org/ethiopia-introduces-deep-packet-...
खोजा गया algorithm इतना intuition के ख़िलाफ़ है कि लगता है जैसे इसे AI ने खोजा हो
बात कुछ ऐसी है कि अगर client द्वारा भेजा गया पहला TCP payload किसी एक exception condition को पूरा कर दे तो connection जारी रहने दिया जाता है, वरना block कर दिया जाता है
exceptions ये हैं: popcount/length ratio किसी खास range के बाहर हो, या शुरुआती 6 bytes या उससे ज़्यादा [0x20,0x7e] range में हों, या 50% से ज़्यादा bytes उस range में हों, या लगातार 20 से ज़्यादा bytes उस range में हों, या वह TLS/HTTP protocol fingerprint से मेल खाता हो
लक्ष्य असामान्य encrypted ट्रैफ़िक को छाँटना है
पहला rule encryption की IND-CPA property का फायदा उठाकर ऐसे ट्रैफ़िक को मारने की कोशिश करता है जिसमें प्रति byte लगभग 4 bits 1 पर सेट हों, यानी जो “random जैसा दिखे”
उसके बाद के rules अनुमत encrypted या compressed ट्रैफ़िक के लिए exceptions हैं
compression IND-CPA नहीं होती, लेकिन यह high entropy पैदा करती है, इसलिए पहला rule इसे पकड़ सकता है
यह तरीका काफ़ी अच्छा काम कर सकता है, और पेपर के शोधकर्ताओं ने भी इसकी पुष्टि की है
अगर CCP ने खोजा, तो संभव है कि इसे बुनियादी statistical analysis से बनाया गया हो और फिर side effects तथा collateral damage को स्वीकार्य threshold के नीचे लाने के लिए tune किया गया हो
दुनिया भर के ट्रैफ़िक का लगभग 0.6% अनजाने में block हो जाने का स्तर है
अगर शोधकर्ताओं ने खोजा, तो पेपर विस्तार से बताता है कि इन rules को खोजने के लिए किस बुनियादी statistical analysis का इस्तेमाल किया गया
high-entropy data में 1 और 0 का distribution औसत की ओर converge करता है, और encrypted data high entropy जैसा दिखता है
यह एक मोटा तरीका है, लेकिन embedded hardware पर compute करना बहुत efficient है
Ex2~4 कई non-encrypted protocols, जैसे IMAP में इस्तेमाल होने वाले ASCII text, को exception देते हैं, और ऐसे text में भी entropy काफ़ी ऊँची हो सकती है, इसलिए पहला test सांख्यिकीय रूप से अक्सर fail हो सकता है
Ex5 इसलिए ज़रूरी है क्योंकि TLS अपने स्वभाव से encrypted है और इसलिए high entropy वाला है, और HTTP को भी शायद इसलिए exception दिया गया है कि compressed uploads, जैसे images या videos, फँस न जाएँ
GFW bypass का मूल बिंदु “low entropy” होना बिल्कुल भी चौंकाने वाली बात नहीं है। high entropy लगभग हर cipher की लगभग अनिवार्य विशेषता होती है
सिद्धांत रूप से encryption जानकारी जोड़ती नहीं है, इसलिए अगर encryption से पहले compression न किया जाए, तो ऐसी virtual cipher schemes संभव हैं जो कई objective measures पर entropy को preserve करें, लेकिन encryption से पहले compression करके और फिर ciphertext को steganography-जैसी padding से भरने वाली meta-scheme के अलावा मुझे कुछ और ज्ञात नहीं
बेशक, इससे संदेश की negative entropy जितनी जानकारी leak होती है, लेकिन आम तौर पर वह ऐसी जानकारी होगी जिसे संदर्भ से निकाला नहीं जा सकता, जैसे सिर्फ इतना कि संदेश HTML+text है
तो फिर क्या TLS को base64 में encode कर देना चाहिए?
यह बात 10~12 साल पहले भी साफ़ थी
जब मैं चीन में पढ़ रहा था, हमारे स्कूल का VPN बस कुछ ही दिनों तक चलता था
लेकिन एक बहुत छोटा VPN software इधर-उधर घूमता था, और सही याद है या नहीं पता नहीं, लेकिन मुझे याद है कि कहा जाता था Falun Gong ने इसे CIA के साथ मिलकर बनाया था
उस समय यह detection से बच सकता था, और शायद लगातार IP बदलने जैसा कुछ करता था
यह दिलचस्प था कि वह tool अंतरराष्ट्रीय छात्रों के बीच “offline” कितनी तेज़ी से फैल गया
चीनी छात्रों के पास भी यह था, लेकिन उनके बीच यह कम मशहूर था
यह अब भी काम करता है या नहीं, पता नहीं: https://en.m.wikipedia.org/wiki/Freegate
[Edit] कि यह काम नहीं करता, इस बारे में एक पुरानी HN comment, और कुछ दूसरे विकल्प जो उतने ही कठिन हैं: https://news.ycombinator.com/item?id=10101965