Hetzner/Linode XMPP.ru MitM इंटरसेप्शन घटना के शमन उपाय

 (devever.net)
1 पॉइंट द्वारा GN⁺ 2023-10-22 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • jabber.ru और xmpp.ru को ऐसा MitM हमला झेलना पड़ा जिसमें होस्टिंग प्रदाता के रास्ते ट्रैफ़िक इंटरसेप्शन और Domain Validation प्रमाणपत्र का अनधिकृत जारी होना साथ आया, जिससे non-web TLS services की सुरक्षा में मौजूद खालीपन सामने आया
  • Certificate Transparency logs की निगरानी और TLS public key probing असामान्य संकेत खोजने में मदद कर सकते हैं, लेकिन CT में दर्ज न किए गए प्रमाणपत्रों और selective MitM के सामने पूरी तरह विश्वसनीय detection कठिन है
  • ACME-CAA(RFC 8657) को DNSSEC के साथ तैनात करने पर किसी विशेष CA के केवल किसी विशेष account को ही प्रमाणपत्र जारी करने की अनुमति दी जा सकती है, इसलिए हमलावर के लिए सिर्फ वही CA इस्तेमाल करना पर्याप्त नहीं रहेगा
  • वेब ब्राउज़र के विपरीत, कई non-web clients CT proof (SCT) को अनिवार्य नहीं करते, और CA/Browser Forum Baseline Requirements भी सभी प्रमाणपत्रों के लिए CT logging को अनिवार्य नहीं बनातीं
  • ऑपरेटरों को ACME-CAA·DNSSEC·CT monitoring·Tor onion service·jurisdiction diversification पर विचार करना चाहिए, और उपयोगकर्ताओं को end-to-end encryption तथा fingerprint verification को अपनी मूल सुरक्षा रेखा बनाना चाहिए

घटना की मुख्य संरचना

  • jabber.ru और xmpp.ru के ऑपरेटरों ने बताया कि उनकी service पर man-in-the-middle attack हुआ
  • हमला दो तत्वों के संयोजन वाला था
    • Hetzner और Linode ने service machine की ओर जाने वाले traffic को intercept किया
    • हमलावर ने उस service के लिए Domain Validation प्रमाणपत्र अनधिकृत रूप से जारी करवा लिया
  • आकलन है कि जर्मन राज्य ने इसका समन्वय किया, या जर्मनी ने एक या अधिक अन्य राज्यों के साथ मिलकर ऐसा किया हो सकता है
  • अन्य संभावनाएँ भी बनी हुई हैं
    • Hetzner और Linode ने कानूनी दबाव के बिना किसी विदेशी शक्ति के wiretapping अनुरोध का स्वेच्छा से पालन किया हो सकता है
    • हालांकि ऐसा होने पर दोनों कंपनियों की बहुत खराब छवि बनेगी और यह अवैध भी हो सकता है, इसलिए इसकी संभावना कम मानी गई है

पता लगाने के तरीके और सीमाएँ

  • पहला तरीका Certificate Transparency(CT) logs की निगरानी करना है, ताकि ऑपरेटर द्वारा अनुरोध न किए गए प्रमाणपत्र जारी होने का पता लगाया जा सके
    • कुछ services यह काम ऑपरेटरों की ओर से करती हैं
    • केवल अनचाहे प्रमाणपत्रों को सही ढंग से चुनकर alert देने वाले tools में अभी और सुधार की गुंजाइश है
  • दूसरा तरीका समय-समय पर service से connect होकर यह जांचना है कि TLS server की public key अपेक्षित मान से मेल खाती है या नहीं

  • CT monitoring किन चीज़ों को मिस कर सकती है

    • किसी वैध CA द्वारा जारी प्रमाणपत्र का CT logs में दर्ज होना अनिवार्य नहीं है
    • CA/Browser Forum Baseline Requirements अभी CT logging को CA के लिए अनिवार्य शर्त नहीं बनातीं
    • वेब ब्राउज़र उन प्रमाणपत्रों को अस्वीकार कर देते हैं जिनमें CT log entry का cryptographic proof नहीं होता, इसलिए वेब में CT logging व्यावहारिक रूप से अनिवार्य हो जाती है
    • अधिकांश non-web client applications यह जांचती या मांगती नहीं हैं कि प्रमाणपत्र में CT record proof मौजूद है या नहीं
    • सिद्धांततः हमलावर CT में दर्ज न किया गया प्रमाणपत्र प्राप्त कर सकता है

  • selective MitM द्वारा बच निकलने की संभावना

    • भले ही service probing से MitM का पता लगाने की कोशिश की जाए, हमलावर detection connection को पहचान कर उस connection पर MitM लागू न करे, ऐसा हो सकता है
    • कम-से-कम probe को Tor के माध्यम से चलाना चाहिए ताकि आसानी से पहचाने जाने वाली स्थिति से बचा जा सके
    • TLS stack की fingerprinting TLV enumeration order जैसे संकेतों से की जा सकती है, इसलिए वास्तविक XMPP client और probe agent में अंतर किया जा सकता है
    • हमलावर ज्ञात probes को blacklist करने के बजाय केवल रुचि वाले खास व्यक्तियों के traffic को whitelist करके MitM कर सकता है
    • दोनों detection तरीकों में से कोई भी पूर्ण विश्वसनीयता नहीं देता

