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 সালে প্রকাশিত হয়েছিল এবং ব্যবহারিক ব্যবহারে এসেছিল, তবে এতে numerous দুর্বলতা ছিল: Man-in-the-Middle আক্রমণের বিরুদ্ধে সুরক্ষার অভাব, দুর্বল এনক্রিপশন অ্যালগরিদম এবং ট্রাঙ্কেশন আক্রমণের প্রতি সংবেদনশীলতা। 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 প্রমাণীকরণের ভিত্তি হল X.509 ফরম্যাটের সার্টিফিকেটের উপর নির্মিত পাবলিক কী ইনফ্রাস্ট্রাকচার (PKI)। প্রতিটি সার্টিফিকেটে থাকে: একটি ডোমেন নাম (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()