Android 14: क्या root अधिकार भी system certificates में बदलाव रोकते हैं?

 (httptoolkit.com)
1 पॉइंट द्वारा GN⁺ 2023-09-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Android 14 (API v34) में system CA certificates को /system के बजाय APEX-आधारित com.android.conscrypt module से पढ़ने में बदला गया है, जिससे root अधिकारों के साथ certificates inject करने वाला पुराना debugging flow टूट गया
  • Android 7 Nougat के बाद app का default trust store system CA और user CA में बंट गया था, इसलिए development, testing और reverse engineering tools system CA directory को सीधे modify करने के तरीके पर निर्भर रहे हैं
  • नया structure CA certificates को Google Play System Update के जरिए update करने देता है, जिससे problematic CA हटाना और नए CA deploy करना तेज होता है, लेकिन device owner का control घटता है
  • Android 14 beta emulator में /system/etc/security/cacerts, /system/etc/security/cacerts_google, /apex/com.android.conscrypt/cacerts आदि को tmpfs से ढकने या delete करने पर भी Settings और apps Google CA list ही देखते रहते हैं
  • लेख लिखे जाने के समय Android 13 पर बने रहना या APEX इस्तेमाल न करने वाला custom OS realistic विकल्प था; बाद के updates में बताया गया कि Android 14 certificate injection bypass के कई तरीके सामने आए

Android CA management कैसे बदलता रहा

  • Android ने 2007 में Open Handset Alliance announcement के समय “open platform”, “complete access to handset capabilities and tools” जैसी expressions के साथ openness पर जोर दिया था
  • समय के साथ users, developers और researchers अपने device को कितना control कर सकते हैं, इसका दायरा धीरे-धीरे घटा है—ऐसा आकलन किया जाता है

  • Android 7 Nougat का बदलाव

    • device owner द्वारा modify की जा सकने वाली CA list को system CA और user CA में बांट दिया गया
    • OS vendor द्वारा दी गई fixed system CA list सभी apps की default बन गई
    • user द्वारा modify की जा सकने वाली CA list केवल तब इस्तेमाल होती है जब app ने explicitly opt-in किया हो
    • नतीजतन लगभग सभी apps ने user CA को default रूप से trust करना बंद कर दिया

CA certificates क्यों महत्वपूर्ण हैं

  • device के trusted CA उन organizations की list होते हैं जो encrypted network traffic की security की गारंटी देते हैं
  • CA, HTTPS जैसे TLS connections में इस्तेमाल होने वाले certificates किसी भी domain के लिए issue कर सकता है, और उस CA को trust करने वाला device उस certificate को valid connection के proof के रूप में स्वीकार करता है
  • अगर user अपने बनाए हुए CA को device में trusted बना दे, तो वह अपने HTTPS या TLS traffic को intercept करके देख सकता है
    • phone द्वारा भेजे और प्राप्त किए जा रहे data को check किया जा सकता है
    • जरूरत पड़ने पर उसे modify या block किया जा सकता है
  • ऐसा control security और privacy research, reverse engineering, app debugging/testing, enterprise internal network setup, और default CA पर trust न करने वाले users के लिए महत्वपूर्ण है
  • non-technical users के लिए गलती से CA बदलना कठिन बनाना, या user को बताए बिना CA बदलने से रोकना reasonable है, लेकिन advanced users का control भी सीमित करने पर कई use cases मुश्किल हो जाते हैं

Android 7 के बाद root-based workaround

  • Android 7 के बाद भी root access वाले devices में system CA store को सीधे manipulate किया जा सकता था
  • आम तरीका /system/etc/security/cacerts/ में trusted certificate डालना था
  • /system आम तौर पर root devices में भी read-only होता है, इसलिए दो तरीके इस्तेमाल होते थे
    • /system directory को writable बनाकर reboot करना और फिर real system certificate directory को modify करना
    • read-only directory के ऊपर temporary read/write filesystem mount करना, existing CA copy करना और फिर नया certificate जोड़ना
  • certificate को system द्वारा accept कराने के लिए file name, permissions, SELinux label जैसी conditions भी match करनी पड़ती थीं
  • HTTP Toolkit ने temporary mount-based procedure को automate करके root Android devices या emulators पर one-click interception setup दिया है
  • यह approach custom rooted devices, special Android distributions, और Google official emulator images के ज्यादातर variants पर काम करता था
    • locked full “Google Play” edition images, जैसे सामान्य OEM devices, exception हैं
  • mitmproxy setup documentation, कई blog posts, StackOverflow answers, forum posts, Magisk packages और cacert.org guides भी इसी तरह के तरीके इस्तेमाल करते थे