ACME-CAA से कम किए जा सकने वाले जोखिम

  • TLS प्रमाणपत्र MitM हमलों को रोकने के लिए होते हैं, लेकिन CA द्वारा domain control सत्यापित करने वाला Domain Validation model स्वयं MitM के प्रति संवेदनशील है
  • यदि हमलावर पीड़ित site के कुछ traffic नहीं बल्कि पूरे traffic को intercept कर सके, तो जोखिम बढ़ जाता है
  • ACME-CAA(RFC 8657) कुछ स्थितियों में इस समस्या को कम कर सकता है
  • मुख्य विचार यह है कि DNS records के जरिए यह निर्दिष्ट किया जाए कि किसी विशेष CA का केवल विशेष account ही domain प्रमाणपत्र जारी कर सके
    • केवल वही CA इस्तेमाल करना पर्याप्त नहीं है
    • उस CA में उसी account तक पहुंच भी चाहिए
    • Let's Encrypt में प्रमाणपत्र अनुरोध के लिए इस्तेमाल होने वाली ACME private key तक पहुंच जरूरी होगी
  • ज्ञात attack method को देखते हुए, यदि यह extension तैनात होता तो संभवतः हमला रोका जा सकता था

  • deployment के समय ध्यान देने योग्य बातें

    • ACME-CAA के सही ढंग से काम करने के लिए DNSSEC की deployment जरूरी है
    • DNSSEC न होने पर CA की DNS requests भी intercept की जा सकती हैं
    • जो व्यक्ति DNSSEC signing key पर कब्जा कर ले, वह इस सुरक्षा अवरोध को पार कर सकता है
    • DNSSEC से संरक्षित DNS zone को signing key किसी third party को दिए बिना भी चलाया जा सकता है
    • इस स्थिति में DNS hosting provider के पास zone से छेड़छाड़ करने का अधिकार नहीं होगा
    • इसे सबसे बेहतर deployment strategy माना गया है
    • हमलावर domain registrar या TLD registry पर दबाव डालकर domain में दर्ज DNSSEC signing key बदलवाने की कोशिश कर सकता है
    • ऐसा करना ध्यान आकर्षित कर सकता है
    • DNS caching की प्रकृति के कारण repeated probing द्वारा key change छिपाना मुश्किल हो सकता है
    • हमलावर CA पर ही दबाव डालकर misissued प्रमाणपत्र निकलवा सकता है
    • third-party CA नियम तोड़े या गलती करे तो जोखिम फिर भी बना रहता है
    • CA/Browser Forum Baseline Requirements CA से DNSSEC जांचने की अपेक्षा करती हैं
    • लेकिन third-party CA CAA record में अनुमति न होने पर भी प्रमाणपत्र जारी कर सकता है
    • CT logging अनिवार्य न होने के कारण ऐसे प्रमाणपत्र detect भी नहीं हो सकते

