SSL Pinning: جوہر، طریقہ کار اور MITM حملوں سے تحفظ

SSL Pinning کیا ہے؟

SSL Pinning ایک حفاظتی طریقہ کار ہے جس میں موبائل یا ویب ایپلیکیشن ایک قابل اعتماد سرور سرٹیفکیٹ یا عوامی کلید کو یاد رکھتی ہے اور ان کنکشنز کو مسترد کرتی ہے جن کا سرٹیفکیٹ ذخیرہ شدہ سے مطابقت نہیں رکھتا۔ معیاری HTTPS اسکیم میں، کلائنٹ روٹ CA تک اعتماد کے سلسلے کے ذریعے سرٹیفکیٹ کی تصدیق کرتا ہے — کوئی بھی CA کسی بھی ڈومین کے لیے سرٹیفکیٹ پر دستخط کر سکتا ہے۔ SSL Pinning اس کمزوری کو ختم کرتا ہے: سینکڑوں CA پر اعتماد کرنے کے بجائے، ایپلیکیشن صرف ایک مخصوص سرٹیفکیٹ پر اعتماد کرتی ہے۔

معیاری تصدیق کا مسئلہ یہ ہے کہ سینکڑوں روٹ CA میں سے کوئی بھی آپ کے ڈومین کے لیے ایک درست سرٹیفکیٹ جاری کر سکتا ہے — حادثاتی طور پر یا جبر کے تحت۔ اپنے روٹ سرٹیفکیٹ کے ساتھ کارپوریٹ پراکسی تک رسائی حاصل کرنے والا حملہ آور براؤزر انتباہ کے بغیر MITM حملہ کر سکتا ہے۔ SSL Pinning اس کمزوری کو بند کرتا ہے: یہاں تک کہ اگر CA جعلی سرٹیفکیٹ جاری کرے، ایپلیکیشن اسے مسترد کر دے گی کیونکہ فنگر پرنٹ ریکارڈ شدہ سے مطابقت نہیں رکھتا۔

موبائل ایپلیکیشنز میں SSL Pinning خاص طور پر اہم ہے کیونکہ آلات اکثر غیر محفوظ نیٹ ورکس پر کام کرتے ہیں — عوامی Wi-Fi، ٹریفک معائنہ کے ساتھ کارپوریٹ پراکسی، متاثرہ رسائی پوائنٹس۔ Verizon Mobile Security Index (2025) کے مطابق، موبائل ایپلیکیشنز میں 60% سے زیادہ ڈیٹا کی خلاف ورزیاں ٹرانسپورٹ پرت پر ٹریفک کی روک تھام سے متعلق ہیں۔

موبائل ڈیولپمنٹ میں SSL Pinning کی ضرورت کیوں

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

SSL Pinning کیسے کام کرتا ہے؟

SSL Pinning کا عمل تین مراحل پر مشتمل ہے: فنگر پرنٹ حاصل کرنا، کنیکشن پر تصدیق، اور غلطی کا انتظام۔ ڈیولپمنٹ کے دوران، انجینئر سرور سرٹیفکیٹ کا SHA-256 فنگر پرنٹ حاصل کرتا ہے (openssl x509 -fingerprint -sha256) اور اسے ایپلیکیشن کوڈ یا کنفیگریشن فائل میں شامل کرتا ہے۔ ہر HTTPS درخواست پر، ایپلیکیشن موصولہ سرٹیفکیٹ کے فنگر پرنٹ کا حساب لگاتی ہے اور ذخیرہ شدہ سے موازنہ کرتی ہے — اگر اقدار مطابقت نہیں رکھتیں، تو کنیکشن ختم کر دیا جاتا ہے۔

پہلا مرحلہ — بلڈ وقت پر پِننگ: ڈیولپر پہلے سے سرور سرٹیفکیٹ جانتا ہے اور ان کے ہیش شامل کرتا ہے۔ دوسرا مرحلہ — پہلے کنیکشن پر پِننگ (پہلے استعمال پر اعتماد، TOFU): ایپلیکیشن پہلی درخواست پر سرٹیفکیٹ یاد رکھتی ہے اور بعد کی تمام درخواستوں کی تصدیق کے لیے اسے استعمال کرتی ہے۔ TOFU متحرک ماحول کے لیے آسان ہے لیکن پہلے حملے میں کمزور ہے — اگر پہلا کنیکشن پہلے ہی روک لیا گیا ہو، تو جعلی سرٹیفکیٹ قابل اعتماد کے طور پر قبول کر لیا جائے گا۔

ایک اہم تفصیل بیک اپ پِن (backup pins) ہیں۔ سرٹیفکیٹس کی میعاد ختم ہونے کی تاریخ ہوتی ہے، اور جب انہیں تبدیل کیا جاتا ہے، تو اپ ڈیٹ کے بغیر ایپلیکیشن سرور سے کنیکشن کھو دے گی۔ انجینئر 2–3 اضافی فنگر پرنٹس شامل کرتے ہیں — مثال کے طور پر، بیک اپ سرٹیفکیٹ کا فنگر پرنٹ اور روٹ CA کا فنگر پرنٹ۔ اگر مرکزی سرٹیفکیٹ تبدیل ہوتا ہے، تو ایپلیکیشن بیک اپ پِن کے خلاف جانچ کرتی ہے، اور کنیکشن کام کرتا رہتا ہے۔

