SSL/TLS: کلیدی تصورات اور ڈیولپمنٹ میں پروٹوکول

SSL/TLS کیا ہے؟

SSL (سیکیور ساکٹس لیئر) اور TLS (ٹرانسپورٹ لیئر سیکیورٹی) خفیہ‌نگاری کے پروٹوکول ہیں جو نیٹ ورک پر ڈیٹا کی محفوظ ترسیل کو یقینی بناتے ہیں۔ SSL، جو 1990 کی دہائی میں Netscape نے تیار کیا تھا، POODLE اور BEAST کمزوریوں کی وجہ سے ورژن 3.0 کے بعد فرسودہ سمجھا جاتا ہے۔ TLS، اس کا جانشین، ورژن 1.0، 1.1، 1.2 اور 1.3 سے گزرا ہے — صرف TLS 1.2 اور TLS 1.3 موجودہ سمجھے جاتے ہیں۔ تمام جدید موبائل پلیٹ فارم نیٹ ورک کنکشن کے لیے TLS کی ضرورت ہے، اور App Store اور Google Play جائزہ کے دوران اس کی جانچ کرتے ہیں۔

موبائل ایپلیکیشنز کے لیے TLS کیوں

TLS کے بغیر، ایپلیکیشن اور سرور کے درمیان ٹریفک صاف متن میں منتقل ہوتی ہے — اسی Wi-Fi نیٹ ورک پر کوئی بھی شخص Wireshark یا tcpdump کا استعمال کرکے لاگ ان، پاس ورڈ، ٹوکن اور صارفین کے ذاتی ڈیٹا کو روک سکتا ہے۔ TLS تمام منتقل شدہ ڈیٹا کو خفیہ کرتا ہے (ٹرانسپورٹ لیئر خفیہ‌نگاری) اور X.509 سرٹیفکیٹس کی زنجیر کے ذریعے سرور کی صداقت کی تصدیق کرتا ہے۔ IETF (2018) کے مطابق، TLS 1.3 صرف جدید AEAD سائفر (AES-GCM، ChaCha20-Poly1305) استعمال کرتا ہے، RC4 اور 3DES جیسے فرسودہ الگورتھم کو خارج کرتے ہوئے۔

HTTPS اور TLS

HTTPS (HTTP سیکیور) TLS کے اوپر HTTP ہے۔ جب کوئی موبائل ایپلیکیشن https:// کے ذریعے درخواست کرتی ہے، تو یہ پہلے سرور کے ساتھ TLS کنکشن قائم کرتی ہے، پھر خفیہ کردہ چینل کے ذریعے HTTP ہیڈر اور درخواست کا باڈی منتقل کرتی ہے۔ HTTPS کے بغیر، کوئی بھی سنجیدہ API کام نہیں کرنا چاہیے — یہ بنیادی تحفظ کی صفائی ہے۔ OWASP (2026) کے مطابق، غیر محفوظ کنکشن موبائل ایپلیکیشنز کی سرفہرست 3 کمزوریوں میں شامل ہیں۔

TLS مصافحہ کیسے کام کرتا ہے

TLS مصافحہ کلائنٹ اور سرور کے درمیان محفوظ کنکشن قائم کرنے کا عمل ہے۔ فریقین پروٹوکول ورژن پر گفت و شنید کرتے ہیں، سائفر سوٹ منتخب کرتے ہیں، غیر متناسب خفیہ‌نگاری کے ذریعے چابیاں کا تبادلہ کرتے ہیں، اور سرٹیفکیٹس کی تصدیق کرتے ہیں۔ TLS 1.2 میں، مصافحہ کے لیے 2 راؤنڈ ٹرپ ٹائم (2 RTT) درکار ہے: کلائنٹ → سرور ClientHello کے ساتھ، سرور → کلائنٹ ServerHello اور Certificate کے ساتھ، پھر حتمی Finished پیغامات۔ TLS 1.3 اس عمل کو 1 RTT تک کم کرتا ہے۔

TLS 1.2 مصافحہ کے تفصیلی مراحل

پہلا مرحلہ: ClientHello — کلائنٹ معاون TLS ورژن، سائفر سوٹ کی فہرست اور ایک بے ترتیب نمبر بھیجتا ہے۔ سرور ServerHello کے ساتھ جواب دیتا ہے، ایک ورژن اور سائفر سوٹ منتخب کرتا ہے، اپنا X.509 سرٹیفکیٹ (Certificate) اور ServerHelloDone پیغام بھیجتا ہے۔ کلائنٹ قابل اعتماد سرٹیفکیٹ اتھارٹیز (CA) کی زنجیر کے ذریعے سرٹیفکیٹ کی تصدیق کرتا ہے، ایک پری ماسٹر سیکرٹ (pre-master secret) تیار کرتا ہے، اسے سرٹیفکیٹ سے عوامی چابی سے خفیہ کرتا ہے اور ClientKeyExchange میں سرور کو بھیجتا ہے۔ اس کے بعد، دونوں فریق سیشن چابیاں تیار کرتے ہیں اور ChangeCipherSpec اور Finished پیغامات کا تبادلہ کرتے ہیں۔ اس مقام سے، تمام ڈیٹا ہم آہنگی سے خفیہ کیا جاتا ہے۔

