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 का उपयोग केवल आइडेम्पोटेंट अनुरोधों (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 के सभी अनुरोधों के लिए इसका उपयोग करें।