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 ডেটা রিপ্লে আক্রমণ থেকে সুরক্ষিত নয় — এটি আটকানো এবং পুনরায় পাঠানো যেতে পারে। শুধুমাত্র আইডেম্পোটেন্ট অনুরোধের (GET, PUT) জন্য 0-RTT ব্যবহার করুন যার কোনো পার্শ্বপ্রতিক্রিয়া নেই।

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-তে সমস্ত অনুরোধের জন্য এটি ব্যবহার করুন।