# SHA-256 سرٹیفکیٹ فنگر پرنٹ حاصل کرنا
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | \
  openssl x509 -pubkey -noout | \
  openssl pkey -pubin -outform der | \
  openssl dgst -sha256 -binary | \
  base64

SSL Pinning کی اقسام

پِننگ کو نافذ کرنے کے دو اہم طریقے ہیں: پورے سرٹیفکیٹ سے بائنڈنگ (certificate pinning) اور عوامی کلید سے بائنڈنگ (public key pinning)۔ ہر طریقہ کی اپنی طاقت اور حدود ہیں جو سیکیورٹی اور دیکھ بھال کو متاثر کرتی ہیں۔

Certificate Pinning

سرٹیفکیٹ پِننگ سب سے سخت طریقہ ہے۔ ایپلیکیشن قابل اعتماد سرٹیفکیٹ یا اس کے SHA-256 فنگر پرنٹ کی ایک کاپی ذخیرہ کرتی ہے اور ہر HTTPS کنیکشن پر سرور سرٹیفکیٹ سے موازنہ کرتی ہے۔ یہ طریقہ زیادہ سے زیادہ سیکیورٹی فراہم کرتا ہے لیکن گردش کے دوران مسائل پیدا کرتا ہے — سرٹیفکیٹ عام طور پر 1–2 سال تک کارآمد رہتے ہیں، جس کے بعد جبری ایپلیکیشن اپ ڈیٹ کی ضرورت ہوتی ہے۔ کنٹرول شدہ اپ ڈیٹ سائیکل والے اہم نظاموں کے لیے تجویز کردہ۔

Public Key Pinning

عوامی کلید پِننگ ایک زیادہ لچکدار طریقہ ہے۔ پورے سرٹیفکیٹ کے بجائے، ایپلیکیشن صرف سرور کی RSA یا ECDSA عوامی کلید کو یاد رکھتی ہے۔ اگر کمپنی ایک ہی کلیدی جوڑی استعمال کرتی ہے، تو سرٹیفکیٹ دوبارہ جاری ہونے پر کلید بدلی ہوئی رہ سکتی ہے۔ اس سے ایپلیکیشن اپ ڈیٹ کی تعدد کم ہو جاتی ہے۔ تاہم، اگر کلید سے سمجھوتہ ہو جاتا ہے، تو تمام کلائنٹس پر جھڑپ تبدیل کی ضرورت ہوگی۔

iOS پر SSL Pinning

Apple پلیٹ فارم پر، SSL Pinning URLSession ڈیلیگیٹ کے ذریعے نافذ کیا جاتا ہے۔ ڈیولپر URLSessionDelegate پروٹوکول کو لاگو کرنے والی کلاس بناتا ہے اور didReceive challenge طریقہ کو اوور رائڈ کرتا ہے، جہاں وہ ذخیرہ شدہ فنگر پرنٹس کے خلاف دستی طور پر سرور سرٹیفکیٹ کی تصدیق کرتا ہے۔ ایک متبادل طریقہ ServerTrustManager کے ساتھ Alamofire استعمال کرنا ہے، جو کنفیگریشن کو آسان بناتا ہے۔

class SSLPinningDelegate: NSObject, URLSessionDelegate {
    let pinnedHash = "sha256/Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg="

