Certificate Pinning: यह क्या है, तंत्र और फिक्सेशन के तरीके

Certificate Pinning क्या है?

Certificate Pinning एक सुरक्षा तकनीक है जिसमें एप्लिकेशन एक विश्वसनीय प्रमाणपत्र का फिंगरप्रिंट संग्रहीत करता है और HTTPS कनेक्शन स्थापित करने के लिए इसे एकमात्र मानदंड के रूप में उपयोग करता है। मानक TLS मॉडल में, क्लाइंट जाँचता है कि सर्वर का प्रमाणपत्र किसी विश्वसनीय रूट CA द्वारा हस्ताक्षरित है — सिस्टम में पूर्व-स्थापित सैकड़ों प्रमाणपत्र प्राधिकरणों में से कोई भी। Certificate Pinning इस श्रृंखला को प्रत्यक्ष जाँच से बदल देता है: प्रमाणपत्र संग्रहीत नमूने से मेल खाना चाहिए या अपेक्षित सार्वजनिक कुंजी शामिल करनी चाहिए।

मानक मॉडल की समस्या CA समझौता घटनाओं के बाद स्पष्ट हुई — DigiNotar (2011), Comodo (2011), TrustCor (2022)। यदि कोई CA आपके डोमेन के लिए नकली प्रमाणपत्र जारी करता है, तो ब्राउज़र या एप्लिकेशन इसे वैध मानकर स्वीकार करता है। Certificate Pinning इस हमले को रोकता है: पूरी तरह से हस्ताक्षरित नकली प्रमाणपत्र भी अस्वीकार कर दिया जाएगा क्योंकि इसका फिंगरप्रिंट एप्लिकेशन में फिक्स किए गए फिंगरप्रिंट से मेल नहीं खाता।

pinning शब्द pin से आया है — «पिन» या «फिक्सेटर»: डेवलपर एक विश्वसनीय प्रमाणपत्र को फिक्स करता है, और उससे कोई भी विचलन कनेक्शन को अवरुद्ध करता है। Mitre CWE-295 के शोध के अनुसार, अनुचित प्रमाणपत्र सत्यापन मोबाइल एप्लिकेशन में शीर्ष 10 सबसे खतरनाक सुरक्षा त्रुटियों में से एक बना हुआ है, और Certificate Pinning इसे रोकने का एक सीधा तरीका है।

Certificate Pinning का इतिहास और विकास

मूल रूप से, Certificate Pinning का उपयोग ब्राउज़रों में HPKP (HTTP Public Key Pinning) तंत्र के माध्यम से किया जाता था, जो RFC 7469 में मानकीकृत है। डेवलपर अपेक्षित कुंजियों के हैश के साथ एक HTTP Public-Key-Pins हेडर भेजता था, और ब्राउज़र उन्हें निर्दिष्ट अवधि के लिए संग्रहीत करता था। हालाँकि, HPKP खतरनाक साबित हुआ: कॉन्फ़िगरेशन में एक त्रुटि किसी साइट को महीनों के लिए अवरुद्ध कर सकती थी। 2018 में, Chrome ने HPKP का समर्थन बंद कर दिया, और वर्तमान मानक क्लाइंट-साइड कार्यान्वयन बन गया — मोबाइल एप्लिकेशन या ब्राउज़र एक्सटेंशन के अंदर।

Certificate Pinning कैसे काम करता है?

Certificate Pinning प्रक्रिया में तीन प्रमुख चरण शामिल हैं: फिंगरप्रिंट गणना, कनेक्शन सत्यापन और त्रुटि प्रबंधन। तैयारी के दौरान, डेवलपर प्रोडक्शन सर्वर के प्रमाणपत्र या सार्वजनिक कुंजी का SHA-256 हैश प्राप्त करता है। GDPR और PCI DSS-अनुपालन एप्लिकेशन के लिए, श्रृंखला में मध्यवर्ती CAs के फिंगरप्रिंट को भी फिक्स करना आवश्यक है।

प्रत्येक HTTPS अनुरोध के साथ, एप्लिकेशन TLS प्रमाणीकरण कॉलबैक को इंटरसेप्ट करता है, सर्वर का प्रमाणपत्र निकालता है और उसके SHA-256 हैश की गणना करता है। इस हैश की तुलना संग्रहीत विश्वसनीय फिंगरप्रिंट सूची से की जाती है। यदि मिलान मिलता है — कनेक्शन जारी रहता है। यदि नहीं — एप्लिकेशन को कनेक्शन समाप्त करना चाहिए और हमलावर को कार्यान्वयन विवरण प्रकट किए बिना त्रुटि की रिपोर्ट करनी चाहिए।

