सर्टिफ़िकेट पिनिंग
जो ऐप अपना सर्टिफ़िकेट पिन करता है वह Busymate DevTools से डिक्रिप्ट नहीं होगा — न iOS पर, न Android पर, न प्रॉक्सी से। यहाँ ठीक-ठीक बताया गया है कि हर कैप्चर रास्ता क्या देख सकता है और क्या नहीं, पिन किए हुए होस्ट को कैसे पहचानें, और क्या फिर भी काम का रहता है।
HTTPS डिक्रिप्ट करने वाला हर कैप्चर टूल एक ही तरह काम करता है: वह क्लाइंट को खुद का साइन किया सर्टिफ़िकेट देता है, और क्लाइंट उसे इसलिए मानता है क्योंकि वह साइन करने वाली अथॉरिटी पर भरोसा करता है। सर्टिफ़िकेट पिनिंग का मतलब है कि ऐप कहता है कि वह सिर्फ़ एक ख़ास सर्टिफ़िकेट या कुंजी पर भरोसा करेगा, किसी और पर नहीं। जब पिन किया हुआ ऐप बदले हुए सर्टिफ़िकेट से मिलता है, तो वह बस कनेक्शन ठुकरा देता है। यह ऐप की खासियत है, टूल का स्विच नहीं, और Busymate का कोई भी कैप्चर रास्ता इसे पार नहीं करता।
जो टूल यह बात चुपचाप छिपा ले, वह आपका पूरा रिसर्च सेशन ऐसे लक्ष्य पर बर्बाद करा देता है जो कभी डिक्रिप्ट होने वाला ही नहीं था। इसलिए यह गाइड नक्शा है, तरकीब नहीं: पिन किए होस्ट के सामने iOS की ऑन-डिवाइस कैप्चर, Android ऐप, डेस्कटॉप प्रॉक्सी, फ़ार्म का रूट किया फ़ोन और Chrome कनेक्टर क्या-क्या देते हैं, फ़ीड उसे कैसे लेबल करता है, और काम के कौन-से हिस्से फिर भी हो जाते हैं।
आपको क्या
यह गाइड मानकर चलती है कि कम से कम एक कैप्चर रास्ते से ट्रैफ़िक पहले से आपके डैशबोर्ड तक पहुँच रहा है।
पहले से पेयर और कैप्चर कर रहा फ़ोन या क्लाइंट — iPhone या Android गाइड आपको वहाँ तक ले जाती है।
जिस ऐप की जाँच कर रहे हैं उसके होस्टनेम, SSL प्रॉक्सी सूची में जोड़े हुए, ताकि डिक्रिप्शन की कम से कम कोशिश तो हो।
डैशबोर्ड फ़ीड खुला हुआ, और उसका इंस्पेक्शन फ़िल्टर हाथ के पास।
ऐप की जाँच की अनुमति: ये तकनीकें उन ऐप्स और साइटों के ट्रैफ़िक के लिए हैं जो आपकी हैं या जिन्हें डिबग करने की आपको इजाज़त है।
इसे क्रम
रास्तों को क्रम से देखें — हर एक यह और सीमित करता है कि पिन किया होस्ट अब भी आपको क्या बता सकता है।
- 01
जानें कि आपका कैप्चर रास्ता किस ट्रस्ट स्टोर पर टिका है
iOS पर डिक्रिप्शन इस पर निर्भर है कि Busymate प्रोफ़ाइल इंस्टॉल हो और सेटिंग्स में उसे पूरा भरोसा मिला हो — उसके बाद फ़ोन का हर ऐप उस सर्टिफ़िकेट पर भरोसा करता है जो ऐप पेश करता है, सिवाय उनके जो पिन करते हैं। Android पर दो स्टोर हैं: यूज़र स्टोर, जिसे Android 7.0 से सिर्फ़ वही ऐप मानते हैं जो साफ़ तौर पर ऑप्ट-इन करें, और सिस्टम स्टोर, जिसे हर ऐप मानता है पर जिसमें सिर्फ़ रूट किया डिवाइस लिख सकता है। डेस्कटॉप प्रॉक्सी उस भरोसे का इस्तेमाल करता है जो क्लाइंट मशीन या ब्राउज़र उसकी बनाई अथॉरिटी पर रखता है।
पिनिंग इन तीनों से ऊपर बैठी है। पिन करने वाला ऐप बदले हुए सर्टिफ़िकेट को ठुकरा देता है, चाहे वह किसी भी स्टोर से आया हो, इसलिए सर्टिफ़िकेट को मज़बूत स्टोर में ले जाना पिन किए होस्ट के खिलाफ़ कभी काम नहीं आता। यह सिर्फ़ उन ऐप्स के खिलाफ़ काम आता है जो यूज़र स्टोर को ठुकरा रहे थे।
- 02
फ़ीड में पिन किए होस्ट को पहचानें
जिस होस्ट को आपने डिक्रिप्शन के लिए सूची में नहीं डाला, वह बंद ताले के साथ सिर्फ़ होस्टनेम और रिक्वेस्ट की गिनती दिखाता है — यह डिज़ाइन है, पिनिंग नहीं। पिन किया होस्ट अलग दिखता है: वह आपकी सूची में है, डिक्रिप्शन की कोशिश हुई, और कनेक्शन नाकाम हुआ या ऐप ने फिर कोशिश की और हार मान ली। डैशबोर्ड फ़ीड के इंस्पेक्शन फ़िल्टर में तीन विकल्प हैं — सिर्फ़ डिक्रिप्टेड, सिर्फ़ एन्क्रिप्टेड, और सिर्फ़ SSL पिन्ड — और आख़िरी विकल्प ठीक इन्हीं पंक्तियों को अलग करता है।
दूसरा संकेत व्यवहार है: होस्ट डिक्रिप्ट होते ही ऐप उस होस्ट के लिए काम करना बंद कर देता है, और होस्ट को सूची से हटाते ही फिर काम करने लगता है। अगर दोनों सही हैं, तो आपने पिन किया हुआ कनेक्शन ढूँढ लिया।
- 03
iPhone पर ऑन-डिवाइस कैप्चर: मेटाडेटा, बॉडी कभी नहीं
iOS ऐप पूरे सिस्टम का ट्रैफ़िक Wi-Fi और सेल्युलर पर कैप्चर करता है और सूचीबद्ध होस्ट डिक्रिप्ट करता है। पिन किए ऐप के सामने भी यह हर कनेक्शन दर्ज करता है — होस्ट, समय, रिक्वेस्ट की संख्या और आकार, लागू कनेक्शन मोड — पर हेडर या बॉडी नहीं दे सकता, और कोई टॉगल इसे नहीं बदलता। MITM All Hosts चालू करने से हर बिना-पिन वाला होस्ट डिक्रिप्ट होता है; पिन किए होस्ट के लिए यह उसे तोड़ने के अलावा कुछ नहीं करता।
व्यावहारिक कदम यह है कि पिन किए होस्ट को सूची से हटा दें ताकि ऐप चलता रहे, ऐप के बाकी होस्ट सूची में रखें, और देखें कि बिना-पिन वाले एंडपॉइंट क्या बताते हैं। कई ऐप सिर्फ़ अपना ऑथेंटिकेशन या पेमेंट होस्ट पिन करते हैं और बाकी खुला छोड़ देते हैं।
- 04
Android: बिना रूट, रूट के साथ, और पिनिंग कहाँ है
बिना रूट वाले Android फ़ोन पर ऐप का बनाया सर्टिफ़िकेट यूज़र स्टोर में रहता है, इसलिए सिर्फ़ आपके अपने डिबग बिल्ड और ऑप्ट-इन किए क्लाइंट डिक्रिप्ट होते हैं; बाकी हर ऐप मेटाडेटा के रूप में दर्ज होता है। रूट किए डिवाइस पर सर्टिफ़िकेट सिस्टम स्टोर में डाला जा सकता है, और HTTPS पूरे सिस्टम में डिक्रिप्ट होने लायक हो जाता है — हर ऐप की अपनी पिनिंग को छोड़कर। फ़ोन फ़ार्म अपने Android डिवाइस ठीक इसी वजह से उस रूट वाले स्तर पर चलाता है।
तो रूट अपारदर्शी ऐप्स की एक श्रेणी को पढ़ने लायक बना देता है — वे जो सिर्फ़ यूज़र स्टोर को नज़रअंदाज़ कर रहे थे — और पिन वाली श्रेणी को छुए बिना छोड़ देता है। Busymate कभी बिना रूट वाले डिवाइस पर सिस्टम-व्यापी डिक्रिप्शन का दावा नहीं करता, और कभी यह दावा नहीं करता कि रूट किए डिवाइस पर पिनिंग हार गई।
- 05
प्रॉक्सी: वही सीमा, साथ में वे होस्ट जिन्हें वह जानबूझकर ठुकराता है
डेस्कटॉप प्रॉक्सी का पिनिंग से वही रिश्ता है जो फ़ोन ऐप्स का: पिन किया क्लाइंट उसका बनाया सर्टिफ़िकेट ठुकराता है और कनेक्शन नाकाम होता है। उसके पास उन होस्ट की एक छोटी सूची भी है जिन्हें वह कभी इंटरसेप्ट नहीं करता, चाहे आपकी SSL प्रॉक्सी सेटिंग्स कुछ भी कहें — Apple की अपनी PKI और रिवोकेशन एंडपॉइंट, Apple की चेन के सर्टिफ़िकेट-स्टेटस रिस्पॉन्डर, और खुद Busymate का बैकएंड — क्योंकि उन्हें इंटरसेप्ट करने से डिवाइस या डैशबोर्ड का अपना लाइव कनेक्शन टूट जाएगा। ये कच्ची टनल के रूप में गुज़रते हैं, और यह जानबूझकर है, ग़लत कॉन्फ़िगरेशन नहीं।
वे होस्ट जिन्हें प्रॉक्सी डिज़ाइन के तहत बिना छुए जाने देता है text# Passed through as raw tunnels by the proxy, regardless of your SSL-proxy list: pkis.apple.com ocsp*.apple.com crl*.apple.com valid.apple.com ppq.apple.com # the DigiCert OCSP / CRL responders Apple's chain uses *.busymate.net # the dashboard's own backend + Realtime connection - 06
Chrome कनेक्टर: पिनिंग लागू ही नहीं होती
एक कैप्चर रास्ता ऐसा है जहाँ पिनिंग बेमानी है। कमांड-लाइन कनेक्टर एक Chrome इंस्टेंस लॉन्च करता है और उसका ट्रैफ़िक DevTools Protocol से TLS के ब्राउज़र वाली तरफ़ पढ़ता है। Chrome और सर्वर के बीच का एन्क्रिप्टेड कनेक्शन कभी छुआ नहीं जाता — न ठुकराने के लिए कोई बदला सर्टिफ़िकेट, न इंस्टॉल करने को कुछ, न पिनिंग के पकड़ने को कुछ। जिन प्रोवाइडर के पिन किए सर्टिफ़िकेट प्रॉक्सी नहीं खोल सकता, उनके लॉगिन फ़्लो शुरू से अंत तक दर्ज होते हैं, रीडायरेक्ट और टोकन समेत।
इसकी कीमत है दायरा: यह उसे कवर करता है जो उस Chrome के अंदर चलता है, नेटिव ऐप को नहीं। अगर आपके मतलब के फ़्लो का वेब संस्करण है, तो यही रास्ता उसे पूरा देखता है।
- 07
पिन किया होस्ट जो अब भी देता है, उसका इस्तेमाल करें
मेटाडेटा कुछ नहीं, ऐसा नहीं है। आप अब भी देखते हैं कि ऐप पिन किए होस्ट से कब बात करता है, कितनी बार, आदान-प्रदान कितने बड़े हैं और कितना समय लेते हैं, और इसे आसपास की डिक्रिप्ट की हुई कॉल से जोड़ सकते हैं। ब्लॉक नियम एन्क्रिप्टेड होस्ट पर अब भी होस्ट-स्तर पर मेल खाते हैं — पाथ दिखता नहीं, पर आप ऐप को ऐसे व्यवहार करा सकते हैं मानो वह एंडपॉइंट पहुँच से बाहर हो, जो अक्सर ठीक वही फ़ेल्योर मोड है जिसे आप जाँचना चाहते थे। पॉज़ होस्ट को प्रॉक्सी पूरी तरह बायपास करने देता है ताकि ऐप चलता रहे और आप बाकी सब जाँचें।
और आपकी हर कार्रवाई ऑडिट ट्रेल में है, इसलिए रिसर्च सेशन इस बात का रिकॉर्ड छोड़ता है कि क्या डिक्रिप्ट हुआ, क्या ब्लॉक हुआ और क्या छोड़ दिया गया।
क्या गड़बड़
सबसे ज़्यादा समय वे ग़लतियाँ खाती हैं जो टूल के बग जैसी दिखती हैं पर होती नहीं।
जैसे ही मैंने ऐप का होस्ट जोड़ा, ऐप टूट गया
यही पिनिंग है। होस्ट को SSL प्रॉक्सी सूची से हटाएँ — iOS पर उसके बाद VPN रीस्टार्ट करें ताकि टनल बदलाव उठा ले — और ऐप ठीक हो जाता है। उसके बाकी होस्ट सूची में रखें।
MITM All Hosts से ऐप नहीं खुला
यह कभी खुलने वाला था ही नहीं। वह स्विच यह बढ़ाता है कि कौन-से बिना-पिन वाले होस्ट डिक्रिप्ट हों; ऐप के पिन किए होस्ट पर उसका कोई असर नहीं, और वह फ़ोन के बाकी हर पिन किए कनेक्शन को भी फ़ेल कर देता है। उसे वापस बंद करें।
Android फ़ोन को रूट करने से भी मदद नहीं मिली
रूट सर्टिफ़िकेट को सिस्टम स्टोर में ले जाता है, जिससे वे ऐप मान जाते हैं जो यूज़र स्टोर को नज़रअंदाज़ कर रहे थे। जो ऐप सर्टिफ़िकेट की तुलना अपने पिन से करता है, उस पर इसका असर नहीं।
कोई Apple सिस्टम होस्ट प्रॉक्सी पर कभी डिक्रिप्ट नहीं होता
वह प्रॉक्सी की कभी-इंटरसेप्ट-नहीं सूची में है, क्योंकि उसे डिक्रिप्ट करने से डिवाइस टूट जाएगा। ठीक करने को कुछ नहीं; फ़िल्टर उसे डिज़ाइन के तहत एन्क्रिप्टेड दिखाता है।
लोग जो
क्या Busymate पिनिंग बायपास देता है?
नहीं। कोई भी कैप्चर रास्ता लक्ष्य ऐप में बदलाव नहीं करता, कोड नहीं डालता, न उसकी भरोसे की लॉजिक बदलता है। पिन किए नेटिव ऐप के लिए ईमानदार जवाब है मेटाडेटा, और वह सब जो उसके बिना-पिन वाले होस्ट बताते हैं।
पिनिंग और उस होस्ट में कैसे फ़र्क करूँ जिसे मैं बस सूची में डालना भूल गया?
सूची से बाहर होस्ट बंद ताला दिखाता है और ऐप चलता रहता है। पिन किया होस्ट सूची में है, डिक्रिप्शन की कोशिश हुई, फ़ीड का SSL पिन्ड फ़िल्टर उसे अलग करता है, और जब तक आप उसे सूची से नहीं हटाते ऐप फ़ेल होता रहता है।
पिन किए प्रोवाइडर के ऑथेंटिकेशन फ़्लो के लिए कौन-सा रास्ता चुनूँ?
अगर प्रोवाइडर का वेब साइन-इन है, तो उसे Chrome कनेक्टर से चलाएँ — TLS ब्राउज़र के अंदर खत्म होता है और पूरी रीडायरेक्ट चेन दर्ज होती है। नेटिव ऐप के लिए कोई डिक्रिप्टेड रास्ता नहीं है; मेटाडेटा और आसपास की बिना-पिन वाली कॉल कैप्चर करें।
शुरू करने से पहले
डिक्रिप्शन को उन्हीं होस्ट तक सीमित रखें जिन्हें आप जाँच रहे हैं, फ़ीड को बताने दें कि कौन-से पिन करते हैं, और सेशन उस पर लगाएँ जो सचमुच पढ़ा जा सकता है।