Tor ने onion services के लिए proof-of-work defense पेश किया

 (blog.torproject.org)
2 पॉइंट द्वारा GN⁺ 2023-08-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Tor 0.4.8 में ऐसी defense जोड़ी गई है जो onion services पर DoS attack होने पर verified network traffic को प्राथमिकता देती है
  • IP address छिपाने वाली onion service संरचना में IP-based rate limiting अधूरी रहती है, इसलिए privacy को नुकसान पहुँचाए बिना client puzzle तरीका ज़रूरी था
  • जब service पर दबाव बढ़ता है, तो client को काम का प्रमाण देने के लिए धीरे-धीरे कठिन होते puzzle computation करने पड़ते हैं, और उसी स्तर के आधार पर connection priority तय होती है
  • सामान्य users के लिए शुरुआती solve time तेज़ computer पर लगभग 5ms और धीमे hardware पर अधिकतम 30ms है, इसलिए ज़्यादातर devices पर यह संभालने योग्य है
  • attack traffic बढ़ने पर required work लगभग 1 minute तक बढ़ सकता है, जिससे बड़े पैमाने पर connection attempts महंगे हो जाते हैं और वैध users को congestion के दौरान भी access का मौका मिलता है

Tor 0.4.8 की onion services PoW defense

  • Tor ने Tor 0.4.8 release के साथ onion services के लिए proof-of-work (PoW) defense को आधिकारिक रूप से पेश किया है
  • इसका लक्ष्य DoS attacks को रोकना और verified traffic को प्राथमिकता देना है
  • onion service operators को version 0.4.8 पर update करने की सिफारिश की गई है
  • onion services user privacy के लिए IP addresses छिपाती हैं, इसलिए वे DoS attacks के प्रति संवेदनशील हो सकती हैं, और पारंपरिक IP-based rate limiting से पूरी सुरक्षा नहीं मिलती

Client puzzles और priority handling

  • PoW मूल रूप से एक ticket system की तरह काम करता है जो डिफ़ॉल्ट रूप से बंद रहता है, लेकिन network stress होने पर priority queue बनाता है
  • client को onion service access करने से पहले एक छोटा puzzle solve करना होता है, ताकि वह यह साबित कर सके कि उसने एक निश्चित workload पूरा किया है
    • puzzle जितना कठिन होगा, उतना अधिक काम किए जाने का संकेत होगा
    • onion service client द्वारा दिखाए गए effort level के आधार पर connection priority तय करती है
  • अगर attacker बहुत सारे requests भेजकर onion service को flood करता है, तो .onion site तक पहुँचने के लिए आवश्यक computation effort बढ़ जाता है
    • बड़े पैमाने पर connection attempts के लिए अधिक computing resources चाहिए होते हैं
    • workload बढ़ने के साथ attacker की profitability कम होती जाती है

सामान्य users पर दिखने वाला प्रभाव

  • सामान्य users आमतौर पर एक बार में कम requests भेजते हैं, इसलिए puzzle solve करने का भार ज़्यादातर devices पर manageable रहता है
    • शुरुआती solve time तेज़ computer पर लगभग 5ms
    • धीमे hardware पर अधिकतम 30ms
    • attack traffic बढ़ने पर workload लगभग 1 minute तक बढ़ सकता है
  • यह प्रक्रिया user को दिखाई नहीं देती, और PoW solution का इंतज़ार करना धीमे network connection का इंतज़ार करने जैसा महसूस होता है
  • अगर प्रमुख sites इस तरीके को अपनाती हैं, तो targeted attacks का network speed पर पड़ने वाला नकारात्मक असर कम किया जा सकता है, और अचानक traffic spike के दौरान load balancing में मदद मिल सकती है, जिससे onion services तक पहुँच अधिक consistent और reliable बन सकती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-08-26