अधिक कुशल हमलावर कौन-सा flow अपना सकता है

  • इस घटना का हमलावर अवैध प्रमाणपत्रों को expire होने देता रहा, इसलिए वह पूरी तरह सक्षम attacker नहीं था
  • सस्ती और आसान encryption के प्रसार के साथ राज्य-स्तरीय हमले अधिक sophisticated और अधिक frequent होने की संभावना है
  • अधिक कुशल state-level attacker निम्न flow चुन सकता है
    • CA द्वारा CT log entry को अनिवार्य न बनाने का लाभ उठाकर undisclosed certificate का अनुरोध करना
    • hosting provider पर दबाव डालकर victim machine की ओर जाने वाले सभी traffic पर MitM करना
    • TLS stack fingerprint और source IP के आधार पर रुचि वाले traffic और detection traffic को heuristically अलग करना
    • MitM का उपयोग कर CA को यह विश्वास दिलाना कि हमलावर ही victim domain का वैध नियंत्रक है
    • यदि domain ACME-CAA और DNSSEC उपयोग करता है, तो DNS hosting provider, registrar, TLD registry और CA पर दबाव डालने की कोशिश करना

मौजूदा TLS infrastructure की कमियां

  • non-web TLS clients में CT enforcement की कमी

    • वेब ब्राउज़र CA प्रमाणपत्रों में CT log entry का cryptographic proof शामिल होने की मांग करते हैं
    • अधिकांश अन्य TLS clients CT proof को अनिवार्य नहीं करते, इसलिए वे CT में दर्ज न किए गए प्रमाणपत्र स्वीकार कर सकते हैं
    • संभावना है कि कई XMPP clients भी इसी श्रेणी में आते हों
    • CT verification ऐसा feature नहीं है जो केवल OpenSSL से link होने भर से अपने-आप सक्रिय हो जाए; इसके लिए अलग implementation चाहिए
    • संवेदनशील संचार में उपयोग होने वाले software को CT enforcement support पर विचार करना चाहिए

  • प्रमाणपत्र CT logging की अनिवार्यता का अभाव

    • CA/Browser Forum Baseline Requirements, जो CA के लिए industry rules हैं, प्रमाणपत्रों को CT logs में दर्ज करना अनिवार्य नहीं बनातीं
    • सभी प्रमाणपत्रों को CT logs में दर्ज करने की दिशा में बदलाव जरूरी माना गया है
    • यदि CT enforcement व्यापक रूप से deploy हो जाए, तो यह समस्या तकनीकी रूप से महत्वहीन हो सकती है

  • CT monitoring services की कमी

    • अधिक CT monitoring services की आवश्यकता है
    • वर्तमान में प्रमुख CT alert services में SSLMate's Cert Spotter शामिल है
    • इसकी कीमत volunteer-based services आदि के लिए बोझ बन सकती है
    • CT monitoring को इस तरह design किया जाना चाहिए कि false positives कम हों और केवल असामान्य या अनधिकृत दिखने वाले प्रमाणपत्र जारी होने पर ही alert मिले

  • DNSSEC transparency का अभाव

    • वर्तमान में domain पर configured DNSSEC keys में बदलाव detect करने के लिए कोई deployed cryptographic infrastructure नहीं है
    • यदि domain registrar और TLD registry पर दबाव या compromise के जरिए domain की DNSSEC key बदल दी जाए, तो ACME-CAA सुरक्षा कमजोर हो सकती है
    • DNSSEC zone key changes को सार्वजनिक रूप से दिखाई देने योग्य बनाने वाला transparency solution वांछनीय है
    • इस समाधान में zone के सभी records नहीं, केवल DS record जैसे zone key changes ही दर्ज करना पर्याप्त हो सकता है