fun validateCertificate(certificate: X509Certificate,
    expectedHash: String): Boolean {
    val digest = MessageDigest.getInstance("SHA-256")
    val hash = Base64.encodeToString(
        digest.digest(certificate.publicKey.getEncoded()),
        Base64.DEFAULT
    ).trim()
    return hash == expectedHash
}

फ़ंक्शन सर्वर से X509Certificate ऑब्जेक्ट और अपेक्षित हैश प्राप्त करता है। यह पहले प्रमाणपत्र की सार्वजनिक कुंजी निकालता है, SHA-256 हैश की गणना करता है और इसे Base64 में एन्कोड करता है। परिणाम की तुलना अपेक्षित फिंगरप्रिंट से की जाती है। प्रोडक्शन में, रोटेशन को समर्थन देने के लिए 2–3 फिंगरप्रिंट की सरणी के विरुद्ध सत्यापन जोड़ना उचित है।

Certificate Pinning बनाम Public Key Pinning

pinning लागू करते समय, यह चुनना होगा कि किस क्रिप्टोग्राफ़िक ऑब्जेक्ट को फिक्स करना है। Certificate Pinning स्वयं X.509 प्रमाणपत्र से बंधता है — इसकी सीरियल नंबर, वैधता अवधि और पूरी श्रृंखला। Public Key Pinning प्रमाणपत्र के अंदर केवल सार्वजनिक कुंजी को फिक्स करता है, अन्य फ़ील्ड को अनदेखा करता है। यह विकल्प परिचालन लागत को महत्वपूर्ण रूप से प्रभावित करता है।

Public Key Pinning अधिकांश परियोजनाओं के लिए पसंदीदा विकल्प है। प्रमाणपत्र पुनः जारी करने पर सर्वर की सार्वजनिक कुंजियाँ आमतौर पर अपरिवर्तित रहती हैं — कंपनी बस पुरानी कुंजी को नए प्रमाणपत्र से हस्ताक्षरित करती है। इसका मतलब है कि यदि कुंजी जोड़ी नहीं बदली है तो प्रमाणपत्र बदलने के बाद एप्लिकेशन को अद्यतन की आवश्यकता नहीं है। दूसरी ओर, Certificate Pinning उन परिदृश्यों के लिए अनुशंसित है जहाँ डेवलपर सर्वर और क्लाइंट कोड दोनों को पूरी तरह से नियंत्रित करता है, जैसे सख्त अद्यतन चक्र वाले एंटरप्राइज़ एप्लिकेशन में।

Trust On First Use (TOFU)

TOFU एक रणनीति है जिसमें Certificate Pinning पहले से कॉन्फ़िगर नहीं किया जाता है, बल्कि सर्वर से पहले कनेक्शन पर प्रमाणपत्र को याद रखता है। यह दृष्टिकोण उन एप्लिकेशन के लिए सुविधाजनक है जो पहले से नहीं जानते कि वे किस सर्वर से जुड़ेंगे। नकारात्मक पक्ष प्रारंभिक हमले के प्रति संवेदनशीलता है: यदि पहला कनेक्शन इंटरसेप्ट किया जाता है, तो नकली प्रमाणपत्र विश्वसनीय मानकर स्वीकार कर लिया जाएगा। TOFU का उपयोग SSH कनेक्शन और कुछ P2P प्रोटोकॉल में किया जाता है।

iOS और Android पर कार्यान्वयन

दोनों प्लेटफ़ॉर्म पर, Certificate Pinning को नेटवर्क स्टैक स्तर पर TLS कनेक्शन को इंटरसेप्ट करके कार्यान्वित किया जाता है। iOS पर, URLSession डेलीगेट या Alamofire ServerTrustManager का उपयोग किया जाता है। Android पर, पसंदीदा तरीका OkHttp CertificatePinner है, जो लोकप्रिय HTTP क्लाइंट में निर्मित है और प्रत्येक डोमेन के लिए कई फिंगरप्रिंट कॉन्फ़िगर करने का समर्थन करता है।

func validate(serverTrust: SecTrust,
    pinnedHash: String) -> Bool {
    guard let certificates = SecTrustCopyCertificateChain(serverTrust)
        as? [SecCertificate] else { return false }

    for certificate in certificates {
        let data = SecCertificateCopyData(certificate)
        var hash = Data(repeating: 0, count: Int(CC_SHA256_DIGEST_LENGTH))
        data.withUnsafeBytes {
            CC_SHA256($0.baseAddress,
                CC_LONG(data.count), &hash)
        }
        if hash.base64EncodedString() == pinnedHash {
            return true
        }
    }
    return false
}