    func urlSession(_ session: URLSession,
        didReceive challenge: URLAuthenticationChallenge,
        completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {

        guard let serverTrust = challenge.protectionSpace.serverTrust
            else { return completionHandler(.cancelAuthenticationChallenge, nil) }

        if validate(serverTrust, pinnedHash) {
            completionHandler(.useCredential, URLCredential(trust: serverTrust))
        } else {
            completionHandler(.cancelAuthenticationChallenge, nil)
        }
    }
}

مثال میں، ڈیلیگیٹ URLSession سے تصدیقی درخواست وصول کرتا ہے، challenge سے serverTrust نکالتا ہے، اور سرٹیفکیٹ کے SHA-256 فنگر پرنٹ کا ذخیرہ شدہ سے موازنہ کرتا ہے۔ اگر فنگر پرنٹ مطابقت رکھتا ہے — کنیکشن جاری رہتا ہے، ورنہ challenge مسترد کر دیا جاتا ہے۔ پروڈکشن کے لیے، متعدد بیک اپ پِن کی تصدیق اور نگرانی کے لیے خرابی نوشتہ شامل کرنا مناسب ہے۔

iOS پر Network Security Config

iOS 14 سے شروع کرتے ہوئے، Apple نے Info.plist کے ذریعے Certificate Pinning کے لیے بلٹ ان سپورٹ شامل کیا۔ ڈیولپر NSAppTransportSecurity کلید میں NSPinnedDomains ذیلی لغت کے ساتھ قابل اعتماد سرٹیفکیٹ متعین کرتا ہے۔ اس طریقہ میں کوڈ لکھنے کی ضرورت نہیں ہے لیکن یہ کم لچکدار ہے — پِن کو متحرک طور پر تبدیل کرنا یا تصدیقی خرابیوں کو نوشتہ کرنا ناممکن ہے۔

Android پر SSL Pinning

Android پر SSL Pinning کو نافذ کرنے کے تین اہم طریقے ہیں: OkHttp لائبریری کے CertificatePinner کے ذریعے، XML میں Network Security Config کے ذریعے، اور HttpsURLConnection میں حسب ضرورت تصدیق کے ذریعے۔ OkHttp سب سے مشہور اور تجویز کردہ طریقہ ہے، جو Retrofit اور دیگر HTTP کلائنٹس میں استعمال ہوتا ہے۔

val certificatePinner = CertificatePinner.Builder()
    .add("api.example.com",
        "sha256/Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg=")
    .add("api.example.com",
        "sha256/FiPq6ePEsVRqZ1yW0F6wLgWi24BE7j5qLk0iL=")  // بیک اپ پِن
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

OkHttp کنفیگریشن میں، ڈیولپر ڈومین اور ایک یا زیادہ SHA-256 فنگر پرنٹس متعین کرتا ہے۔ پہلے فنگر پرنٹ پر، OkHttp سرور سرٹیفکیٹ کا متعین کردہ پِن سے موازنہ کرتا ہے۔ اگر کوئی مطابقت نہیں ہے، تو کلائنٹ SSLPeerUnverifiedException پھینکتا ہے۔ بیک اپ پِن لازمی ہے — اس کے بغیر، سرٹیفکیٹ تبدیل ہونے پر API درخواستیں فوری طور پر ناکام ہونے لگیں گی۔

Android پر Network Security Configuration

Android API 24 سے شروع کرتے ہوئے XML کنفیگریشن کے ذریعے اعلانیہ Certificate Pinning کی حمایت کرتا ہے۔ فائل res/xml/network_security_config.xml میں ڈومین اور ان کے فنگر پرنٹس کی فہرست ہوتی ہے۔ یہ طریقہ جامد کنفیگریشنز کے لیے آسان ہے لیکن اسامانیتاوں کی نوشتہ کے ساتھ TOFU یا حسب ضرورت تصدیقی منطق کو لاگو کرنے کی اجازت نہیں دیتا۔

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">
                Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg=</pin>
            <pin digest="SHA-256">
                FiPq6ePEsVRqZ1yW0F6wLgWi24BE7j5qLk0iL=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

SSL Pinning کے فوائد اور نقصانات

SSL Pinning موبائل ایپلیکیشن کی سیکیورٹی میں نمایاں اضافہ کرتا ہے لیکن آپریشنل پیچیدگیاں پیدا کرتا ہے۔ اہم فائدہ روٹ CA سے سمجھوتہ ہونے پر بھی MITM حملوں سے تحفظ ہے۔ ایپلیکیشن صرف ان سرٹیفکیٹس پر اعتماد کرتی ہے جو ڈیولپر نے واضح طور پر متعین کیے ہیں، نہ کہ عوامی سرٹیفکیشن اتھارٹیز کے پورے بنیادی ڈھانچے پر۔ یہ خاص طور پر مالی ایپلیکیشنز، میسنجر اور حساس ڈیٹا والی ایپلیکیشنز کے لیے اہم ہے۔

اہم نقصان سرٹیفکیٹ گردش کی پیچیدگی ہے۔ اگر سرٹیفکیٹ ختم ہو جاتا ہے یا منسوخ کر دیا جاتا ہے، تو ایپلیکیشن اپ ڈیٹ کے بغیر صارفین کنیکشن کھو دیتے ہیں۔ یہ بیک اپ پِن اور بتدریج اپ ڈیٹ میکانزم کے ذریعے حل کیا جاتا ہے: نئی ایپلیکیشن پرانے اور نئے دونوں سرٹیفکیٹس کو جانتی ہے، اور صارفین کے مکمل اپ ڈیٹ کے بعد، پرانا پِن کوڈ سے ہٹا دیا جاتا ہے۔ کم از کم 2 بیک اپ پِن شامل کرنے کی سفارش کی جاتی ہے — ایک موجودہ سرٹیفکیٹ کے لیے، ایک مستقبل کے لیے۔

ایک اور سمجھوتہ پِننگ کو غیر فعال کیے بغیر ٹریفک ڈیبگنگ (Charles Proxy, Burp Suite) کے لیے عوامی پراکسی استعمال کرنے میں ناکامی ہے۔ یہ ڈیولپمنٹ کے دوران نیٹ ورک کی درخواستوں کی ڈیبگنگ کو پیچیدہ بناتا ہے۔ حل مشروط تالیف ہے: ڈیبگ بلڈ میں پِننگ غیر فعال ہے، ریلیز میں فعال ہے۔ OWASP سوئچ کرنے کے لیے BuildConfig.DEBUG پرچم استعمال کرنے کی سفارش کرتا ہے۔