macOS Sequoia 15 में DNS एन्क्रिप्शन बायपास का संदेह, लेकिन असल में Little Snitch 6.1 की समस्या

 (obdev.at)
1 पॉइंट द्वारा GN⁺ 2024-09-18 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Little Snitch 6.1 में कुछ स्थितियों में DNS एन्क्रिप्शन विफल हो सकता था, लेकिन यह macOS-व्यापी समस्या नहीं निकली और इसे उस वर्ज़न तक सीमित पाया गया; 6.1.1 में इसे ठीक कर दिया गया
  • सही तरीके से काम करने के लिए macOS के DNS अनुरोधों को Little Snitch के DNS proxy तक पहुँचना चाहिए, और proxy को एन्क्रिप्टेड क्वेरी करनी चाहिए
  • जाँच के दौरान देखा गया कि कुछ low-level legacy API अनुरोध proxy तक पहुँचे बिना सिस्टम के डिफ़ॉल्ट nameserver को बिना एन्क्रिप्शन वाले UDP 53 क्वेरी भेज रहे थे
  • इसे दोहराने के लिए Little Snitch में DNS एन्क्रिप्शन चालू करें, Wireshark को port 53 फ़िल्टर के साथ चलाएँ, फिर Xcode playground में getaddrinfo("dnsproxytest.com") कॉल करें
  • Safari और Chrome जैसे high-level API आधारित लुकअप शुरुआत में अप्रभावित लगे, और Firefox प्रभावित दिखा, लेकिन अंततः समस्या का दायरा Little Snitch 6.1 के DNS proxy तक सीमित पाया गया

Little Snitch 6.1 में DNS एन्क्रिप्शन विफलता

  • Little Snitch 6 का DNS एन्क्रिप्शन फ़ीचर hostname lookup को Little Snitch के ज़रिए रूट करके एन्क्रिप्टेड रूप में प्रोसेस करता है
  • इसके लिए Little Snitch एक DNS proxy रजिस्टर करता है, और macOS को सभी DNS अनुरोध उसी proxy को भेजने चाहिए
  • पाया गया कि कुछ DNS अनुरोध, खासकर कुछ low-level legacy API के ज़रिए किए गए अनुरोध, proxy तक पहुँच ही नहीं रहे थे
  • ऐसे अनुरोध सिस्टम के डिफ़ॉल्ट nameserver को बिना एन्क्रिप्शन के भेजे जा सकते थे, और Wireshark में इन्हें UDP port 53 ट्रैफ़िक के रूप में देखा जा सकता था
  • Little Snitch Network Monitor में यह lookup ट्रैफ़िक दिखाई नहीं दे रहा था, क्योंकि यह lookup नेटवर्क फ़िल्टर को पूरी तरह बायपास कर रहा था

पुनरुत्पादन प्रक्रिया और अपडेट की प्रगति

  • पुनरुत्पादन प्रक्रिया

    • Little Snitch settings में DNS encryption सक्षम करें
    • Wireshark को port 53 capture filter के साथ चलाएँ
    • Xcode playground में getaddrinfo के ज़रिए dnsproxytest.com lookup चलाएँ
    • dnsproxytest.com lookup UDP 53 पर बिना एन्क्रिप्शन के दिखाई दे सकता है

  • शुरुआती प्रभाव का दायरा

    • high-level API के ज़रिए होने वाले DNS lookup प्रभावित नहीं लग रहे थे
    • Safari और Chrome में web browsing एन्क्रिप्टेड lookup के फ़ायदे बनाए रखती दिखी
    • Firefox प्रभावित दिखा

  • अपडेट इतिहास

    • 2024-09-17 19:10: पुष्टि हुई कि यह समस्या macOS 14.5 Sonoma से मौजूद हो सकती है, और पुराने 14.x सिस्टम का परीक्षण नहीं किया जा सका
    • 2024-09-18 12:05: यह स्पष्ट हुआ कि यह macOS की सामान्य DNS proxy समस्या नहीं है, बल्कि केवल Little Snitch 6.1 के DNS proxy को प्रभावित करने वाली समस्या है
    • 2024-09-18 15:52: समस्या Little Snitch 6.1.1 में ठीक कर दी गई

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