service operators के लिए सिफारिशें

  • जिन services पर state-level attack का खतरा हो, उनके लिए लागत-प्रभावशीलता के आधार पर defenses लागू करने का approach सुझाया गया है

  • ACME-CAA और DNSSEC

    • ACME-CAA तैनात करने से हमलावर के लिए CA को धोखा देकर domain प्रमाणपत्र जारी करवाना कठिन हो सकता है
    • deployment guide के लिए ACME-CAA deployment post देखी जा सकती है
    • RFC की Security Considerations में भी महत्वपूर्ण सावधानियाँ दी गई हैं
    • यदि ACME-CAA तैनात करें, तो DNSSEC भी साथ में तैनात करें
    • संभव हो तो ऐसा DNSSEC provider चुनें जहां signing key provider को सौंपनी न पड़े

  • proxy services और CT monitoring

    • Cloudflare जैसी service का उपयोग करने को स्वयं को पहले से ही MitM करने जैसी स्थिति माना गया है
    • CT log monitoring service की सदस्यता लें या logs को नियमित रूप से स्वयं जांचें
    • SSLMate's Cert Spotter paid automated monitoring देता है
    • Cert Spotter open source है, इसलिए self-hosting भी संभव है
    • crt.sh CT logs की manual search उपलब्ध कराता है

  • jurisdiction diversification और Tor onion service

    • domain registrar, TLD registry, DNS hosting, CA और hosting provider को अलग-अलग देशों में रखने वाली jurisdiction diversification पर विचार किया जा सकता है
    • ऐसे देश या geopolitical blocs चुने जा सकते हैं जिनके आपस में सहयोग करने की संभावना कम हो
    • Tor onion service देने से TLS और CA जैसी central infrastructure को bypass किया जा सकता है
    • Tor onion service में service public key स्वयं address होती है
    • उपयोगकर्ता को सही onion address किसी विश्वसनीय channel से मिलना चाहिए
    • third party उपयोगकर्ता को गलत onion address की ओर मोड़ सकती है

  • Tor-आधारित automated probing

    • Tor के माध्यम से automated probing पूर्ण समाधान नहीं है, लेकिन वास्तविक दुनिया की अनाड़ी गलतियों को पकड़ सकता है
    • Tor इस्तेमाल करने से probe के रूप में आसानी से पहचान लिए जाने की संभावना घटती है
    • TLS fingerprinting की संभावना कम करने के लिए commonly used TLS libraries वाला client software बेहतर है
    • संभव हो तो वास्तविक client का उपयोग करना अधिक अच्छा है
    • XMPP service हो तो वास्तविक XMPP client इस्तेमाल किया जा सकता है
    • सफलता मिलने पर भी यह compromise के बाद की detection ही होगी, तब तक उपयोगकर्ता प्रभावित हो चुके हो सकते हैं

  • अन्य attack vectors और worst-case assumptions

    • MitM कठिन होने पर हमलावर machine compromise, private key theft या sensitive data theft जैसे दूसरे रास्ते अपना सकता है
    • state-level attacker VM provider पर दबाव डालकर hypervisor स्तर पर memory dump करवा सकता है
    • dedicated server भी attacker की physical access से compromise हो सकता है
    • operators को उपयोगकर्ताओं को end-to-end encryption की सलाह देनी चाहिए और मानकर चलना चाहिए कि service सर्वोत्तम प्रयासों के बावजूद compromise हो सकती है
    • वेब application के जरिए दी जाने वाली “end-to-end” encryption को सार्थक सुरक्षा नहीं माना गया है

