নেটওয়ার্কে এনক্রিপশন — TLS/SSL রিভিউ

Encryption in networking — TLS/SSL review

৮ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এক নজরে · TL;DR

TLS (Transport Layer Security) হলো SSL-এর আধুনিক উত্তরসূরি — SSL এখন deprecated/অনিরাপদ, বাস্তব ডিপ্লয়মেন্টে সবসময় TLS ব্যবহৃত হয়, যদিও কথ্যভাবে এখনও "SSL" নামটি চলে।
TLS অ্যাপ্লিকেশন প্রোটোকলের ঠিক নিচে বসে সেটিকে স্বচ্ছভাবে মুড়ে দেয় — HTTPS মানে HTTP + TLS, HTTP নিজে কোনো পরিবর্তন ছাড়াই আগের মতোই কাজ করে।
TLS হ্যান্ডশেক asymmetric ক্রিপ্টো দিয়ে একটি shared symmetric session key negotiate করে, তারপর দ্রুত সেই symmetric key দিয়ে সব অ্যাপ্লিকেশন ডেটা এনক্রিপ্ট হয় — একটি hybrid পদ্ধতি।
L47-এর IPsec-এর সাথে মূল পার্থক্য — TLS ট্রান্সপোর্ট স্তরের উপরে বসে নির্দিষ্ট অ্যাপ্লিকেশন কানেকশন সুরক্ষা দেয় (প্রতি-অ্যাপ্লিকেশন ইন্টিগ্রেশন লাগে), IPsec নেটওয়ার্ক স্তরে সব IP ট্রাফিক স্বচ্ছভাবে সুরক্ষা দেয়।

এই পাঠে যা শিখবেন

TLS কী এবং কেন SSL এখন আর ব্যবহার করা উচিত নয়
TLS কীভাবে অ্যাপ্লিকেশন প্রোটোকলকে স্বচ্ছভাবে মুড়ে দেয় — L01-এর লেয়ারিং নীতির একটি বাস্তব উদাহরণ
TLS হ্যান্ডশেকের হাই-লেভেল ধারণা — asymmetric + symmetric ক্রিপ্টোর হাইব্রিড ব্যবহার
TLS ও IPsec-এর স্তর ও ট্রান্সপারেন্সি অনুযায়ী পার্থক্য — Python দিয়ে একটি তুলনামূলক টেবিল

১ · TLS কী, এবং SSL কেন deprecated

TLSTransport Layer SecuritySSL-এর আধুনিক, নিরাপদ উত্তরসূরি — অ্যাপ্লিকেশন-লেয়ার প্রোটোকলের কানেকশনকে এনক্রিপ্ট ও প্রমাণীকরণ করে। হলো SSLSecure Sockets LayerTLS-এর পুরনো পূর্বসূরি — এতে পরিচিত নিরাপত্তা-দুর্বলতা থাকায় এখন deprecated, বাস্তব ব্যবহারে TLS দিয়ে সম্পূর্ণ প্রতিস্থাপিত।-এর আধুনিক উত্তরসূরি। SSL-এর পুরনো ভার্সনগুলোতে পরিচিত নিরাপত্তা-দুর্বলতা আছে বলে এগুলো এখন deprecated ও অনিরাপদ — বাস্তব কোনো আধুনিক সিস্টেম আর SSL ব্যবহার করা উচিত নয়। তবে দৈনন্দিন কথাবার্তায় ও কিছু পুরনো ডকুমেন্টেশনে "SSL সার্টিফিকেট" বা "SSL কানেকশন" নামটি এখনও প্রচলিত আছে — বাস্তবে সেখানে আসলে TLS-ই চলছে।

২ · TLS কীভাবে অ্যাপ্লিকেশন প্রোটোকলকে স্বচ্ছভাবে মুড়ে দেয়

TLS অ্যাপ্লিকেশন লেয়ারের (M6) ঠিক নিচে বসে সেই প্রোটোকলের পুরো কানেকশনকে এনক্রিপ্ট করে দেয় — HTTPS আসলে HTTP (L29) একটি TLS-এনক্রিপ্টেড কানেকশনের উপর দিয়ে চলা ছাড়া আর কিছুই নয়। এটি L01-এর লেয়ারিং/মডুলারিটি নীতির একটি চমৎকার বাস্তব উদাহরণ — HTTP প্রোটোকল নিজে বিন্দুমাত্র বদলায় না; TLS নিচে বসে পুরো কানেকশনটিকে "মুড়ে" দেয়, HTTP জানেও না যে তার নিচে TLS আছে।

মূল অন্তর্দৃষ্টি

HTTP-কে HTTPS বানাতে HTTP প্রোটোকলের একটি লাইনও বদলাতে হয় না — শুধু তার নিচে TLS বসিয়ে দেওয়া হয়। এটিই দেখায় কেন স্তরভিত্তিক (layered) ডিজাইন এত শক্তিশালী: একটি নতুন সুরক্ষা-স্তর যোগ করতে উপরের স্তরের প্রোটোকল পুনর্লিখনের দরকার হয় না।