2 टिप्पणियां

 
GN⁺ 2024-09-18
Hacker News की राय

  • getaddrinfo() को “लो-लेवल legacy API” माना जाना थोड़ा अजीब लगता है
    macOS पर स्थिति काफी अलग हो सकती है, लेकिन Linux और शायद *BSD में नाम resolution के लिए यह standard तरीका है
    macOS ऐप्स में से ज़्यादातर DNS queries के लिए Foundation या NetworkKit जैसे frameworks इस्तेमाल करते होंगे, लेकिन यह भी हैरानी की बात है कि अंदर से अंततः वे getaddrinfo() जैसी calls तक उतरकर प्रक्रिया नहीं करते
    GAI blocking है, इसलिए शायद कोई दूसरी लो-लेवल asynchronous call मौजूद होगी

    • सही। CFNetwork open source है, इसलिए implementation देखी जा सकती है, और पहले जब मैंने देखा था तो याद है कि यह getaddrinfo_async जैसा कोई variant इस्तेमाल करता था
      हालांकि Apple नहीं चाहता कि end users getaddrinfo या CF द्वारा expose किए गए asynchronous variants से सीधे IP resolve करें और फिर उस IP पर connect() करें
      कुल मिलाकर उन्हें hostname से connect करने के लिए प्रोत्साहित किया जाता है, ताकि Apple internally happy-eyeballs implementation संभाल सके
      Apple getaddrinfo() model को क्यों पसंद नहीं करता, यह https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf में देखा जा सकता है। हर slide के नीचे speaker notes भी हैं
    • मुझे नहीं लगता कि getaddrinfo() को legacy माना जाता है। लगता है उस blog post ने यह हिस्सा गलत लिखा है
      यह “लो-लेवल” है या नहीं, यह नजरिए पर निर्भर करता है
    • getaddrinfo() Linux से जुड़ा नहीं, बस एक glibc function है
      लोग मान लेते हैं कि glibc Linux user space का standard तरीका है, लेकिन ऐसा होना ज़रूरी नहीं
      उदाहरण के लिए systemd ने अपना resolved mechanism बनाया, और वह glibc वाले से कहीं बेहतर निकला
      मैं भी Linux को target करने वाला standalone software बना रहा हूं, इसलिए संभव है कि किसी दिन मैं खुद ऐसा ही कुछ बनाऊं
    • OpenBSD में कम से कम getaddrinfo/gethostbyname जैसे traditional और standard DNS functions, Eric Faurot द्वारा लिखे गए OpenBSD libc asr implementation के wrappers हैं
      https://man.openbsd.org/man3/asr_run.3
      https://github.com/openbsd/src/tree/master/lib/libc/asr
    • पता नहीं इस मामले में ठीक ऐसा ही है या नहीं, लेकिन एक ही नाम के system functions की internal implementation *Linux/BSD/macOS के बीच काफी अलग हो सकती है
      *BSDs के बीच भी फर्क है
      किसी system पर एक function call कई सालों तक बनी रहती है और “canonical” होती है, जबकि दूसरे system पर वह सचमुच पुरानी और कम उपयोगी हो सकती है

  • यहां चर्चा की गई समस्या macOS की आम समस्या नहीं, बल्कि केवल Little Snitch 6.1 से संबंधित निकली, और आज देर से Little Snitch update के जरिए इसे ठीक किया जाना है

    • अच्छा होगा अगर title भी इसे reflect करने के लिए update किया जा सके

  • आगे की जांच में पता चला कि यह bug कम से कम macOS 14.5 Sonoma से पहले से मौजूद था
    शायद उससे भी पहले से रहा हो, लेकिन कहा गया कि अभी test करने के लिए किसी पुराने 14.x system तक access नहीं है

    • जानना चाहूंगा कि क्या उन्होंने कभी test किया था कि getaddrinfo में यह सच में काम करता था या नहीं
      या फिर CFNetwork में एक बार काम करते देख कर वहीं रुक गए, और बाद में टूटने पर blog post डाल दी
    • developers को testing के लिए पुराने OS versions अलग से बचाकर रखने पड़ें, यह आज भी बेतुका है
      Apple के पास downgrade allow न करने की कोई वास्तविक technical वजह लगभग नहीं है
    • यह देखते हुए कि वे product बेच रहे हैं और नया OS कल ही आया है, यह भी काफी हैरान करने वाला है

  • Sequoia में अगर macOS firewall enabled है और कोई app “incoming connections block” के रूप में registered है, तो उस app की DNS इस्तेमाल करने की क्षमता, और शायद UDP-based functions कुल मिलाकर, टूट जाते हैं
    https://waclaw.blog/macos-firewall-blocking-web-browsing-aft...

    • reproduce नहीं हो रहा। कुछ लोग कहते हैं कि इसका संबंध ESET से है: https://www.reddit.com/r/MacOS/comments/1fievr5/updating_mad...
    • Sequoia से पहले VPN पर OpenDNS इस्तेमाल करने के बावजूद, VPN से connected रहते हुए iMessage और दूसरे apps चलते रहते थे; Sequoia के बाद VPN connection के दौरान iMessage texts वगैरह अब काम नहीं करते
      VPN disconnect करने पर सब कुछ pass हो जाता है
      सोच रहा हूं कि क्या इसका इससे कोई संबंध है। macOS firewall enabled है, लेकिन सभी incoming connections blocked नहीं हैं
    • Sequoia पर upgrade करने के बाद Safari या Mozilla से browsing नहीं कर पा रहा था
      Wi-Fi connection की DNS settings में जाकर Google DNS servers 8.8.8.8 और 8.8.4.4 जोड़ दिए, तो समस्या हल हो गई, और उन्होंने पहले से automatically भरे हुए DNS servers को replace कर दिया
    • सच कहूं तो मुझे यह behavior ठीक लगता है। applications को settings में specified चीज़ों के बाहर जाकर खुद DNS resolve नहीं करना चाहिए
      apps ऐसा इसलिए करते हैं ताकि user telemetry जैसी चीज़ों को block न कर सके
      यह मेरा computer है, इसलिए बाहर क्या जाता है, इस पर अंतिम फैसला मेरा होना चाहिए

  • शीर्षक से ऐसा संकेत मिलता है जैसे यह जानबूझकर किया गया हो या Apple पर विशेषाधिकार के तौर पर लागू होता हो, लेकिन असल में यह बस bug के ज्यादा करीब दिखता है
    अगर ऐसी चीज़ report की गई है, तो FB नंबर और report की details भी साथ में डालना अच्छा होगा

    • शैतान के वकील की तरह देखें तो, विरोध से बचने के लिए इसे जानबूझकर ऐसा बनाया गया और फिर ऐसे bug जैसा दिखाया गया हो जिसे ठीक नहीं किया जा रहा
      लक्ष्य हासिल हो जाए तो implementation का तरीका कितना भी flexible हो सकता है
    • अगर यह जानबूझकर होता, तो शायद hardcoded और encrypted URL होता
      कुछ devices ने ad blocking को bypass करने के लिए पहले ही ऐसा तरीका इस्तेमाल करना शुरू कर दिया है

  • हो सकता है मेरी गलतफहमी हो, लेकिन हर नए iOS या Mac release पर DNS समस्याएं आती हैं और Little Snitch, Mullvad जैसी चीज़ों को प्रभावित करती हैं—ऐसा déjà vu सा लगता है
    अगर यह सच है, तो सच में सवाल उठता है कि Apple महीनों की developer और beta testing के दौरान करता क्या है

  • Little Snitch का ज़िक्र उलझाने वाला था, लेकिन और पढ़ने पर यह कुछ खास cases में ही होने वाला LS bug लगता है
    अगर यह LS blog है, तो बस यही सवाल है कि इसे macOS bug जैसा क्यों बताया जा रहा है
    मेरा मतलब यह नहीं कि वे गलत हैं; यह उनका क्षेत्र है, मेरा नहीं, लेकिन text के आधार पर यह ठीक से justified नहीं दिखता

    • अगर OS DNS proxy registration की अनुमति देता है और कुछ calls उस proxy को bypass कर देती हैं, तो यह साफ तौर पर OS bug है

  • मुझे याद है कि Apple ने third-party developers के लिए किसी खास network API के इस्तेमाल को deprecated कर दिया था
    लेकिन Apple के अपने apps, जैसे App Store, पर वही restrictions लागू नहीं होते
    इसलिए जब नए API से app firewall के जरिए network traffic filter करने की कोशिश की गई, तो App Store के legacy API इस्तेमाल करने की वजह से वह fail हो गया
    यह किसी पुराने bug का हिस्सा हो सकता है, जिसे मैंने समझा था कि पहले ही ठीक कर दिया गया था

    • getaddrinfo() कोई legacy API नहीं है; यह DNS lookup के लिए standard cross-platform API है

  • “नए OS release में bug मिला! Correction: दरअसल यह काफी समय से मौजूद bug था!” जैसी घोषणाएं हमेशा मज़ेदार होती हैं

  • local stub resolver के तौर पर routedns [0] का इस्तेमाल करके खुद चुन रहा हूं कि कौन-सी requests कहां भेजनी हैं और कौन-सा transport method इस्तेमाल करना है
    blocklist, rewrite, cache, load balancing और alternate request handling भी संभव है, इसलिए काफी control मिलता है
    local requests के लिए localhost:53 का stub listener इस्तेमाल करता हूं, और ज्यादातर requests cache के साथ UDP QUIC, यानी TLS 0-RTT के जरिए Cloudflare 1.1.1.1 पर forward करता हूं
    यह तेज़ और काफी सुरक्षित है
    [0] https://github.com/folbricht/routedns
 
nearfall 2024-09-18

महत्वपूर्ण जानकारी के लिए धन्यवाद।
फिलहाल Safari और Chrome को लेकर निश्चिंत रहा जा सकता है, यह राहत की बात है।