SSL/TLS — یہ کیا ہے، پروٹوکول اور خفیہ کاری کے کام کرنے کا اصول

SSL/TLS کیا ہے؟

SSL (Secure Sockets Layer) ایک پروٹوکول ہے جسے Netscape نے 1995 میں ویب ٹریفک کو محفوظ بنانے کے لیے تیار کیا تھا۔ پہلا ورژن SSL 1.0 کبھی عوامی طور پر جاری نہیں کیا گیا؛ SSL 2.0 (1995) اور SSL 3.0 (1996) 2000 کی دہائی کے اوائل تک استعمال ہوئے، لیکن ان میں سنگین کمزوریاں تھیں۔ SSL کی جگہ TLS (Transport Layer Security) نے لے لی — IETF کے ذریعے معیاری بنایا گیا ایک بہتر ورژن۔ TLS 1.0 (1999) SSL 3.0 پر مبنی تھا، جبکہ بعد کے ورژن TLS 1.1 (2006)، TLS 1.2 (2008) اور TLS 1.3 (2018) آہستہ آہستہ اصل فن تعمیر سے دور ہوتے گئے، نئے خفیہ کاری الگورتھم شامل کرتے اور کمزوریوں کو دور کرتے گئے۔ آج SSL کو متروک سمجھا جاتا ہے، اور تمام جدید نظام TLS استعمال کرتے ہیں، اگرچہ عادتاً دونوں پروٹوکول کو اکثر SSL/TLS کے طور پر ایک ساتھ ذکر کیا جاتا ہے۔

پروٹوکول کی تاریخ

SSL/TLS کی تاریخ ابتدائی ویب میں محفوظ ڈیٹا کی ترسیل کی ضرورت سے شروع ہوئی۔ 1994 میں، Netscape نے اپنے Navigator براؤزر کے لیے SSL 1.0 تیار کیا، لیکن سنگین سیکیورٹی مسائل کی وجہ سے پروٹوکول کبھی شائع نہیں ہوا۔ SSL 2.0 1995 میں جاری ہوا اور عملی طور پر استعمال ہوا، تاہم اس میں متعدد کمزوریاں تھیں: Man-in-the-Middle حملوں سے تحفظ کی کمی، کمزور خفیہ کاری الگورتھم، اور کاٹنے (truncation) کے حملوں کے لیے حساسیت۔ SSL 3.0 (1996) نے زیادہ تر مسائل حل کر دیے، لیکن 2014 تک POODLE کمزوری دریافت ہوئی، جس کے بعد IETF نے باضابطہ طور پر تمام SSL ورژن کو متروک قرار دے دیا۔ TLS 1.0–1.3 نے بتدریج خفیہ نگاری کی مضبوطی، کارکردگی اور رازداری کو بہتر کیا، جہاں TLS 1.3 نے مصافحہ کو دو چکروں سے کم کرکے ایک چکر کر دیا — جو غیر مستحکم کنکشن والی موبائل ایپلیکیشنز کے لیے انتہائی اہم ہے۔

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

مصافحہ (Handshake) کلائنٹ اور سرور کے درمیان محفوظ کنکشن قائم کرنے کا عمل ہے۔ یہ کئی متواتر مراحل پر مشتمل ہے جن کے دوران فریقین پروٹوکول ورژن پر متفق ہوتے ہیں، خفیہ کاری الگورتھم منتخب کرتے ہیں، کلیدوں کا تبادلہ کرتے ہیں اور ایک دوسرے کی تصدیق کرتے ہیں۔ TLS 1.3 میں، مصافحہ میں صرف ایک نیٹ ورک چکر (1-RTT) لگتا ہے، جبکہ TLS 1.2 میں دو (2-RTT) درکار تھے۔

پہلا قدم کلائنٹ کا ClientHello بھیجنا ہے — ایک پیغام جس میں معاون TLS ورژن، سائفر سوٹ اور ایک بے ترتیب نمبر کی فہرست ہوتی ہے۔ سرور منتخب کردہ ورژن اور سائفر، اپنے X.509 سرٹیفکیٹ اور ڈیجیٹل دستخط کے ساتھ ServerHello کے ساتھ جواب دیتا ہے۔ کلائنٹ سرٹیفکیٹ اتھارٹی (CA) چین کے ذریعے سرٹیفکیٹ کی تصدیق کرتا ہے، ایک سیشن کلید تیار کرتا ہے اور اسے سرٹیفکیٹ سے سرور کی عوامی کلید کے ساتھ خفیہ کرکے بھیجتا ہے۔ سرور کی تصدیق کے بعد، محفوظ ڈیٹا کی ترسیل شروع ہوتی ہے۔ پورا مصافحہ جدید آلات پر 1–3 ملی سیکنڈ لیتا ہے، جو اسے صارف کے لیے ناقابل تصور بناتا ہے۔

X.509 سرٹیفکیٹ اور اعتماد کا سلسلہ

TLS تصدیق کی بنیاد عوامی کلید کا بنیادی ڈھانچہ (PKI) ہے جو X.509 فارمیٹ کے سرٹیفکیٹس پر بنایا گیا ہے۔ ہر سرٹیفکیٹ میں شامل ہے: ایک ڈومین نام (Common Name یا Subject Alternative Name)، سرور کی عوامی کلید، جاری کنندہ کا نام (سرٹیفکیٹ اتھارٹی)، میعاد ختم ہونے کی تاریخ اور CA کا ڈیجیٹل دستخط۔ کلائنٹ اعتماد کے سلسلے کے ذریعے سرور کے سرٹیفکیٹ کی تصدیق کرتا ہے: سرور سرٹیفکیٹ سے روٹ CA تک، جس کا سرٹیفکیٹ آپریٹنگ سسٹم میں شامل ہوتا ہے۔ Android آلات پر، روٹ سرٹیفکیٹ سسٹم کی اسٹور میں محفوظ ہوتے ہیں، جو Google Play Services کے ذریعے اپ ڈیٹ ہوتے ہیں؛ iOS میں — iOS اپ ڈیٹس کے ذریعے۔ اگر سلسلے کی کوئی کڑی ٹوٹ جائے (میعاد ختم شدہ سرٹیفکیٹ، ڈومین کا عدم مماثلت، نامعلوم CA)، کلائنٹ کنکشن ختم کر دیتا ہے۔ خود دستخط شدہ سرٹیفکیٹس (ترقی میں استعمال) کے لیے، واضح اعتماد درکار ہے — Android میں Network Security Config کے ذریعے، iOS میں Info.plist میں NSExceptionDomains کے ذریعے۔ سرٹیفکیٹ چین کی تصدیق کے عمل میں CRL (سرٹیفکیٹ منسوخی کی فہرست) یا OCSP (آن لائن سرٹیفکیٹ اسٹیٹس پروٹوکول) کے ذریعے منسوخی کی حیثیت کی جانچ بھی شامل ہے، اگرچہ موبائل آلات پر کنکشن تیز کرنے کے لیے OCSP درخواستیں اکثر چھوڑ دی جاتی ہیں — یہ سیکیورٹی اور کارکردگی کے درمیان ایک سمجھوتہ ہے جسے معماروں کو مدنظر رکھنا چاہیے۔

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()