Android 14 का नया CA update structure

  • लेख लिखे जाने के समय Android 14 final beta stage में था और कुछ हफ्तों में release होने वाला था
  • इसके प्रमुख security features में से एक remotely updateable CA certificates है
  • CA certificate management को core OS image से अलग करके Google Play के जरिए deploy और update होने वाले अलग component में ले जाया गया है
  • इस structure में Google problematic CA पर trust को ज्यादा जल्दी revoke कर सकता है
    • हर phone vendor द्वारा पूरा OS OTA update deploy करने का इंतजार करने की जरूरत घटती है
    • केवल Google Play System Update से Android 14+ devices की CA list बदली जा सकती है
  • default trusted CA के पास strong privileges होते हैं, इसलिए oversight और sanctions जरूरी हैं, और failed CA के privileges जल्दी हटाए जाने चाहिए
  • उदाहरण के लिए जनवरी 2023 में TrustCor ने malware distribution organization और US defense/intelligence contractors के साथ करीबी संबंध सामने आने के बाद Google समेत major parties से CA trust खो दिया
  • उलटी दिशा में, नए CA deployment में देरी भी समस्या बनती है
    • Let’s Encrypt को old Android devices में latest root CA न होने के कारण signing chain improvements का deployment कई बार टालना पड़ा
  • CA update responsiveness बढ़ाने वाला structure अपने आप में valuable है, लेकिन Android 14 implementation system CA modification को practically मुश्किल बना देता है

वास्तविक file locations और APEX behavior

  • Android 14 का key change यह है कि मौजूदा /system/etc/security/cacerts के बजाय, अगर /apex/com.android.conscrypt/cacerts मौजूद है तो certificates वहीं से पढ़े जाते हैं
  • /apex वह path है जहां Android Pony EXpress, यानी APEX containers, mount होते हैं
  • APEX modules independently updateable system components हैं, और signed immutable containers के रूप में deploy होते हैं
  • Android 14 के CA certificates Android की core TLS/SSL library com.android.conscrypt module का हिस्सा बन गए हैं
  • APEX का low-level behavior पर्याप्त रूप से documented नहीं है, और कहा जाता है कि कुछ key details के links केवल Google internal sites पर हैं
  • testing में दिखा कि APEX module content individual processes को direct expose होता है, इसलिए दूसरी location पर files modify करने से apps को दिखने वाले content में बदलाव reflect नहीं होता

Android 14 emulator में देखी गई बातें

  • Android 14 beta official emulator के AOSP और “Play Services” images root access देते हैं
    • “Google Play” images सामान्य OEM devices की तरह locked हैं
  • API 34 “Google APIs” image से emulator बनाकर root shell खोला जा सकता है
  • पुराने temporary mount तरीके से नीचे दिए paths को tmpfs से ढकने पर भी expected effect नहीं मिला
    • /system/etc/security/cacerts
    • /system/etc/security/cacerts_google
    • /apex/com.android.conscrypt/cacerts
    • /apex/com.android.conscrypt@340818022/cacerts
  • Settings → Security & Privacy → More → Encryption → Trusted Credentials के “System” tab में वे certificates वैसे ही दिखते रहे जिन्हें छिपा दिया गया समझा गया था
  • उदाहरण के लिए “ACCV” certificate file 3c9a4d3b.0 को पूरे filesystem में खोजने पर mount से ढके होने के दौरान वह नहीं दिखी, लेकिन Settings में दिखती रही
  • यही procedure Android 13 image पर चलाने पर Settings की certificate list खाली हो जाती है, यानी पुराना तरीका expected तरीके से काम करता है