CA, client developers और users के लिए आवश्यक कदम

  • CA/Browser Forum

    • सभी प्रमाणपत्रों को CT logs में दर्ज करना अनिवार्य करे, या ऐसा प्रस्ताव आगे बढ़ाए

  • application client developers

    • TLS प्रमाणपत्रों में Signed Certificate Timestamps(SCTs) की उपस्थिति अनिवार्य करने वाला feature जोड़ें और उसे default रूप से enable करें
    • उपयोगकर्ता यह जान सकें कि उन्हें यह सुरक्षा मिल रही है
    • CT proof enforcement में कुछ variability हो सकती है, इसलिए संबंधित चर्चाओं पर भी ध्यान देना चाहिए
    • software को public audit के लिए open source रूप में उपलब्ध कराया जाना चाहिए
    • supply chain risk और इस संभावना पर भी विचार होना चाहिए कि developer स्वयं कानूनी दबाव में software को कमजोर करने पर मजबूर हो सकता है
    • Linux distribution package repositories जैसे distribution channels, जिन्हें developer सीधे नियंत्रित नहीं करता, नुकसान कम करने में मदद कर सकते हैं

  • end users

    • यह मानकर चलना चाहिए कि operator भले सद्भावना से service चला रहा हो, फिर भी सर्वोत्तम प्रयासों के बावजूद compromise संभव है
    • यदि किसी की जान service के uncompromised रहने पर निर्भर करती है, तो उस service पर भरोसा नहीं करना चाहिए
    • XMPP में OMEMO या OTR जैसे end-to-end encryption technologies का उपयोग करना चाहिए
    • संचार-साझेदार के fingerprint को हमेशा verify करना चाहिए
    • web-based software में end-to-end encryption न करें, या कम-से-कम उसे compromised मानकर चलें
    • यदि service provider Tor onion service देता है, तो उसके उपयोग पर विचार करें, लेकिन onion address विश्वसनीय स्रोत से ही प्राप्त करें

  • CA और standards writers

    • यदि CA ACME-CAA(RFC 8657) को support नहीं करता, तो implementation पर विचार करे
    • ACME-आधारित CA न होने पर भी ACME-CAA implement किया जा सकता है
    • भले ही CA/Browser Forum rules CT में दर्ज न करने की अनुमति दें, CA सभी प्रमाणपत्रों को CT में दर्ज करने की policy अपना सकता है
    • standards writers कम-से-कम DS records के लिए DNSSEC transparency की संभावना की फिर से समीक्षा कर सकते हैं

Confidential computing पर आकलन

  • यदि hosting provider द्वारा machine compromise तक की चिंता हो, तो मौजूदा confidential computing technology को पर्याप्त समाधान नहीं माना गया है
  • deployment कुछ न करने से बेहतर हो सकता है, लेकिन इसे सुरक्षित मान लेना उचित नहीं है
  • AMD, Intel आदि सहित वर्तमान technologies को ऐसे vendor golden keys पर निर्भर माना गया है जिनसे system में backdoor डाला जा सकता है
  • state-level attacker vendor पर दबाव डालकर ये keys हासिल कर सकता है, और तब यह तरीका विफल हो जाएगा
  • golden key पर निर्भर न रहने वाले confidential computing approaches संभव हो सकते हैं, लेकिन मौजूदा तरीके उस मानक पर खरे नहीं उतरते

संबंधित सामग्री

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