Swift फ़ंक्शन में, serverTrust से प्रमाणपत्र श्रृंखला निकाली जाती है, प्रत्येक प्रमाणपत्र के लिए SHA-256 हैश की गणना की जाती है, और परिणाम की तुलना अपेक्षित से की जाती है। श्रृंखला में सभी प्रमाणपत्रों के माध्यम से पुनरावृति मध्यवर्ती CA स्तर पर pinning लागू करने की अनुमति देती है — यदि कोई मध्यवर्ती प्रमाणपत्र मेल खाता है, तो कनेक्शन स्वीकार किया जाता है। यह लीफ प्रमाणपत्र रोटेशन के दौरान लचीलापन प्रदान करता है।

Android के लिए कस्टम TrustManager

यदि एप्लिकेशन OkHttp का उपयोग नहीं करता है, तो Certificate Pinning को कस्टम X509TrustManager के माध्यम से कार्यान्वित किया जा सकता है। इस विधि में अधिक कोड की आवश्यकता होती है लेकिन सत्यापन प्रक्रिया पर पूर्ण नियंत्रण देता है। TrustManager checkServerTrusted विधि को ओवरराइड करता है, जहाँ डेवलपर मैन्युअल रूप से सर्वर प्रमाणपत्रों की जाँच करता है और उन पर भरोसा करने का निर्णय लेता है। इसकी अनुशंसा केवल विशिष्ट परिदृश्यों के लिए की जाती है जहाँ OkHttp लाइब्रेरी उपलब्ध नहीं है।

Certificate Pinning कार्यान्वयन में सामान्य गलतियाँ

सबसे आम गलती backup pins की अनुपस्थिति है। डेवलपर एक ही प्रमाणपत्र फिंगरप्रिंट शामिल करता है, और जब वह समाप्त हो जाता है, तो उपयोगकर्ता सामूहिक रूप से कनेक्टिविटी खो देते हैं। न्यूनतम स्वीकार्य कॉन्फ़िगरेशन दो फिंगरप्रिंट है: वर्तमान प्रमाणपत्र और एक बैकअप। आदर्श रूप से तीन: वर्तमान, एक बैकअप, और फ़ॉलबैक के रूप में रूट CA फिंगरप्रिंट।

दूसरी गलती कोड में pins को सादे पाठ में संग्रहीत करना है। APK या IPA तक पहुँच रखने वाला हमलावर आसानी से फिंगरप्रिंट निकाल सकता है और उन्हें बदल सकता है। हैश ऑब्फस्केशन की अनुशंसा की जाती है: स्ट्रिंग को भागों में विभाजित करें, एन्क्रिप्टेड संसाधनों में संग्रहीत करें, या रनटाइम पर गणना करें। Android के लिए, स्ट्रिंग कॉन्स्टेंट ऑब्फस्केशन के साथ ProGuard प्रभावी है।

तीसरी गलती डेवलपमेंट प्रमाणपत्र स्तर पर pinning करना है। डेवलपमेंट और प्रोडक्शन प्रमाणपत्र आमतौर पर अलग होते हैं, लेकिन डेवलपर अक्सर रिलीज़ बनाते समय pins बदलना भूल जाते हैं। परिणाम यह होता है कि प्रोडक्शन एप्लिकेशन सर्वर से कनेक्ट नहीं हो पाता। समाधान BuildConfig या फ्लेवर-विशिष्ट संसाधनों के माध्यम से debug और release के लिए अलग pin कॉन्फ़िगरेशन है।

• प्रमाणपत्र श्रृंखला को अनदेखा करना — मध्यवर्ती CAs पर विचार किए बिना केवल लीफ प्रमाणपत्र की जाँच करना, जो रोटेशन के दौरान कनेक्शन तोड़ता है
• हार्डकोडेड तिथियाँ — प्रमाणपत्र समाप्ति तिथियाँ हार्डकोडेड होती हैं जो अद्यतन के बाद नहीं बदलतीं
• कोई निगरानी नहीं — Certificate Pinning त्रुटियों पर अलर्ट की अनुपस्थिति, जिससे समस्याएँ केवल उपयोगकर्ताओं से पता चलती हैं
• बिना सत्यापन के TOFU — अतिरिक्त सत्यापन के बिना Trust On First Use का उपयोग, जिससे पहला MITM हमला नकली प्रमाणपत्र फिक्स कर सकता है