৩ · TLS হ্যান্ডশেক — হাই-লেভেল ধারণা

TLS হ্যান্ডশেক (discrete-math কোর্সের RSA পাঠ ও cybersecurity কোর্সের TLS-হ্যান্ডশেক পাঠে বিস্তারিত আছে, এখানে সংক্ষেপে) একটি hybrid পদ্ধতি ব্যবহার করে — প্রথমে asymmetric ক্রিপ্টো (পাবলিক/প্রাইভেট-কী জোড়া) দিয়ে দুই পক্ষ নিরাপদে একটি shared symmetric session key-তে একমত হয়, তারপর যেহেতু symmetric এনক্রিপশন asymmetric-এর চেয়ে অনেক দ্রুত, বাকি পুরো সেশনের সব অ্যাপ্লিকেশন ডেটা সেই দ্রুত symmetric কী দিয়ে এনক্রিপ্ট হয়। এই একই hybrid-পদ্ধতি-পয়েন্ট আগের কোর্সগুলোতেও উল্লেখ করা হয়েছে — asymmetric ক্রিপ্টো ধীর কিন্তু প্রাথমিক পরিচয়/কী-বিনিময়ের জন্য নিরাপদ, symmetric ক্রিপ্টো দ্রুত কিন্তু আগে থেকে একটি shared secret দরকার হয়।

৪ · TLS বনাম IPsec (L47) — স্তর ও ট্রান্সপারেন্সির পার্থক্য

L47-এ IPsec দেখেছি — যা নেটওয়ার্ক লেয়ারে (M4) কাজ করে বলে সব IP ট্রাফিককে স্বচ্ছভাবে সুরক্ষা দেয়, কোনো প্রতি-অ্যাপ্লিকেশন ইন্টিগ্রেশনের দরকার হয় না। TLS ঠিক তার বিপরীত ট্রেড-অফে বসে — এটি ট্রান্সপোর্ট স্তরের উপরে (M5-M6-এর মাঝামাঝি) বসে নির্দিষ্ট একটি অ্যাপ্লিকেশন কানেকশনকে সুরক্ষা দেয়, তাই প্রতিটি অ্যাপ্লিকেশনকে জেনেশুনে TLS ব্যবহার করার জন্য আলাদাভাবে ইন্টিগ্রেট করতে হয় (যেমন একটি ওয়েব সার্ভারকে HTTPS চালু করতে TLS লাইব্রেরি/সার্টিফিকেট কনফিগার করতে হয়)।

Python

# TLS বনাম IPsec — স্তর ও ট্রান্সপারেন্সি অনুযায়ী তুলনা (ইন-মেমরি রেফারেন্স টেবিল)

comparison = {
    "TLS": {
        "osi_layer": "ট্রান্সপোর্ট স্তরের উপরে (৪-৭ এর মাঝামাঝি, অ্যাপ্লিকেশনের ঠিক নিচে)",
        "protects_which_traffic": "শুধু সেই নির্দিষ্ট অ্যাপ্লিকেশন কানেকশন যা সরাসরি TLS ব্যবহার করে (যেমন HTTPS)",
        "requires_per_application_integration": True,
    },
    "IPsec": {
        "osi_layer": "নেটওয়ার্ক স্তর (স্তর ৩)",
        "protects_which_traffic": "সেই হোস্ট/গেটওয়ে দিয়ে যাওয়া সব IP ট্রাফিক, প্রোটোকল/অ্যাপ্লিকেশন নির্বিশেষে",
        "requires_per_application_integration": False,
    },
}

print("=" * 60)
for name, info in comparison.items():
    print(f"{name}:")
    for key, value in info.items():
        print(f"  {key}: {value}")
    print("-" * 60)

লক্ষ্য করুন — requires_per_application_integration এর মান TLS-এর জন্য True আর IPsec-এর জন্য False। এটিই দুই প্রোটোকলের মূল ব্যবহারিক পার্থক্য: TLS নমনীয় কিন্তু প্রতি-অ্যাপ্লিকেশন কাজ চায়, IPsec এক জায়গায় কনফিগার করলেই সব ট্রাফিক ঢেকে দেয় কিন্তু নির্দিষ্ট অ্যাপ্লিকেশন-স্তরের সূক্ষ্ম-নিয়ন্ত্রণ দেয় না।

মূল কথা · Key takeaway

TLS ও IPsec একে অপরের প্রতিদ্বন্দ্বী নয়, বরং ভিন্ন স্তরে ভিন্ন কাজের জন্য পরিপূরক টুল — একটি সংস্থা প্রায়ই দুটোই একসাথে ব্যবহার করে (যেমন office-to-office ট্রাফিকের জন্য IPsec VPN, আর প্রতিটি ওয়েবসাইটের জন্য আলাদাভাবে HTTPS/TLS)।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ HTTP-কে HTTPS বানাতে HTTP প্রোটোকল নিজে কেন বদলাতে হয় না?