1 टिप्पणियां

 
GN⁺ 2023-10-22
Hacker News की राय

  • https://notes.valdikss.org.ru/jabber.ru-mitm/ पर हमले का सारांश दिलचस्प है
    हमलावर ने 18 अप्रैल 2023 से Let’s Encrypt के जरिए jabber.ru और xmpp.ru के कई SSL/TLS certificate जारी करवाए, और यह पुष्टि हुई कि 21 जुलाई से 19 अक्टूबर तक कम-से-कम XMPP STARTTLS 5222 port पर client traffic के 100% पर man-in-the-middle attack लागू किया गया था
    इसके बाद certificate फिर से जारी करवाने में विफल रहने पर jabber.ru के 5222 port पर expired certificate भेजा गया, और जांच व Hetzner/Linode से पूछताछ शुरू होने के तुरंत बाद हमला रुक गया, लेकिन कुछ Linode servers पर अतिरिक्त routing hop के जरिए passive interception बाकी था
    ऐसा लगता है कि server खुद hack नहीं हुआ था, बल्कि Hetzner और Linode networks को XMPP service IP को निशाना बनाने के लिए फिर से configure किया गया था
    उस page या यहां link किए गए pages में से कोई भी certificate pinning का ज़िक्र नहीं करता। पता नहीं यह इसलिए है कि XMPP इसे support नहीं करता, लेकिन अगर support करता तो शायद ऐसे हमले को रोका जा सकता था

    • XMPP channel binding को support करता है, और यह इस हमले को रोक सकता था, लेकिन लेख में इसका ज़िक्र नहीं है
      दुर्भाग्य से jabber.ru 2016 का server software इस्तेमाल कर रहा है, इसलिए वह पुराना version इसे support नहीं करता
      आजकल certificate pinning में बहुत समस्याएं हैं क्योंकि certificates की lifetime छोटी होती है और वे अक्सर renew होते हैं। अगर user से हर महीने नया certificate allow करने को पूछा जाए, तो वह attacker के certificate पर भी बिना सोचे “Accept” दबा देगा
      channel binding certificate से स्वतंत्र रूप से काम करता है और यह सुनिश्चित करता है कि TLS stream expected entity पर ही terminate हो
      XMPP clients में CT/SCT support की कमी पर ध्यान देना अजीब है। इस हमले में Let’s Encrypt द्वारा जारी और CT logs में भी दर्ज valid certificate इस्तेमाल हुआ था, इसलिए CT/SCT से इसका पता नहीं चलता
      अगर strict CAA record होता, तो किसी दूसरे certificate authority से जारी होने की काल्पनिक स्थिति को SCT verification से पकड़ा जा सकता था, लेकिन असल में CAA भी नहीं था, और channel binding privacy के लिहाज़ से बेहतर है तथा third parties पर कम निर्भर करता है
    • मुझे हैरानी है कि सिर्फ STARTTLS port को ही क्यों निशाना बनाया गया। इससे संबंधित, अगर पता हो कि server पर normal TLS port मौजूद है, तो opportunistic encryption वाला STARTTLS port मैं कभी इस्तेमाल नहीं करूंगा
    • हमलावर ने Let’s Encrypt से कई SSL/TLS certificates जारी करवाए, इसका मतलब है कि उसने jabber.ru और xmpp.ru के domain ownership verification को pass किया
      यानी वह hosted HTTP पर ACME protocol का जवाब दे सकता था, या DNS TXT record लिख सकता था; इसलिए ऐसा लगता है कि victim पहले ही process server या nameserver पर control खो चुका था
    • अगर clients पर control नहीं है तो certificate pinning कैसे की जा सकती है, यह मुझे समझ नहीं आता
      मेरी समझ में certificate pinning तभी संभव है जब आप client को control कर सकते हों, और allow किए जाने वाले certificate को सीधे client में डालकर पूरे web public key infrastructure को bypass करते हों
      जब generic clients connect करते हैं, तो यह जानने का कोई तरीका नहीं होता कि कौन-सा certificate allow किया जाना चाहिए, और इसी काम के लिए web public key infrastructure इस्तेमाल किया जाता है
      बेशक, अगर आप अपना client provide भी करते हैं, तो समस्या बस एक level ऊपर चली जाती है: customer जिस जगह से custom client download करता है, वह compromise हो सकती है और malicious client distribute किया जा सकता है

  • इस list में सबसे obvious defense गायब है। authentication method के रूप में SCRAM-xxxxx-PLUS को enable करना चाहिए और संभव हो तो enforce करना चाहिए
    PLUS variants का idea सरल लेकिन प्रभावी है। सिर्फ salt से verify करने के बजाय यह verification को किसी खास TLS connection से bind कर देता है, इसलिए authentication केवल उसी एक TLS connection में valid रहता है
    इसे channel binding भी कहा जाता है

  • सोच रहा हूँ कि xmpp.ru और jabber.ru के अंतिम यूज़र कौन हैं। क्या मकसद रूसी सैनिकों या जासूसों के बीच का ट्रैफ़िक पकड़ना है? मुझे mass surveillance पसंद नहीं है, लेकिन समझ नहीं आता कि खास तौर पर रूसी डोमेन को ही क्यों निशाना बनाया गया

    • युद्ध से सीधे जुड़े, यानी सचमुच सैनिकों या जासूसों को intercept करने वाले scenario की कल्पना करना मुश्किल है
      ज्यादा plausible scenario carder या botnet operators को पकड़ने का लगता है। Jabber/XMPP रूसी तरफ़ उस underground में अब भी काफ़ी लोकप्रिय है, और Krebs on Security जैसी posts में भी @exploit.in, @jabber.ru जैसे कई servers वाले screenshots या logs अक्सर दिख जाते हैं
      फिर भी मंशा कुछ भी हो, mass surveillance आम तौर पर घिनौनी चीज़ है
      इन दो servers पर आपराधिक और गैर-आपराधिक इस्तेमाल का अनुपात ठीक-ठीक क्या है, मुझे नहीं पता, लेकिन Tor की तरह जहाँ साफ़ तौर पर illegal content और legitimate use मिला-जुला होता है, यहाँ भी काफ़ी पूरी तरह सामान्य बातचीत होगी
      इसलिए, शुरुआत से ही ऐसे किसी मनमाने cybercriminal पर निगरानी के लिए privacy का उल्लंघन करने के पक्ष में मैं ज़्यादा नहीं हूँ, जो किसी ऐसे देश के jurisdiction से बाहर है जहाँ extradition भी मुश्किल है
      मैं समझता हूँ कि Hetzner को Lavabit जैसा न बनने के लिए cooperate करना पड़ा होगा, लेकिन जिस नज़रिए से मैं अक्सर उसे recommend करता था, अगर Hetzner को middleman attack की जानकारी थी और उसने उसे अनुमति दी या मदद की, तो यह काफ़ी निराशाजनक होगा। बाकी मामलों में मैं उसे सबसे अच्छी hosting companies में से एक मानता हूँ
      उसकी transparency अच्छी है, uptime·reliability·support ज़्यादातर cloud providers से बेहतर हैं, और cost भी ज़्यादा नहीं है। eco-friendly design को आर्थिक रूप से भी smart choice बनाने की उसकी कोशिश भी तारीफ़ के काबिल है
      “reduce > reuse > recycle” में reduce KISS design में दिखता है। उदाहरण के लिए natural heat exhaust में मदद करने वाली ऊँची और ढलान वाली छतें[2], server chassis जो असली chassis से ज़्यादा minimal structural support और airflow cover जैसे हैं, VRM·CPU·memory को एक fan से cool करने के लिए socket को 90 degrees rotate किया गया standard motherboard design[3] जैसी चीज़ें
      “reuse” server auctions में दिखता है। पुराने hardware को फेंकने के बजाय Dutch auction तरीके से rent पर देते हैं, जिससे नए hardware की cost और हर generation में फिर से manufacturing की environmental cost, दोनों से बचते हैं
      अगर Europe के बाहर भी dedicated servers होते, तो मैं इसे और ज़्यादा इस्तेमाल करना चाहता
      [1]: “legal” को define करना भी अपने-आप में मुश्किल है। एक देश का journalist दूसरे देश का “foreign agent” है, और एक देश का “freedom fighter” दूसरे देश का “terrorist” है
      [2]: Der8auer: Over 200,000 Servers in One Place! Visiting Hetzner in Falkenstein - https://youtu.be/5eo8nz_niiM?t=259
      [3]: Der8auer: Hetzner shows Special AM5 Board with 90° Rotated Socket - https://youtu.be/V2P8mjWRqpk

  • लेख में “CT optional है” कहा गया है, लेकिन आखिर यह XMPP client को तय करने वाली बात नहीं है क्या? जब browsers अब practically इसकी मांग करते हैं, तो XMPP client को CT require करने से क्या रोकता है, यह जानना चाहता हूँ
    यह भी समझ नहीं आता कि वे किस trust store पर निर्भर हैं जो browser में काम न करने वाले certificates जारी करता है

    • सही है। ऐसा किया जा सकता है और यह अच्छा idea लगता है
      समस्या यह है कि CT-required behavior लगभग किसी भी TLS library में default रूप से enabled नहीं होता। इसलिए XMPP client developer को जानबूझकर इसे enable करना होगा, और अभी मुझे लगता है कि ज़्यादातर या सभी ऐसा नहीं करते। बेशक यह बदल सकता है

  • यह लेख XMPP में OTR इस्तेमाल करने का सुझाव देता है, लेकिन दुर्भाग्य से OTRv3 पुराने crypto का इस्तेमाल कर रहा है और OTRv4 अभी final नहीं हुआ है
    https://dustri.org/b/time-to-sunset-otr.html

  • “perfect attacker क्या करेगा?” वाले सवाल पर, अगर computer तक physical access हो, तो किसी तरह की bus interception से device से data निकालने का तरीका हो सकता है

    • बड़े picture में थोड़ा अलग सोचें तो समझ नहीं आता कि हम अभी भी datacenters पर क्यों निर्भर हैं
      dial-up और slow·high-latency broadband के दौर में यह समझ में आता था, लेकिन अब कई जगहों पर high-speed fiber और peering points तक low latency है
      datacenters और cloud से जितना बाहर निकलेंगे, internet infrastructure को अपने originally designed तरीके से काम करना चाहिए, और आज जैसे गंभीर failure point और बड़े security risk वाले centralized aggregation points से गुजरने की ज़रूरत कम होगी
    • datacenter में physical access हासिल करना बेहद मुश्किल है

  • CAA के बारे में देखा, लेकिन जो DNS provider मैं अभी इस्तेमाल करता हूँ वह उस record को support नहीं करता। यह ज़्यादा common TXT record की जगह नया type क्यों होना चाहिए था, इसकी कोई वजह है?

    • देख सकते हैं कि provider “opaque” type support करता है या नहीं। यह ऐसा तरीका है जिसमें provider को record क्या है यह जाने बिना भी binary encoding submit की जा सकती है
      अगर ऐसा नहीं है, तो support के लिए request करनी होगी। CAA record increasingly used type है, इसलिए आजकल इसे support न करना बहुत अच्छी service नहीं कही जाएगी
      CAA design discussion के बारे में मुझे पता नहीं, लेकिन संभव है कि relevant IETF mailing list पर चर्चा हुई हो
    • RFC5507 का “Why Adding a New Resource Record Type Is the Preferred Solution” देखें
      DNS providers को अलग-अलग RR types support करने चाहिए, और domain owners को NS records से vote करना चाहिए
      CAA support करने वाले DNS providers की list https://github.com/StackExchange/dnscontrol/blob/master/docu... पर है
    • कुछ providers कहते हैं कि वे support नहीं करते, लेकिन कई बार असल में मतलब सिर्फ़ यह होता है कि web interface में नहीं होता
      एक hidden primary server खड़ा करके provider को सिर्फ़ secondary server के रूप में रखा जा सकता है या नहीं, यह test करने लायक है। Linode में मैंने इसी तरह उस limitation को bypass किया

  • अपनी certificate authority चलाने और root certificates सावधानी से चुनने वाला विकल्प छूट गया

    • जब आप किसी third party को service देते हैं जो कोई भी client software इस्तेमाल कर सकती है, तो यह थोड़ा मुश्किल है

  • प्रदाता के पास होस्ट तक पहुंच हो सकती है, इसलिए वह बाहर से काम की जांच कर सकता है और उपयोगकर्ता को पता भी नहीं चलेगा

    • Hetzner वाला पक्ष physical server है। “बिजली कटने” जैसी स्थिति बनाकर backdoor लगाना होगा, जो आसान नहीं होगा
      उदाहरण के लिए, ऐसा kernel module लगाना होगा जो kernel upgrade के बाद भी बचा रहे और खुद को बेहद अच्छी तरह छिपाए। लेख में raw memory dump analysis पर भी चर्चा है
    • Secure Boot और virtualized memory encryption ऐसे हमलों को रोकने के लिए बनाए गए हैं। हालांकि Intel/AMD पर भरोसा करना पड़ेगा
    • लेकिन इस मामले में हमलावरों ने किसी वजह से server backdoor access का इस्तेमाल नहीं किया

  • किसी राष्ट्र-राज्य या उसके बराबर ताकतवर actor के ऐसे हमलों का मूलभूत तकनीकी समाधान क्या हो सकता है? क्या ऐसा तरीका है जो उस geeky सपने को पूरा करे—ऐसा software जिसे स्वतंत्र रूप से distribute किया जा सके, फिर भी लेखक के अलावा कोई भी उसे censor, intervene या tamper न कर सके?
    क्या मौजूदा Internet infrastructure के ऊपर ठीक से बनाया गया P2P system पर्याप्त जवाब होगा, या हमें wireless पर चलने वाला एक और low-bandwidth global mesh Internet बिछाना पड़ेगा?
    उम्मीद है Freenet 2023 P2P applications के लिए frictionless developer experience की दिशा में आगे बढ़ेगा