Certificate Pinning एक सुरक्षा तकनीक है जिसमें मोबाइल एप्लिकेशन जाँचता है कि सर्वर का सर्टिफिकेट पूर्व-ज्ञात नमूने से मेल खाता है, न कि केवल CA श्रृंखला के किसी भी सर्टिफिकेट पर भरोसा करता है। सामान्य TLS जाँच के विपरीत, जो सैकड़ों प्रमाणपत्र प्राधिकारियों पर निर्भर करती है, pinning विश्वास को एक विशिष्ट सर्टिफिकेट या उसकी सार्वजनिक कुंजी तक सीमित कर देता है। OWASP मोबाइल सुरक्षा परीक्षण गाइड (2024) के अनुसार, Certificate Pinning लागू करने से सर्टिफिकेट प्रतिस्थापन से संबंधित 100% Man-in-the-Middle हमले के परिदृश्य अवरुद्ध हो जाते हैं। OWASP MSTG, 2024
मुख्य बातें
Certificate Pinning एक सुरक्षा तंत्र है जिसमें एप्लिकेशन सर्वर के सर्टिफिकेट का एक नमूना संग्रहीत (या “पिन”) करता है और प्रत्येक कनेक्शन पर प्राप्त सर्टिफिकेट की इस नमूने से तुलना करता है। यदि सर्टिफिकेट मेल नहीं खाता — तो कनेक्शन समाप्त कर दिया जाता है, भले ही वह किसी विश्वसनीय प्रमाणपत्र प्राधिकारी द्वारा आधिकारिक रूप से हस्ताक्षरित हो। यह उन हमलों से बचाता है जिनमें हमलावर समझौता किए गए CA के माध्यम से नकली सर्टिफिकेट प्राप्त करता है (जैसा कि 2011 में DigiNotar या 2011 में Comodo के साथ हुआ था)।
Pinning प्रक्रिया तीन चरणों से बनी है: विश्वसनीय उदाहरण से सर्टिफिकेट या सार्वजनिक कुंजी का फिंगरप्रिंट निकालना; इस फिंगरप्रिंट को एप्लिकेशन कोड या संसाधनों में संग्रहीत करना; TLS हैंडशेक के दौरान तुलना करना। डेवलपर पूरे सर्टिफिकेट के SHA-256 फिंगरप्रिंट या केवल सार्वजनिक कुंजी (Public Key Pinning) को पिन कर सकता है। दूसरा दृष्टिकोण बेहतर है: सर्टिफिकेट नवीनीकृत होने पर, सार्वजनिक कुंजी अक्सर वही रहती है, और ऐप सर्वर से कनेक्शन नहीं खोता। OWASP अनुशंसाओं के अनुसार, न्यूनतम पिन संख्या 2 है: एक वर्तमान और एक बैकअप कुंजी रोटेशन के लिए। OkHttp और TrustKit जैसी आधुनिक लाइब्रेरी बिना डेवलपर के अतिरिक्त प्रयास के प्रत्येक TLS कनेक्शन के दौरान निर्दिष्ट पिनों की जाँच प्रक्रिया को स्वचालित करती हैं। यह समझना महत्वपूर्ण है कि pinning मानक TLS जाँच को प्रतिस्थापित नहीं करता, बल्कि इसे पूरक करता है: पहले सर्टिफिकेट श्रृंखला सत्यापन के साथ एक सामान्य हैंडशेक किया जाता है, फिर एक अतिरिक्त pinning जाँच। यह दो-स्तरीय सुरक्षा CA समझौता से संबंधित कमजोरियों को समाप्त करती है, जिसमें गलत सर्टिफिकेट जारी करने और प्रमाणपत्र प्राधिकारी बुनियादी ढांचे पर हमले शामिल हैं।
Certificate Pinning को लागू करने के कई दृष्टिकोण हैं, प्रत्येक की अपनी भंडारण और सत्यापन विशेषताएँ हैं। विधि का चुनाव एप्लिकेशन आर्किटेक्चर, सर्टिफिकेट अद्यतन आवृत्ति और लचीलापन आवश्यकताओं पर निर्भर करता है।
| Pinning प्रकार | क्या संग्रहीत होता है | लचीलापन | उपयोग उदाहरण |
|---|---|---|---|
| Certificate Pinning | पूर्ण X.509 सर्टिफिकेट | निम्न | 1–2 वर्षों के लिए निश्चित सर्टिफिकेट |
| Public Key Pinning | सार्वजनिक कुंजी (SPKI) | मध्यम | OWASP अनुशंसित दृष्टिकोण |
| Hash Pinning | SHA-256 फिंगरप्रिंट | मध्यम | OkHttp में लोकप्रिय (certificatePinner) |
| CA Pinning | मध्यवर्ती CA | उच्च | उद्यम अनुप्रयोग |
सबसे संतुलित विधि Public Key Pinning है, जो OWASP और Google द्वारा अनुशंसित है। एक विशिष्ट सर्टिफिकेट (जो हर 1–2 वर्षों में बदलता है) के बजाय, एप्लिकेशन SubjectPublicKeyInfo फिंगरप्रिंट — सार्वजनिक कुंजी का एक अमूर्त — संग्रहीत करता है। यदि सर्टिफिकेट उसी कुंजी के साथ नवीनीकृत होता है (कुंजी पुन: उपयोग), तो पिन वैध रहता है। यदि कुंजी बदलती है — तो डेवलपर पहले से एप्लिकेशन अपडेट में एक बैकअप पिन जोड़ता है। मोबाइल परियोजनाओं में न्यूनतम/अधिकतम पिन रणनीति का उपयोग किया जाता है: बैकअप सहित न्यूनतम 2 पिन, और अधिकतम 4 विस्तार और बढ़े हुए सत्यापन समय को रोकने के लिए।
विशिष्ट pinning प्रकार का चुनाव एप्लिकेशन आर्किटेक्चर और आवश्यकताओं पर निर्भर करता है। एकल डोमेन के माध्यम से REST API के साथ काम करने वाले सार्वजनिक मोबाइल एप्लिकेशन के लिए, OkHttp या TrustKit के माध्यम से दो पिनों के साथ Public Key Pinning इष्टतम है। अपने स्वयं के प्रमाणपत्र प्राधिकारी वाले उद्यम अनुप्रयोगों के लिए, CA Pinning उपयुक्त है — इसे क्लाइंट सर्टिफिकेट बदलने पर अपडेट की आवश्यकता नहीं होती, क्योंकि विश्वास CA से बंधा होता है, अंतिम सर्टिफिकेट से नहीं। IoT और एम्बेडेड सिस्टम के लिए, पूर्ण सर्टिफिकेट पिनिंग के साथ Certificate Pinning अनुशंसित है: उपकरण शायद ही कभी अपडेट होते हैं, इसलिए संपूर्ण विश्वास श्रृंखला पर नियंत्रण महत्वपूर्ण है। पिन समाप्ति तिथियों की निगरानी अनिवार्य अभ्यास है: वर्तमान सर्टिफिकेट अमान्य होने से पहले नए पिनों के साथ एप्लिकेशन अपडेट जारी करने के लिए सर्टिफिकेट समाप्ति से 30, 14 और 7 दिन पहले अलर्ट सेट करें। नए पिनों के साथ अपडेट जारी करने को स्वचालित करने के लिए, Firebase Remote Config या एक कस्टम कॉन्फ़िगरेशन API का उपयोग करने की अनुशंसा की जाती है जो ऐप स्टोर में नया संस्करण प्रकाशित किए बिना पिन सूची को गतिशील रूप से अपडेट करने की अनुमति देता है।
Certificate Pinning मोबाइल एप्लिकेशन सुरक्षा में काफी वृद्धि करता है लेकिन विकास टीम पर परिचालन बोझ डालता है। गलत कार्यान्वयन के कारण सुरक्षा लाभों और कनेक्शन अवरोधन के जोखिमों के बीच संतुलन बनाना महत्वपूर्ण है।
मुख्य लाभ Man-in-the-Middle हमलों से सुरक्षा है, जिसमें CA समझौता के मामले शामिल हैं। Pinning हमलावर द्वारा जारी नकली सर्टिफिकेट को बेकार बना देता है: भले ही किसी CA ने जालसाजी पर हस्ताक्षर किया हो, एप्लिकेशन इसे अस्वीकार कर देगा। एक अतिरिक्त लाभ कॉर्पोरेट प्रॉक्सी सर्वरों से सुरक्षा है जो ट्रैफ़िक निरीक्षण के लिए सर्टिफिकेट बदलते हैं। Google Security Blog (2023) के अनुसार, pinning वाले एप्लिकेशन में केवल मानक TLS जाँच का उपयोग करने वाले एप्लिकेशन की तुलना में ट्रैफ़िक अवरोधन के माध्यम से समझौता होने की 86% कम संभावना होती है।
Pinning का मुख्य नुकसान स्व-अवरोधन का जोखिम है: यदि एप्लिकेशन अपडेट जारी होने से पहले सर्वर सर्टिफिकेट बदलता है (नवीनीकरण, प्रदाता परिवर्तन, कुंजी रोटेशन), तो उपयोगकर्ता सर्वर तक पहुँच खो देते हैं। अतिरिक्त कमियाँ: डिबगिंग जटिलता (प्रत्येक कॉन्फ़िगरेशन परिवर्तन के लिए पिन अपडेट की आवश्यकता), TrustKit का उपयोग करते समय APK आकार में 5–15 KB की वृद्धि, और नए रिलीज़ के बिना जल्दी से परिवर्तनों को वापस लेने में असमर्थता। जोखिमों को कम करने के लिए, बैकअप पिन, हर 2–3 महीने में स्वचालित रोटेशन, और एक अनुग्रह अवधि का उपयोग किया जाता है, जिसके दौरान एप्लिकेशन पुराने और नए दोनों सर्टिफिकेट को स्वीकार करता है। यह भी ध्यान रखना महत्वपूर्ण है कि pinning सक्षम के साथ विकास के दौरान, नेटवर्क अनुरोधों को डीबग करने के लिए प्रॉक्सी टूल (Burp Suite, Charles) का उपयोग नहीं किया जा सकता — डेव बिल्ड के लिए, BuildConfig.DEBUG फ़्लैग के माध्यम से pinning अक्षम किया जाना चाहिए, और QA परीक्षण सुरक्षा सक्षम के साथ रिलीज़ हस्ताक्षर पर किया जाना चाहिए। कुछ टीमें विकास के दौरान भी सुरक्षा बनाए रखने के लिए डेव वातावरण के लिए एक अलग pinning सर्टिफिकेट के साथ स्टेजिंग डोमेन का उपयोग करती हैं।
आइए OkHttp — नेटवर्क अनुरोधों के लिए मानक लाइब्रेरी — का उपयोग करके Android पर Certificate Pinning लागू करने का एक उदाहरण देखें। OkHttp एक अंतर्निहित CertificatePinner प्रदान करता है जो सार्वजनिक कुंजियों के SHA-256 हैश स्वीकार करता है।
val certificatePinner = CertificatePinner.Builder()
.add(
"api.example.com",
"sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
)
.add(
"api.example.com",
"sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB="
)
.build()
val client = OkHttpClient.Builder()
.certificatePinner(certificatePinner)
.build()
उपरोक्त कोड में, हम डोमेन api.example.com के लिए दो पिन जोड़ते हैं: प्राथमिक (वर्तमान सर्टिफिकेट) और एक बैकअप पिन (रोटेशन के लिए)। OkHttp स्वचालित रूप से जाँचता है कि सर्वर का सर्टिफिकेट निर्दिष्ट SHA-256 फिंगरप्रिंट में से एक से मेल खाता है। सर्टिफिकेट का SHA-256 फिंगरप्रिंट प्राप्त करने के लिए, कमांड का उपयोग करें: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. फिंगरप्रिंट को कोड में सादे पाठ के रूप में नहीं, बल्कि एन्क्रिप्टेड या अस्पष्ट संग्रहीत करना महत्वपूर्ण है: MobSF स्थैतिक विश्लेषण DEX फ़ाइलों में आसानी से कच्चे SHA-256 स्ट्रिंग ढूँढ लेता है। पिनों को res/raw संसाधनों में, AES के माध्यम से एन्क्रिप्ट करके संग्रहीत करने और मूल कोड (NDK/JNI) के माध्यम से एप्लिकेशन स्टार्टअप पर उन्हें डिक्रिप्ट करने की अनुशंसा की जाती है।
iOS पर, Certificate Pinning के लिए प्राथमिक उपकरण ओपन-सोर्स TrustKit लाइब्रेरी है। OkHttp के विपरीत, TrustKit को Info.plist के माध्यम से घोषणात्मक रूप से कॉन्फ़िगर किया जाता है, जो एप्लिकेशन को पुनर्संकलित किए बिना पिन बदलने की अनुमति देता है। कॉन्फ़िगरेशन में डोमेन के साथ एक शब्दकोश और SHA-256 सार्वजनिक कुंजी फिंगरप्रिंट की एक सरणी शामिल है। TrustKit स्वचालित रूप से NSURLSession अनुरोधों को इंटरसेप्ट करता है और डेटा ट्रांसमिशन शुरू होने से पहले सर्टिफिकेट सत्यापित करता है। TrustKit की एक महत्वपूर्ण विशेषता पिन सत्यापन रिपोर्ट के लिए समर्थन है: लाइब्रेरी पिन बेमेल होने पर एक निर्दिष्ट एंडपॉइंट पर रिपोर्ट भेज सकती है, जिससे सर्टिफिकेट विसंगतियों पर त्वरित प्रतिक्रिया संभव होती है। Apple iOS 14 से Info.plist में एक मूल NSPinnedDomains तंत्र भी प्रदान करता है, लेकिन TrustKit अधिक लचीले कॉन्फ़िगरेशन, रिपोर्ट समर्थन और OS अपडेट के बिना पिनों को हॉट-स्वैप करने की क्षमता के कारण पसंदीदा विकल्प बना हुआ है। यह ध्यान रखना महत्वपूर्ण है कि TrustKit didReceiveChallenge डेलिगेट के माध्यम से URLSession के साथ एकीकृत होता है, सफल पिन सत्यापन पर .performDefaultHandling और बेमेल पर .cancelAuthenticationChallenge लौटाता है। पिन सत्यापन रिपोर्ट की निगरानी के लिए, एक अलग एंडपॉइंट स्थापित करने की अनुशंसा की जाती है जो त्रुटि आवृत्ति का विश्लेषण करता है: यदि रिपोर्टों की संख्या तेजी से बढ़ती है — तो यह MitM हमले या आसन्न सर्टिफिकेट समाप्ति का संकेत हो सकता है जिसके लिए तत्काल पिन अपडेट की आवश्यकता है।
अक्सर पूछे जाने वाले प्रश्न
Certificate Pinning आपके फोन में किसी मित्र के फिंगरप्रिंट को सहेजने जैसा है: आपको याद रहता है कि “सही” सर्वर सर्टिफिकेट कैसा दिखता है, और आप किसी और पर भरोसा नहीं करते, भले ही कोई “आधिकारिक” प्राधिकरण से पहचान दिखाए।
सामान्य HTTPS सैकड़ों प्राधिकारियों में से किसी भी CA द्वारा हस्ताक्षरित किसी भी सर्टिफिकेट पर भरोसा करता है। Certificate Pinning शीर्ष पर एक जाँच जोड़ता है: सर्टिफिकेट केवल मान्य नहीं होना चाहिए, बल्कि विशेष रूप से वह होना चाहिए जिसे आपने एप्लिकेशन कोड में हार्डकोड किया है।
2–3 पिन संग्रहीत करने की अनुशंसा की जाती है: वर्तमान और नए सर्टिफिकेट के लिए एक बैकअप पिन। सर्टिफिकेट बदलने से 1–2 महीने पहले, भविष्य के सर्टिफिकेट का पिन जोड़कर एप्लिकेशन का एक नया संस्करण जारी करें। बदलाव के बाद, पुराने पिन को अगले रिलीज़ से हटा दिया जाता है।
हाँ, किया जा सकता है। Pinning किसी भी सर्टिफिकेट के साथ काम करता है, जिसमें Let’s Encrypt शामिल है। यह याद रखना महत्वपूर्ण है कि मुफ्त सर्टिफिकेट की वैधता अवधि कम (3 महीने) होती है, इसलिए बैकअप पिन रणनीति और स्वचालित रोटेशन अनिवार्य हो जाते हैं।
Pinning के परीक्षण के लिए Burp Suite या mitmproxy का उपयोग करें। यदि pinning के साथ एप्लिकेशन सही ढंग से कॉन्फ़िगर किया गया है, तो प्रॉक्सी टूल ट्रैफ़िक को इंटरसेप्ट नहीं कर पाएगा — हैंडशेक चरण में कनेक्शन समाप्त हो जाएगा। एकीकरण परीक्षणों के लिए, OkHttp के MockWebServer का उपयोग करें।
सारांश
हम एक मोबाइल एप्लिकेशन टर्नकी विकसित करेंगे
IT Sectr 2017 से स्टार्टअप और व्यवसायों के लिए iOS और Android एप्लिकेशन बनाता है। हम आपको सलाह देंगे और सर्वोत्तम समाधान प्रस्तावित करेंगे।
यह भी पढ़ें