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 کی تحقیق کے مطابق، نامناسب سرٹیفکیٹ تصدیق موبائل ایپلی کیشنز میں سب سے خطرناک سیکیورٹی غلطیوں میں سے ایک ہے، اور 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 کے نفاذ میں عام غلطیاں

سب سے عام غلطی بیک اپ پنز کی عدم موجودگی ہے۔ ڈیولپر ایک ہی سرٹیفکیٹ فنگر پرنٹ شامل کرتا ہے، اور جب اس کی میعاد ختم ہوتی ہے تو صارفین اجتماعی طور پر کنکشن کھو دیتے ہیں۔ کم از کم قابل قبول ترتیب دو فنگر پرنٹس ہیں: موجودہ سرٹیفکیٹ اور ایک بیک اپ۔ مثالی طور پر تین: موجودہ، ایک بیک اپ، اور فال بیک کے طور پر روٹ CA فنگر پرنٹ۔

دوسری غلطی کوڈ میں پنوں کو سادہ متن میں ذخیرہ کرنا ہے۔ APK یا IPA تک رسائی رکھنے والا حملہ آور آسانی سے فنگر پرنٹس نکال سکتا ہے اور انہیں تبدیل کر سکتا ہے۔ ہیش مبہم کرنے کی سفارش کی جاتی ہے: سٹرنگ کو حصوں میں تقسیم کریں، انکرپٹڈ وسائل میں ذخیرہ کریں یا رن ٹائم پر حساب لگائیں۔ Android کے لیے، سٹرنگ کانسٹنٹ مبہم کرنے کے ساتھ ProGuard مؤثر ہے۔

تیسری غلطی ڈیولپمنٹ سرٹیفکیٹ کی سطح پر pinning کرنا ہے۔ ڈیولپمنٹ اور پروڈکشن سرٹیفکیٹ عام طور پر مختلف ہوتے ہیں، لیکن ڈیولپر اکثر ریلیز بناتے وقت پن تبدیل کرنا بھول جاتے ہیں۔ نتیجہ یہ ہوتا ہے کہ پروڈکشن ایپلی کیشن سرور سے کنیکٹ نہیں ہو سکتی۔ حل BuildConfig یا فلیور کے مخصوص وسائل کے ذریعے ڈیبگ اور ریلیز کے لیے علیحدہ پن کنفیگریشنز ہیں۔

• سرٹیفکیٹ چین کو نظر انداز کرنا — درمیانی CAs پر غور کیے بغیر صرف لیف سرٹیفکیٹ چیک کرنا، جو گردش کے دوران کنکشن توڑ دیتا ہے
• ہارڈ کوڈڈ تاریخیں — سرٹیفکیٹ میعاد ختم ہونے کی تاریخیں ہارڈ کوڈڈ ہوتی ہیں جو اپ ڈیٹس کے بعد تبدیل نہیں ہوتیں
• کوئی نگرانی نہیں — Certificate Pinning کی غلطیوں پر الرٹ کی عدم موجودگی، جس کی وجہ سے مسائل صرف صارفین سے دریافت ہوتے ہیں
• تصدیق کے بغیر TOFU — اضافی تصدیق کے بغیر Trust On First Use کا استعمال، جس سے پہلا MITM حملہ جعلی سرٹیفکیٹ فکس کر سکتا ہے