কারণ TLS HTTP-এর ঠিক নিচে বসে সম্পূর্ণ কানেকশনটিকে এনক্রিপ্ট করে দেয় — HTTP শুধু জানে সে একটি "কানেকশনের" উপর দিয়ে ডেটা পাঠাচ্ছে-গ্রহণ করছে, সেই কানেকশনটি আসলে TLS-এনক্রিপ্টেড কিনা তা HTTP-এর দৃষ্টিকোণ থেকে সম্পূর্ণ অপ্রাসঙ্গিক। এটি L01-এর লেয়ারিং নীতির সরাসরি প্রয়োগ — প্রতিটি স্তর শুধু তার ঠিক নিচের স্তরের ইন্টারফেস জানে, সেই স্তরের ভেতরের বাস্তবায়ন সম্পর্কে অজ্ঞ থাকে।

প্র ০২ TLS হ্যান্ডশেকে কেন পুরো সেশন জুড়ে asymmetric ক্রিপ্টো ব্যবহার না করে symmetric key-তে সুইচ করা হয়?

Asymmetric ক্রিপ্টো (পাবলিক/প্রাইভেট-কী) গাণিতিকভাবে অনেক বেশি costly/ধীর — বড় পরিমাণ ডেটার জন্য এটি ব্যবহারিকভাবে খুবই অদক্ষ। তাই TLS শুধু প্রাথমিক পরিচয়/কী-বিনিময়ের জন্য asymmetric ক্রিপ্টো ব্যবহার করে (যেখানে এর সুরক্ষা-গুণ সবচেয়ে গুরুত্বপূর্ণ), তারপর সেই বিনিময়কৃত shared secret দিয়ে দ্রুত symmetric এনক্রিপশনে সুইচ করে বাকি সব ডেটার জন্য — এই hybrid পদ্ধতি নিরাপত্তা ও গতি উভয়ই দেয়।

প্র ০৩ একটি সংস্থা কেন IPsec VPN ও TLS/HTTPS দুটোই একসাথে ব্যবহার করতে পারে — একটি থাকলে কি অন্যটি অপ্রয়োজনীয় নয়?

না — দুটো ভিন্ন সমস্যার সমাধান করে। IPsec VPN সাধারণত দুই অফিসের পুরো নেটওয়ার্ককে সংযুক্ত করে (যেমন অভ্যন্তরীণ ফাইল শেয়ারিং, ডাটাবেস কানেকশন — যেসব প্রোটোকলের নিজস্ব এনক্রিপশন নেই)। কিন্তু একই সংস্থার পাবলিক-ফেসিং ওয়েবসাইট (যা সাধারণ ইন্টারনেট ব্যবহারকারীরা VPN-এর বাইরে থেকে ভিজিট করে) সুরক্ষিত করতে HTTPS/TLS দরকার — কারণ সাধারণ ভিজিটররা VPN টানেলের ভেতরে নেই। তাই দুটো ভিন্ন ট্রাফিক-প্যাটার্নের জন্য দুটোই প্রয়োজন হতে পারে।

অনুশীলন

চিন্তা করুন: আপনার ব্রাউজারের ঠিকানা বারে যেকোনো একটি ওয়েবসাইট খুলে দেখুন এটি http:// নাকি https:// ব্যবহার করছে — এবং কেন প্রায় সব আধুনিক ওয়েবসাইট এখন https:// ব্যবহার করে তা ব্যাখ্যা করুন।

বর্তমানে প্রায় সব ওয়েবসাইট https:// ব্যবহার করে কারণ ব্রাউজার ভেন্ডর ও সার্চ ইঞ্জিন (উদাহরণ: Chrome-এ "Not Secure" সতর্কতা) এখন নিরাপত্তাহীন http://-কে সক্রিয়ভাবে নিরুৎসাহিত করে, এবং Let's Encrypt-এর মতো সেবা বিনামূল্যে TLS সার্টিফিকেট সহজলভ্য করে দিয়েছে — তাই এনক্রিপশনের প্রযুক্তিগত ও প্রায়োগিক বাধা দুটোই কার্যত দূর হয়ে গেছে।
পরীক্ষা করুন: উপরের কোড সেলে comparison dict-এ একটি তৃতীয় এন্ট্রি "প্লেইন HTTP" যোগ করুন যার protects_which_traffic হবে "কোনোটিই না — এনক্রিপশন নেই" এবং লুপ চালিয়ে দেখুন এটি সঠিকভাবে প্রিন্ট হয় কি না।

যেহেতু লুপটি comparison.items()-এর উপর সাধারণভাবে ইটারেট করে, dict-এ নতুন যেকোনো কী-ভ্যালু জোড়া যোগ করলেই তা স্বয়ংক্রিয়ভাবে আউটপুটে যুক্ত হয়ে যাবে — এটি দেখায় dict-চালিত রেফারেন্স-টেবিল প্যাটার্নটি কতটা সহজে বাড়ানো (extensible) যায়, নতুন প্রোটোকল যোগ করতে লুপের কোনো লজিক বদলানোর দরকার হয় না।