import Security

let url = URL(string: "https://api.example.com")!
let session = URLSession(configuration: .default,
                           delegate: self,
                           delegateQueue: nil)

func urlSession(
    _ session: URLSession,
    didReceive challenge: URLAuthenticationChallenge,
    completionHandler: @escaping (URLSession.AuthChallengeDisposition,
                                    URLCredential?) -> Void
) {
    let trust = challenge.protectionSpace.serverTrust
    guard let trust else {
        completionHandler(.cancelAuthenticationChallenge, nil)
        return
    }
    completionHandler(.useCredential, URLCredential(trust: trust))
}

URLSessionDelegate کے ذریعے iOS پر URLAuthenticationChallenge کو ہینڈل کرنے کی مثال۔ یہ طریقہ ہر TLS مصافحہ کے دوران کال کیا جاتا ہے، جس سے ایپلیکیشن سرور سرٹیفکیٹ کی حسب ضرورت تصدیق کر سکتی ہے۔ پروڈکشن استعمال کے لیے، SecTrustEvaluateWithError کے ذریعے سرٹیفکیٹ کی تصدیق شامل کریں اور پہلے سے محفوظ کردہ فنگر پرنٹ سے موازنہ کریں — اس کے بعد ہی useCredential کال کریں۔

TLS 1.2 بمقابلہ TLS 1.3

TLS 1.3 (RFC 8446, 2018) 10 سالوں میں پہلی بڑی پروٹوکول اپ ڈیٹ ہے۔ اہم بہتری: مصافحہ 1 RTT تک کم (دوبارہ کنکشن کے لیے 0 RTT)، فرسودہ سائفر سوٹ ہٹا دیے گئے (RSA چابی کا تبادلہ، CBC موڈ)، لازمی پرفیکٹ فارورڈ سیکریسی (PFS)، اور signed transcript کے ذریعے ڈاؤن گریڈ حملوں سے تحفظ۔ Qualys SSL Labs (2026) کے مطابق، TLS 1.3 PFS کی بدولت طویل مدتی سرور چابی سے سمجھوتہ ہونے پر بھی تحفظ فراہم کرتا ہے۔

0-RTT (صفر راؤنڈ ٹرپ ٹائم) TLS 1.3 کی ایک خصوصیت ہے جو کلائنٹ کو PSK (پری شیئرڈ کی) کے ذریعے دوبارہ کنکشن کے دوران ClientHello کے ساتھ فوری طور پر ڈیٹا بھیجنے کی اجازت دیتی ہے۔ یہ موبائل ایپلیکیشنز میں بعد کی اسکرینوں کی لوڈنگ کو تیز کرتا ہے، خاص طور پر ایک ہی سرور پر بار بار درخواستوں کے ساتھ۔ تاہم، 0-RTT ڈیٹا ری پلے حملوں سے محفوظ نہیں ہے — اسے روکا اور دوبارہ بھیجا جا سکتا ہے۔ 0-RTT صرف idempotent درخواستوں (GET, PUT) کے لیے استعمال کریں جن کے کوئی ضمنی اثرات نہ ہوں۔

iOS پر TLS: App Transport Security

App Transport Security (ATS) Apple کا طریقہ کار ہے جو TLS 1.2 یا اس سے اوپر کے ساتھ HTTPS کنکشن کی ضرورت ہے، iOS 9 سے ڈیفالٹ طور پر فعال ہے۔ ATS تمام HTTP کنکشنز اور TLS 1.2 سے نیچے کے HTTPS کو بلاک کرتا ہے۔ ڈیولپر مخصوص ڈومینز کے لیے NSAppTransportSecurity کے ذریعے Info.plist میں مستثنیات ترتیب دے سکتا ہے، لیکن Apple مستثنیات کو کم سے کم رکھنے اور ہر جگہ HTTPS استعمال کرنے کی سفارش کرتا ہے۔ ATS کی ضروریات کی خلاف ورزی App Store کے جائزے میں ایپلیکیشن کو مسترد کرنے کا سبب ہے۔

<!-- Info.plist — App Transport Security -->
<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <false/>
    <key>NSExceptionDomains</key>
    <dict>
        <key>cdn.example.com</key>
        <dict>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <false/>
            <key>NSExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
        </dict>
    </dict>
    <key>NSAllowsLocalNetworking</key>
    <true/>
</dict>