system image को सीधे modify करना भी विफल

  • Android 14 emulator को -writable-system के साथ start करके adb root, adb remount, avbctl disable-verification, reboot आदि के बाद writable बनाया जा सकता है
  • इसके बाद /system/etc/security/cacerts/*, /system/etc/security/cacerts_google/* के certificates delete किए जा सके
  • लेकिन /apex के certificates delete नहीं किए जा सके
    • remount के बाद भी यह read-only रहा
    • mount -o remount,rw ... command भी fail हुई
  • सबसे नजदीकी संभव manipulation बस इतना था कि संबंधित certificate path को umount करके mount output से गायब कर दिया जाए
  • फिर भी Settings की “Trusted” list में CA certificates load होते रहे
  • यह Settings app cache की समस्या नहीं, बल्कि apps द्वारा देखे जाने वाले certificate store के perspective से भी वही behavior माना गया
  • filesystem को जैसे भी modify किया गया, apps Google की CA list ही देखते रहे

impact और limitations

  • Android 14 में पुराने तरीके से system CA certificate install करके debugging, reverse engineering, testing और research में इस्तेमाल होने वाला flow टूट जाता है
  • लेख लिखे जाने के समय alternatives थे: Android 13 पर बने रहना, या CA certificate management के लिए APEX module इस्तेमाल न करने वाला custom OS release इस्तेमाल करना
  • समय के साथ Android Mainline के core internal components से अलग होना या पुराने software का इस्तेमाल जारी रखना पड़ेगा, इसलिए ऐसे alternatives धीरे-धीरे कम practical हो सकते हैं
  • अगर APEX module के अंदर का content root rights से भी modify नहीं किया जा सकता, तो आगे APEX में move होने वाले हर system component के साथ user control घट सकता है
  • GrapheneOS, LineageOS जैसे Android forks और Magisk तथा कई modules के लिए भी यह समस्या बन सकती है
  • हालांकि ऊपर दिए update के अनुसार बाद की discussions और bypass research से Android 14 में भी certificate injection संभव बनाने वाले कई solutions सामने आए
  • Android 14 में HTTPS traffic debug करने के लिए अब केवल पुराने root-based system CA injection को आधार मानना मुश्किल है

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

1 टिप्पणियां

 
GN⁺ 2023-09-06
Hacker News की राय

  • पुराने Android root टूल्स और आधुनिक general-purpose custom ROMs, और Android OS से जुड़े कई काम कर चुके व्यक्ति के तौर पर मुझे लगता है कि शीर्षक अभी भी और आगे भी गलत है
    Android में root का मतलब सचमुच root privileges है, और आप जो चाहें कर सकते हैं [1]
    मौजूदा Android root, यानी Magisk, में Java code तक “modify” करने की क्षमता शामिल है, इसलिए चीज़ कितनी भी अंदर छिपी हो, उस तक पहुंच होनी चाहिए
    लेखक नहीं कर पाए, इसका मतलब यह नहीं कि यह असंभव है; मुमकिन है समस्या यह हो कि zygote CA को cache करता है इसलिए stop;start से restart करना पड़े, या command चलाने से पहले सही mount namespace में switch करना पड़े
    GrapheneOS और LineageOS के पास पूरे source code की access है, इसलिए वे अपनी मर्ज़ी से बदल सकते हैं; सीमा बस इतनी है कि Google जिन चीज़ों को जबरदस्त रफ्तार से तोड़ता है, उनके साथ बने रहना झंझट है
    उम्मीद है कि जैसे-जैसे Android users, खासकर power users, के प्रति और शत्रुतापूर्ण होता जा रहा है, और लोग custom ROMs की ओर जाएंगे
    सपनों में तो मैं “OwnerDroid” जैसा Android fork बनाता हूं, जिसके security model की पहली लाइन “user is the enemy” न हो, लेकिन मैंने बस कुछ छोटे-छोटे ईंट जैसे हिस्से बनाए हैं; पूरा project बहुत भारी काम मांगता है
    [1] कुछ kernel-level protections अपवाद हैं, लेकिन GKI उस जोखिम को कम कर देता है

    • मुख्य बात यह है कि पहले Google की stock OS images पर भी, बिना कोई tool install किए, कोई भी disk पर लिखकर इस certificate को सीधे modify कर सकता था; यह तरीका व्यापक रूप से इस्तेमाल होता था और कई tools की setup guides में भी शामिल था
      अब ऐसा नहीं किया जा सकता
      बेशक, अगर पूरा source code हो तो कुछ भी संभव है, और आप शुरुआत से ऐसा Android system image build कर सकते हैं जिसमें यह module disabled हो; GrapheneOS/LineageOS भी इससे निपट सकते हैं
      लेकिन इससे बहुत नया काम पैदा होगा, और core components में Android implementation से अलग होने पर आगे भी ज्यादा maintenance की जरूरत पड़ सकती है
      प्रभावित होने वाले ज्यादातर users के लिए “पहले अपना system image खुद build करो” कहना उनकी सुविधा और समय निवेश की सीमा से बहुत आगे है
      आखिरकार कोई दूसरा समाधान आएगा, लेकिन वह शायद namespaces में अंदर जाकर target process के mounts को अलग-अलग modify करने, या Android जिस तरह trust करता है उस तरह अपना APEX module build/install करके system module को replace करने, या Frida से अलग-अलग apps में hooking करने जैसा होगा
      फिर भी यह users के लिए अपने device पर पूरा control रखना और मुश्किल बनाने वाली बड़ी समस्या है
    • जो लोग custom ROMs से छेड़छाड़ करना कुछ हद तक छोड़ चुके हैं, उनका क्या होगा
      जरूरी banking apps की root checks या Google-related features जैसी अहम चीज़ें documented नहीं होतीं, और “phone model + local bank app + custom ROM” का combination test होकर ठीक चलता है, ऐसी जानकारी मिलना भी लगभग असंभव है
      मैं freedom और choice के पक्ष में हूं, लेकिन अगर औसत phone user कई phones और कई दिनों का working time न लगा सके, या शुरू से expert न हो, तो इसे व्यवहारिक रास्ता कहना मुश्किल है
      Computer पर मैं power user हूं, लेकिन मुझे लगता है phone थोड़ा ज्यादा dumb हो तो भी ठीक है
      हालांकि जब phone को धीरे-धीरे multi-factor authentication device की तरह इस्तेमाल करना पड़े, या banks जैसी ज्यादा leverage वाली companies की मनमानी से बंधना पड़े, तो ऐसा रहना मुश्किल हो जाता है
      Rooted phone पर चलने वाला app खोजने के लिए मैं अपना bank account तीन बार बदलने वाला नहीं हूं
    • Google का बहुत तेज़ी से चीज़ें तोड़ना और दूसरों को पीछे-पीछे भागने पर मजबूर करना, competitors को catch up में busy रखने की strategy है: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
      अगर आप पूछें “Android fork भला कौन सा competitor है”, तो इसका मतलब है कि strategy काम कर रही है
    • Article को बस ऊपर-ऊपर से देखें तो workaround खुद काफी आसान लगता है
      अगर नया तरीका /apex/com.android.conscrypt/cacerts मौजूद होने पर certificates वहीं से पढ़ता है, तो मौजूदा SafetyNet bypass, root hiding, Magisk hiding की तरह सिर्फ जरूरी processes में /apex/com.android.conscrypt/cacerts को hide करके पुराने तरीके पर fallback कराया जा सकता है
    • मुझे नहीं लगता custom ROMs mainstream बनेंगे, चाहे Google या Apple कितना भी बुरा व्यवहार करें
      यह hackers का इलाका है, और उनमें से भी बहुत छोटा हिस्सा ही इन्हें इस्तेमाल करता है

  • यहां कई अच्छे comments हैं, लेकिन मैं बार-बार सोचता हूं कि यह कितनी राहत की बात है कि PC smartphones की तरह behave नहीं करते
    Android ने खुद को इतनी बुरी तरह बिगाड़ लिया है कि मुझे खुद अजीब लगता है जब मैं कहता हूं कि शुक्र है Microsoft PC दुनिया को वैसे नहीं चलाता जैसे Google smartphone दुनिया को चलाता है
    Android की तुलना में Windows खुद stability और common sense का गढ़ सा है, और hardware सचमुच पुराना होकर खराब होने से पहले upgrade करने के लिए मजबूर होने की जरूरत भी नहीं पड़ती
    Google की तरह Microsoft भी पूरी hardware-software pipeline control नहीं करता, लेकिन उसके पास stores के जरिए norms enforce करने या SafetyNet जैसे तरीकों से environment changes रोककर PC ownership को बेहद असुविधाजनक बनाने की ताकत थी
    धुंधला-सा याद है कि कभी Microsoft पर ऐसी चीज़ों के लिए antitrust lawsuit हुआ था; सोचता हूं Google के साथ ऐसा कब होगा

    • Windows करीब 20 साल से regular CA updates करता आया है, और इस लिहाज से अब Android ही Windows की तरह behave कर रहा है
      Microsoft ने भी Windows में ढेर सारे DRM जोड़े, बाद में उनमें से कुछ तोड़े भी, और remote attestation भी OS में built-in है
      Google ने Android की ऐसी internal implementation बदल दी जिस पर असल में depend नहीं करना चाहिए था, जिससे developers को परेशानी हुई; Microsoft भी ऐसी चीज़ें हमेशा करता है
      Updated Magisk module के लिए कुछ हफ्ते इंतज़ार करना पड़ेगा, इसकी संभावना ज्यादा है, और ईमानदारी से कहें तो यह इतना भी खराब नहीं है
      जिन 5–6 devices को Android 14 मिलेगा, उन पर तब तक बस update button न दबाना काफी है
    • Microsoft ने भी कोशिश की थी, बस नाकाम रहा, और अब भी कोशिश कर रहा है
      Windows 11 TPM और Secure Boot मांगता है
    • मुझे लगता है इससे users को फायदा भी हो सकता है
      मैंने सुना है कि कुछ developing countries सभी connections पर man-in-the-middle attack करने के लिए national CA install करने की मांग करती हैं; अगर इसे बहुत मुश्किल बना दिया जाए, तो users से उनकी privacy बंद करवा देना व्यवहारिक रूप से कठिन हो जाएगा

  • PinePhone Pro को डेली ड्राइवर के तौर पर इस्तेमाल कर रहा हूँ
    Chase.com, Librewolf जैसे non-standard ब्राउज़र और फोन/टैबलेट ब्राउज़र के इस्तेमाल को सचमुच जिद्दी तरीके से रोकने की कोशिश करता है, और मोबाइल ऐप इस्तेमाल करने पर मजबूर करना चाहता है
    कम-से-कम WEI के अनिवार्य होने तक, ऐसी बेवकूफी भरी चीजें आसानी से bypass हो जाती हैं, इसलिए यह कोई गंभीर समस्या नहीं है, लेकिन Chase एक बैंक है, इसलिए सोचता हूँ कि क्या इस पर कानूनी रूप से लड़ने की गुंजाइश है
    पहली अटकल ADA compliance की तरफ है, लेकिन पक्का नहीं हूँ
    अब इतना थक गया हूँ कि इस मुद्दे पर मुकदमा करना चाहता हूँ—यह बात मज़ाक है या नहीं, मुझे भी नहीं पता
    थोड़ा अलग मुद्दा है, लेकिन संबंधित है, क्योंकि यह दिखाता है कि मोबाइल OS oligopoly से बाहर निकलना लगभग असंभव है
    अगर Linux फोन niche किसी चमत्कार से कुछ प्रतिशत तक बढ़ भी जाए, तब भी Android के लगातार बदतर होते जाने की संभावना बड़ी है, और कुछ चाहिए

    • अंधकार युग आ रहा है, सच में
      लगता है digital serfdom का दौर आएगा
      आप किसी “दयालु” कंपनी द्वारा दिया गया डिवाइस इस्तेमाल करेंगे, वह कंपनी डिवाइस के हर पहलू की मालिक होगी, और आप पैसे देकर ही उसे चला पाएँगे—मानो ड्राइव कर रहे हों
      बाकी रास्ते ज्यादातर बंद होंगे, general-purpose computing सिर्फ “enterprise” के लिए रह जाएगी, और “free web” होगा तो सही, लेकिन काफी तकनीकी और user-hostile होगा
      ज्यादातर बाजार, खासकर जहाँ भी पैसे का लेन-देन है, उससे महामारी की तरह बचेंगे
    • अगर आप Chase के ग्राहक बने रहते हैं, तो आप उनके predatory attitude का समर्थन कर रहे हैं, और बाकी industry को भी संकेत दे रहे हैं कि वही रवैया अपनाना ठीक है
    • “कम-से-कम WEI के अनिवार्य होने तक” वाला हिस्सा दुखद है
      मुझे लगता है Google ने इससे open web को मार दिया
      वैसे भी यह थोड़ा उबाऊ होता जा रहा था, लेकिन अब फोन या “approved” ब्राउज़र के बिना जीना कहीं ज्यादा मुश्किल हो गया है, जो खीझ पैदा करता है
    • अगर आपको ऐसी accessibility features चाहिए जो सिर्फ alternative ब्राउज़र में मिलती हैं, तो Chase से संपर्क करना बेहतर होगा
      अनुभवी user अतिरिक्त software install करके समस्या ठीक कर सकता है, यह अच्छी बात है, लेकिन बेहतर होगा कि Chase अपनी basic website ठीक करे ताकि समान जरूरत वाले beginner users को भी मदद मिले

  • इस मामले में मुझे लगता है Android, Apple से ज्यादा coercive था और अब भी है
    जब नया root CA install करके trust किया जा सकता था, तब भी कुछ apps इसे ignore कर सकते थे और सच में करते भी थे
    iOS और Android दोनों में apps certificate pinning इस्तेमाल कर सकते हैं, लेकिन Android 7+ में 2016 से default रूप से apps user द्वारा जोड़े गए CA को ignore करते हैं[1]
    iOS में root CA को trust करने की प्रक्रिया profile install और डरावनी warnings से गुजरती है, इसलिए झंझट भरी है, और वह अपने आप में उचित है, लेकिन मेरे अनुभव में certificate pinning न हो तो ज्यादातर apps इसे trust करते हैं
    [1]: https://android-developers.googleblog.com/2016/07/changes-to...

    • Google ने Android 7 में ऐसा क्यों किया, यह समझ आता है
      Android, iOS की तुलना में सामान्य computer के कहीं ज्यादा करीब है, इसलिए इसमें stalkerware की समस्या बहुत बड़ी है
      stalkerware prompts से नहीं रुकता, backward compatibility को हथियार बनाता है, और हर तरह के abuse को शामिल करता है
      iOS पर किसी को 5 मिनट के लिए फोन उधार देने के बाद सालों तक HTTPS privacy उलट जाना हैरान करने वाली हद तक आसान है
      installed CA certificate पर सचमुच trust करने का विकल्प मैं चाहता हूँ, लेकिन खासकर यह बात गुस्सा दिलाती है कि web browser Firefox तक hidden tabs और settings के बिना user certificates इस्तेमाल नहीं करता
      फिर भी दुनिया भर के Android users के लिए पैदा होने वाले जोखिम को देखते हुए, रोजमर्रा में इस्तेमाल करने वाले कुछ दर्जन तकनीकी लोगों के लिए यह feature उतना महत्वपूर्ण है, ऐसा कहना मुश्किल है
      यह मामला स्थानीय IT department की योजना बिगाड़ने की Google की कोई शैतानी साजिश नहीं, बल्कि Google के अच्छे sandboxing improvements और लंबे समय से delay हुए CA store update mechanism के side effect जैसा ज्यादा लगता है
      Magisk module जल्द ही workaround के रूप में आ जाएगा, और पुराने modules कुछ समय के लिए टूटेंगे, लेकिन major Android update के बाद यह आम बात है
      जरूरत हो तो सीधे module लिख भी सकते हैं
    • iOS में ऐसे apps भी हैं जो VPN connection को ignore कर सकते हैं: https://restoreprivacy.com/latest-ios-found-to-bypass-vpn-co...

  • मुझे लगता है यह बस mount के काम करने का तरीका ही है
    अगर /apex/whatever पर कुछ mount है और हर app का अलग mount namespace है, तो अपने namespace में /apex/whatever के ऊपर फिर से mount करने से दूसरे namespaces में कोई बदलाव नहीं होगा
    filesystem को सीधे बदलना होगा, या दूसरे app के mount namespace में जाकर वहाँ भी tmpfs mount करना होगा
    shared mount मदद कर सकता है, लेकिन पक्का नहीं हूँ, और असल में क्या हो रहा है इसे और detail में देखना होगा
    मुझे लगता है यह नतीजा root privileges के साथ भी user को root CA बदलने से रोकने की जानबूझकर की गई कोशिश से ज्यादा Google के namespace/containerization काम का byproduct होने की संभावना रखता है

    • असल में मुझे लगता है वह बात सही है
      लेकिन अंतिम नतीजा फिर भी बड़ी समस्या है
      यहाँ चौंकाने वाली बात “अलग mount namespace” है
      पहले shell खोलकर filesystem पर mount कर दें या सीधे modify कर दें, तो apps उस mount से files ठीक से पढ़ लेते थे
      अब इन cacert files के साथ ऐसा नहीं है, और नए तरीके में direct modification भी संभव नहीं है
      इस बदलाव से पहले मुझे यह भी नहीं पता था कि Android apps अपना mount namespace इस्तेमाल करते हैं
      यह ठीक-ठीक कैसे काम करता है, इसकी documentation बहुत कम है, और यह भी नहीं पता कि अब तक ऐसा कोई मामला था जहाँ यह इतनी साफ तरह सामने आया हो
    • जब technology business goals के लिए बहाना ढूँढने लायक काफी complex हो जाती है, तो बहुत सुविधाजनक होती है
      manifest v3 को देखिए

  • मैंने लेखक को Twitter पर reply किया था, लेकिन शायद उन्होंने नहीं देखा, इसलिए यहाँ भी छोड़ रहा हूँ
    मैं वही व्यक्ति हूँ जिसने Android 14 के updateable certificates पर blog post लिखा था, और वह post article में linked है
    असल में एक system property है जिसे APEX certificate directory से पढ़ने को bypass करने के लिए set किया जा सकता है
    system.certs.enabled=true
    स्रोत: https://android-review.googlesource.com/c/platform/framework...

    • अफसोस, लगता नहीं कि इससे बहुत मदद मिलेगी
      वह android.os.SystemProperties OS property नहीं है, यानी ऐसी value नहीं जिसे adb से device-wide set किया जा सके; बल्कि वह java.lang.System property है, मतलब एक JVM/app के अंदर set होने वाला configuration value
      मुझे लगता है कि पहली वाली चीज़ को फिर से set करने के लिए app को ही modify करना पड़ेगा
      automated tests के लिए या debug/prod builds के बीच setting toggle करने के लिए यह उपयोगी है, लेकिन जब आप पूरे device पर CA certificate को trusted बनाना चाहते हैं, तब यह खास मददगार नहीं है
      हाँ, अगर आपको इसे बाहर से set करके सभी apps पर apply करने का तरीका पता है, तो यह सच में बहुत अच्छी तरह काम करेगा—मैं जरूर सुनना चाहूँगा
      वैसे, मैं ही लेखक हूँ, और Twitter पर ऐसा कोई reply दिखाई नहीं दे रहा
      वाकई, 2023 वाले Twitter जैसा ही

  • security के लिए अच्छा लगता है और कुछ developers के लिए नरक जैसा, लेकिन सोचता हूँ कि 2–3 साल बाद जब यह Android version छोड़ दिया जाएगा तो क्या होगा
    क्या बस दुआ करनी होगी कि hardcoded certificates कुछ और साल टिक जाएँ

    • यह एक ज्ञात समस्या थी जिसे certificate providers को काफी पहले से ध्यान में रखना चाहिए था [0], लेकिन Android 14 से लगता है अब ऐसा नहीं है [1]
      Android 14 root certificates को Google Play के जरिए updateable बनाता है, और पहले की तरह root certificates जोड़ने या हटाने के लिए OTA update की जरूरत नहीं होती
      आज पता चला एक workaround भी है [0]
      कहा गया है कि अगर आप Android 7.0 या उससे नीचे चला रहे हैं, तो Let’s Encrypt certificate से protected websites तक access जारी रखने के लिए action लेना पड़ सकता है, और Firefox Mobile install/use करने की सिफारिश की गई है, जो Android OS trust store के बजाय अपना trust store इस्तेमाल करता है
      [0] https://letsencrypt.org/2023/07/10/cross-sign-expiration.htm...
      [1] https://www.xda-developers.com/android-14-root-certificates-...
    • अपने self-hosted password manager को चलाने के लिए मुझे Let’s Encrypt certificate install करना पड़ा था
      क्योंकि Google update में Let’s Encrypt द्वारा इस्तेमाल किया गया intermediate certificate शामिल नहीं था
      यह भविष्य की काल्पनिक समस्या नहीं, बल्कि अभी मौजूद समस्या है
      Google ही क्यों तय करे कि मैं किस पर भरोसा करूँ
      Google में भी निश्चित रूप से कमियाँ हैं
      और already approved certificate providers में भी कुछ ऐसे हैं जिनका इतिहास ऐसे लोगों और संगठनों को certificates जारी करने का रहा है जिन्हें वे नहीं मिलने चाहिए थे, इसलिए वास्तव में उन पर भरोसा नहीं किया जाना चाहिए
    • मेरी पत्नी को ठीक इसी वजह से अपना phone बदलना पड़ा
      apps आम तौर पर user certificates स्वीकार नहीं करते, और Google Cloud या उससे जुड़ी किसी चीज़ के newer certificate पर switch होने से कुछ apps ने काम करना बंद कर दिया
    • certificates अब APEX module बन गए हैं, और लेखक की शिकायत का मुख्य बिंदु यही है
      यानी वे Play Services के जरिए out-of-band update होते हैं और OEM के OS update की जरूरत नहीं होती
    • Android 14 से इन्हें Google Play के जरिए update किया जा सकता है, इसलिए ये OS updates से बंधे नहीं हैं

  • हर Android release के साथ देखता हूँ कि कुछ न कुछ हटाया जाता है और बहुत मायने न रखने वाली चीजें जोड़ दी जाती हैं
    iOS उलटी दिशा में चलता दिखता है, इसलिए लगता है कि धीरे-धीरे दोनों बीच में मिलेंगे और बाद में iOS हर मामले में Android से आगे निकल सकता है
    Apple वाले लोगों की ईमानदार राय सुनना चाहूँगा
    आजकल macOS इस्तेमाल कर रहा हूँ, और यह Windows/Linux में दशकों से obvious रहे बहुत बुनियादी user experience पर fail होता है, इसलिए नापसंद है
    Finder जैसी चीज़ तो सच में बेहद खराब है
    अगर अगली बार Android के बजाय iPhone खरीदूँ, तो क्या iOS पर भी मेरी वही नकारात्मक प्रतिक्रिया होगी
    smartphone use case में क्या iOS को macOS से ज्यादा polished और उपयोगी user experience माना जा सकता है
    switch करना तो चाहता हूँ, लेकिन समय और पैसा बर्बाद नहीं करना चाहता

    • अगर App Store restrictions खत्म हो जाएँ और app sideloading आसान हो जाए, तो मुझे Android की iOS पर एक भी बढ़त याद नहीं आएगी
      पुराना Android सिर्फ .apk वाला iOS भर नहीं था; सच में अफसोस है
    • iPhone को सुबह HN scroll करने, portable audio player की तरह इस्तेमाल करने, चलते-फिरते चीजें lookup करने और phone calls के लिए ही इस्तेमाल करता हूँ
      उस काम के लिए ठीक है
      लेकिन user बहुत ज्यादा restricted है, इसलिए jailbreak देखने का सोच सकता हूँ; मगर मैं phone use कम से कम रखना और लगभग सब कुछ desktop पर करना चाहता हूँ
      वैसे मैं macOS भी छोड़कर Linux पर जा रहा हूँ
    • return policy होती है, तो Mint जैसे prepaid carrier के साथ एक बार try करके देख सकते हैं

  • मैं self-hosted software तक पहुँचने के लिए personal PKI इस्तेमाल कर रहा हूँ
    जैसे email server, calendar provider, notes server, photo sync tool वगैरह
    मुझे अपना root certificate certificate authorities की सूची में जोड़ पाने की सुविधा चाहिए
    मैं system-provided list बदलना नहीं चाहता, बस अपना certificate जोड़ना चाहता हूँ
    यह मेरा device है, इसलिए मेरी राय में अगर मैं चाहूँ तो मुझे कुछ भी बदल पाने की सुविधा होनी चाहिए

    • आप user certificate store में अपना CA certificate install कर सकते हैं, और Chrome तथा वे दूसरे apps जो user-installed CA पर भरोसा करना चुनते हैं, उस पर भरोसा करते हैं
      email और calendar apps भी शायद इसमें शामिल होंगे
      जहाँ काम न करने की संभावना ज़्यादा है, वह है अपना CA install करके app और app maker के server के बीच traffic intercept करना
      यह अफसोस की बात है, क्योंकि आपको यह जाँच पाने में सक्षम होना चाहिए कि आपका device क्या कर रहा है, लेकिन self-hosted software के लिए personal PKI वाला use case निश्चित रूप से supported है
    • मेरे साथ भी ऐसा ही है, और क्या corporate IT policies भी devices पर root certificates बहुत deploy नहीं करतीं?
      लगता है कोई न कोई तरीका होना चाहिए
    • एक alternative यह है कि private network में public CA इस्तेमाल किया जाए
      इसके लिए getlocalcert पर tool बनाया जा रहा है [1]
      trust root जोड़ने की ज़रूरत से बचा जा सकता है, इसलिए कुछ networks में “private network पर public certificate” approach कुल मिलाकर फायदेमंद है
      सच कहूँ तो मैंने उम्मीद नहीं की थी कि Android private CA को block करेगा, लेकिन आखिरकार यही हुआ
      [1] https://www.getlocalcert.net/
    • मैं भी उसी हिस्से को लेकर confused था
      अभी Android phone इस्तेमाल नहीं करता, लेकिन मुझे याद है कि पहले root access के बिना, सिर्फ settings के नीचे मौजूद option से, Android phone में अपना CA certificate add किया जा सकता था, और कम से कम web browser जैसे apps उस पर भरोसा करते थे
      यह बहुत पुरानी बात भी नहीं है
      इसलिए मुझे समझ नहीं आया कि custom certificate install करने के लिए device rooting की ज़रूरत क्यों है—क्या यह किसी और use के लिए है

  • HTTP Toolkit Turkey के घटिया electric vehicle charging app से hidden API निकालने में बहुत काम आया
    SSL pinning और root detection को रोकने के लिए Frida भी साथ में इस्तेमाल किया
    फिर मुझे एहसास हुआ कि शायद वे API छिपाना इसलिए चाहते हैं क्योंकि वे API किसी राक्षसी चीज़ जैसे हैं /s