Hacker News की राय

  • दिलचस्प। प्रस्ताव देखने पर अपेक्षाएँ साफ़ हैं: मकसद बड़े botnet को रोकना नहीं, बल्कि script kiddies और छोटे botnet से बचाव करना है
    DoS हमले के दौरान भी जो यूज़र सच में कनेक्ट करना चाहते हैं वे पार हो सकते हैं, लेकिन इसमें कुछ मेहनत लग सकती है
    Proof-of-work algorithm के तौर पर https://github.com/tevador/equix चुना गया है, यह भी दिलचस्प है
    Bitcoin की तरह किसी static target value से नीचे जाने पर सफलता मिलने वाला तरीका नहीं है; इसमें client proof-of-work effort से “bid” करता है और जितनी ज़्यादा मेहनत लगाता है, उसकी priority उतनी बढ़ती है। इसकी व्याख्या यह है कि coin stake करने के बजाय work stake किया जाता है, इसलिए यह proof-of-stake जैसा है
    [1] https://gitlab.torproject.org/tpo/core/torspec/-/raw/main/pr...

    • CPP, यानी Client Puzzle Protocol, पहली बार सुन रहा हूँ। सोच रहा हूँ कि क्या बड़े botnet दूसरे ports पर हुड़दंग मचाकर इसे bypass कर सकते हैं
    • अच्छा होता अगर proof-of-work defense सिर्फ़ user-side resources जलाने के बजाय, user से provider तक किसी तरह का value transfer भी शामिल करता
      यह version भी अच्छा है, लेकिन value transfer जुड़ जाए तो और बेहतर लगेगा
    • अब दोनों तरफ़ की कमियाँ भी साथ आ गईं। जिसके पास सबसे ज़्यादा compute resources हैं और जो उन्हें toaster की तरह इस्तेमाल कर सकता है, वह बाकी सभी को DoS कर सकता है
      ऊपर से proof-of-work सिर्फ़ बेकार की wasteful computation है। computation मुफ्त नहीं है, और proof-of-work में खर्च होने वाला हर watt मौजूदा climate crisis को और बिगाड़ता है
      ऐसी जगह रहने वाले के तौर पर जहाँ कुछ दिनों में feels-like 120°F और actual 109°F तक जाने वाला है, विनम्रता से कहूँ तो जो भी यह सुझाव देता है कि proof-of-work किसी भी चीज़ के लिए अच्छा idea है, उसे दफा हो जाना चाहिए
      यह दिलचस्प नहीं है; यह धरती पर conspicuous consumption का सबसे खुल्लमखुल्ला उदाहरण है

  • बेहतर लेख, यानी असली technical details, यह है: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...
    चुना गया proof-of-work function equi-X लगता है

  • हैरानी है कि यह पहले क्यों नहीं जोड़ा गया, और प्रस्ताव [0] को मैंने इतना detail में नहीं पढ़ा कि अभी कह सकूँ कि क्या इससे user anonymity को प्रभावित करने वाला data बढ़ेगा। फिर भी अगर यह user-service unit के रूप में बंधा रहे और कहीं store न हो, तो ठीक लगता है
    यह भी जानना चाहूँगा कि proxied service के load और node के अपने load को यह अलग-अलग कितना कम करेगा। Access कई nodes में distribute होता है, इसलिए service side को ज़्यादा फायदा होगा लगता है
    [0]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...

    • यह बहुत पहले हो जाना चाहिए था, लेकिन “समुद्र उबल रहे हैं” चिल्लाने वालों की वजह से delay हुआ

  • अच्छा है। शायद जल्द ही DDoS defense CDN की ज़रूरत न रहे। API को Onion service के रूप में provide कर दो

  • यह तरीका पहले email spam रोकने के लिए भी propose किया गया था
    Cloudflare भी ऐसा कर सकता है। किसी busy site पर connect करने पर हर बार browser से कुछ seconds से लेकर कुछ minutes तक बेकार computations चलवाने जैसा। कुल असर शायद पूरी दुनिया की batteries चूस लेने जैसा होगा

    • Email deposit के लिए proof-of-work proposal Adam Back का Hashcash था, जिसमें partial hash collision इस्तेमाल हुआ था
      http://www.hashcash.org/
      दिलचस्प बात है कि वही Bitcoin proof-of-work mining की inspiration बना
    • Cloudflare पहले से यह करता है। “connection verify कर रहे हैं” वाली screen आती है और browser में hashes run होते हैं
    • यह ads जैसा ही है। बिना consent battery drain करता है
    • वह assessment fair नहीं है
      क्योंकि यह greenhouse gases भी atmosphere में छोड़ेगा
    • इसी concept के इर्द-गिर्द बना Bitmessage नाम का एक app था, जो अब abandoned project लगता है

  • सोच रहा हूँ कि जब proof-of-work काम करना शुरू कर दे, तब abuser को नई identity लेकर DDoS जारी रखने से क्या रोकता है
    Edit: लगता है proof-of-work client के बजाय attack झेल रही “service” unit पर set होता है

    • यह per-service लागू होता है, और स्थिति Onion service को overwhelm कर पाने से बदलकर ऐसी हो जाती है जहाँ server द्वारा request process करने की तुलना में attacker को ज़्यादा compute resources खर्च करने पड़ते हैं। इससे मदद मिलती है
    • सही। proof-of-work per-request भी है, इसलिए identity नई है या पुरानी, फर्क नहीं पड़ता
    • सही, यह per-client नहीं है। अगर per-client होता, तो proof-of-work मांगने के बजाय malicious clients को block कर देते
      anonymity या freely नई identities बनाने की capability की वजह से attacker Sybil attack के जरिए capacity खत्म करके denial of service करा सकता है

  • मुझे जिज्ञासा है कि यहाँ Sybil attack को और elegant तरीके से हल करने का कोई रास्ता है या नहीं। उदाहरण के लिए, कई CPU में हर processor के लिए एक unique key pair होता है, और issuer Intel, AMD आदि के CA root certificate से उसे verify किया जा सकता है। Proof of work को serial signatures के साथ बाँधकर parallel verification की अनुमति दें, तो हर proof of work CPU-specific unique हो जाएगा, जिससे botnet के जरिए उसे parallelize नहीं किया जा सकेगा
    लगता है ये लोग botnet की लागत बढ़ाने के लिए memory को target कर रहे हैं। इस attack scenario को कम करने के और भी कई तरीके दिखते हैं। यही logic ESIM इस्तेमाल करने वाले phones पर भी लागू हो सकता है। बाद में mobile network authentication public-key cryptography इस्तेमाल करता है, तो unique proof भी संभव लगता है
    यह बस अचानक आया विचार है, इसलिए संभव है कि मैं इस तरीके की कोई साफ़-साफ़ दिखने वाली समस्या miss कर रहा हूँ

    • अगर आप immutable hardware keys और manufacturer certification supply chain पर आधारित solution सुझा रहे हैं, तो मैं पूछना चाहूँगा कि क्या आप समझते हैं कि Tor क्या है
    • Onion service को ऐसे तरीके से identity prove करना, जिसे दूसरी Onion service usage से link किया जा सके, खराब नतीजे दे सकता है
    • DDoS का Sybil attack से कोई संबंध नहीं है। DoS इसलिए होता है क्योंकि limited resource, यहाँ connection initiation, मुफ्त में उपलब्ध कराई जाती है
      memory-heavy algorithm चुनने की वजह specific hardware, यानी ASIC usage को रोकना है
    • जाहिर है अगर आप Intel, AMD आदि के certificates पर trust नहीं करते, तो यह तरीका काम नहीं करेगा। इस use case में उन पर trust क्यों करना चाहिए, यह भी समझ नहीं आता
    • “paired client connection का इंतज़ार” सुनने में तो कमाल लगेगा। विचार रोचक है, लेकिन कई समस्याएँ दिमाग में आती हैं
      इसी तरह की दिशा में, server के पास कई IP pools हों और client port knocking proof return करे, तो कैसा रहेगा। उदाहरण के लिए token दें, इस IP:port पर भेजें, और एक unique response का इंतज़ार करें जिसे मैं verify कर सकूँ। इसे latency proof कहा जा सकता है। CPU usage कम होगा और load कई machines और ports में distribute किया जा सकेगा। downside स्वाभाविक रूप से यह है कि कई IP और संभवतः कई servers चाहिए होंगे। इसे उसी machine पर भी implement किया जा सकता है, लेकिन तब CPU load बस port connections पर shift हो जाएगा

  • Tor network का traffic कम करने या उसे तेज़ बनाने का एक idea है। network को CDN की तरह इस्तेमाल कर पाने की क्षमता होनी चाहिए। अगर आप कोई file publish करना चाहते हैं, तो allowed nodes को file chunks भेज सकें, और file request आने पर उन nodes की ओर point कर सकें
    बेशक ध्यान रखना होगा कि Tor network “anonymous torrent replacement” बनकर अपने उद्देश्य को नुकसान न पहुँचाए
    मौजूदा proposal “verified network traffic prioritization” की बात करता है। चूँकि यह सच में network की मदद करता है, अगर “file chunks” share करना traffic priority बढ़ा सके तो दिलचस्प होगा। यानी “proof of work” की जगह proof of bandwidth contribution होगा

    • वह Tor की तुलना में content-based Freenet model के ज्यादा करीब है। Tor परंपरागत रूप से anonymous TCP real-time networking है
      फिर भी यह network traffic को कैसे कम करेगा, यह मुझे साफ़ नहीं है। आखिर CDN nodes से communication तो करना ही होगा

  • इस proposal ने जो goals और limitations तय किए हैं, उन्हें देखते हुए यह reasonable है, और शायद वे goals हासिल कर लेगा। जैसा कहा गया, छोटे botnets पर काम करेगा, लेकिन बड़े botnets अब भी individual client के available resources को overwhelm कर सकते हैं
    व्यक्तिगत रूप से मुझे proof of work पसंद नहीं है। यहाँ यह defense mechanism के रूप में dialogue avoidance के ज्यादा करीब है, पुराने hardware को जल्दी obsolete बना सकता है, और affected devices को मिलाकर देखें तो काफी बिजली खा सकता है। बड़े पैमाने पर लागू होने पर यह significant environmental burden बन जाता है
    attacker के नज़रिए से difficulty को इतना ऊँचा कर देना भी अपने आप में success माना जाएगा। अगर user को device 100% पर चलाते हुए 1 minute इंतज़ार करना पड़े, तो बहुत मामलों में वे बस छोड़कर चले जाएँगे
    फिर भी user anonymity को नुकसान पहुँचाए बिना DoS attacks को mitigate करने का यह काफी अच्छा तरीका है, इसलिए उस दृष्टि से drawbacks के बावजूद यह अच्छा solution है। Tor में मौजूद रहने तक कोई बड़ी समस्या नहीं है, लेकिन अगर इसे general web पर लागू किया गया तो मेरे हिसाब से यह पूरी तरह disaster होगा

  • लेख में कहा गया है कि high-end server और low-end phone के solve time में फर्क सिर्फ़ 6x है। यह कैसे संभव है, समझ नहीं आता। server के पास phone से RAM और CPU count 6x से कहीं ज्यादा होता है और CPU भी संभवतः तेज़ होते हैं
    साथ ही अगर DDoS है, तो server का काम शर्मनाक हद तक अच्छी तरह parallelize होता है, लेकिन client work जरूरी नहीं कि parallelize हो
    वह फर्क 6x हो, या सिर्फ़ 1x ही क्यों न हो, DDoS detect होने पर solve time 1 minute बताया गया है। उस point पर service practically down ही नहीं है क्या?

    • equihash में limiting factor memory bandwidth माना जाता है, और server और phone के बीच यह फर्क शायद अपेक्षा से उतना बड़ा न हो
    • algorithm explanation यहाँ अच्छी है: https://github.com/tevador/equix/blob/master/devlog.md
      DDoS detect होने पर solve time 1 minute होने की बात का main point यह है कि मौजूदा आसान DoS attack, introduction flooding, को partial failure या slowdown में बदलना है। यह एक कठिन problem पर incremental improvement है
    • वह estimate कम से कम एक order of magnitude, शायद दो orders of magnitude से भी ज्यादा गलत लगता है। अगर GPU acceleration संभव हो तो अंतर और बड़ा हो सकता है