Info.plist میں ATS ترتیب۔ NSAllowsArbitraryLoads false پر سیٹ ہے — تمام کنکشنز کو HTTPS استعمال کرنا چاہیے۔ ڈومین cdn.example.com کے لیے، کم از کم TLS ورژن 1.2 مقرر کیا گیا ہے، NSAllowsLocalNetworking=true مقامی نیٹ ورک کے لیے HTTP کی اجازت دیتا ہے (ڈیولپمنٹ سرورز کے لیے مفید)۔ Apple NSExceptionDomains کے بغیر NSAllowsArbitraryLoads کو فعال نہ کرنے کی سختی سے سفارش کرتا ہے — یہ ایک عمومی قاعدہ نہیں بلکہ ایک استثناء ہونا چاہیے۔

Android پر TLS: Network Security Config

Network Security Config Java/Kotlin کوڈ کو تبدیل کیے بغیر HTTPS اور TLS کو ترتیب دینے کا Android طریقہ کار ہے۔ ترتیب network_security_config.xml فائل میں مخصوص کی جاتی ہے اور android:networkSecurityConfig وصف کے ذریعے AndroidManifest میں منسلک کی جاتی ہے۔ قابل اعتماد سرٹیفکیٹس (صارف اور سسٹم CA)، Certificate Pinning، صاف متن HTTP کو غیر فعال کرنا، ڈیبگ اوور رائڈز اور ٹریفک ری ڈائریکشن کی ترتیب کو سپورٹ کرتا ہے۔

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-01-01">
            <pin digest="SHA-256">
                47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
            </pin>
        </pin-set>
    </domain-config>
</network-security-config>

Android کے لیے Network Security Config۔ Base-config صاف متن ٹریفک کو بلاک کرتا ہے اور صرف سسٹم CA سرٹیفکیٹس پر بھروسہ کرتا ہے (کوئی صارف سرٹیفکیٹ نہیں — صارفین کی طرف سے MitM سرٹیفکیٹ انسٹالیشن سے تحفظ)۔ api.example.com کے لیے Domain-config میں SHA-256 سرٹیفکیٹ فنگر پرنٹ کے ساتھ pin-set ہے۔ اگر سرور سرٹیفکیٹ مخصوص میعاد ختم ہونے کی تاریخ سے پہلے تبدیل ہوتا ہے، تو کنکشن مسترد کر دیا جائے گا — یہ Certificate Pinning کی ایک سخت شکل ہے۔

Certificate Pinning اور تحفظ

Certificate Pinning ایپلیکیشن کوڈ میں سرور کے سرٹیفکیٹ یا عوامی چابی کو فکس کرنے کی ایک تکنیک ہے۔ ہر TLS مصافحہ کے دوران، کلائنٹ سرور سرٹیفکیٹ کا پہلے سے محفوظ کردہ فنگر پرنٹ (SHA-256 ہیش) سے موازنہ کرتا ہے۔ یہاں تک کہ اگر حملہ آور قابل اعتماد CA سرٹیفکیٹ حاصل کر لے یا سرٹیفکیٹ اتھارٹی سے سمجھوتہ کر لے، وہ MitM حملہ نہیں کر سکتا — ایپلیکیشن CA چین نہیں، بلکہ مخصوص فنگر پرنٹ چیک کرتی ہے۔ یہ خاص طور پر مالیاتی ایپلیکیشنز اور حساس ڈیٹا سے نمٹنے والی ایپس کے لیے اہم ہے۔

Pinning کے خطرات اور متبادل

Certificate Pinning میں احتیاط کی ضرورت ہے: جب سرور سرٹیفکیٹ تبدیل ہوتا ہے، ایپلیکیشن کے تمام پرانے ورژن کنیکٹ ہونا بند کر دیں گے۔ ایک سے زیادہ بیک اپ فنگر پرنٹس (بنیادی + بیک اپ) ذخیرہ کرنے، pin-set کی میعاد ختم ہونے کی تاریخ مخصوص کرنے اور معیاری CA تصدیق کے ذریعے فال بیک میکانزم لاگو کرنے کی سفارش کی جاتی ہے۔ ایک متبادل ٹرسٹ آن فرسٹ یوز (TOFU) ہے، جہاں ایپلیکیشن پہلے کنکشن پر سرٹیفکیٹ یاد رکھتی ہے اور تبدیل ہونے پر صارف کو خبردار کرتی ہے۔ OWASP (2026) کے مطابق، Certificate Pinning کی عدم موجودگی موبائل ایپلیکیشنز کی سرفہرست 3 کمزوریوں (M3: غیر محفوظ مواصلات) میں شامل ہے۔

Alamofire میں Pinning کا نفاذ

Alamofire 5+ میں، Certificate Pinning ServerTrustManager کے ساتھ PinnedCertificatesTrustEvaluator (مکمل سرٹیفکیٹ چیک) یا PublicKeysTrustEvaluator (صرف عوامی چابی) کے ذریعے ترتیب دیا جاتا ہے۔ عوامی چابی ترجیحی ہے — یہ اسی CA کے ساتھ سرٹیفکیٹ کی تجدید پر تبدیل نہیں ہوتی۔ [host: evaluator] لغت کے ساتھ ServerTrustManager بنائیں، اسے Session میں پاس کریں، اور تمام API درخواستوں کے لیے اس کا استعمال کریں۔