HTTPS ও TLS আসলে কীভাবে কাজ করে: হ্যান্ডশেক ও সার্টিফিকেট

কেন HTTPS গুরুত্বপূর্ণ (এবং কেন এটি ভুল বোঝা হয়)

আপনি সম্ভবত ব্রাউজারে তালার আইকন দেখেছেন এবং ধরে নিয়েছেন সাইটটি "নিরাপদ"। কিন্তু এর আসল অর্থ কী? HTTPS শুধু এনক্রিপশন নয়; এটি পরিচয়, অখণ্ডতা এবং বিশ্বাসের বিষয়। অনেক ডেভেলপার TLS-কে ব্ল্যাক বক্স হিসেবে দেখেন—একবার কনফিগার করে ভুলে যান। এতে ভুল কনফিগারেশন, মেয়াদোত্তীর্ণ সার্টিফিকেট এবং দুর্বল সাইফার স্যুট তৈরি হয়।

এই নিবন্ধে, আমরা হ্যান্ডশেক থেকে সার্টিফিকেট যাচাই পর্যন্ত HTTPS এবং TLS আসলে কীভাবে কাজ করে তা ব্যাখ্যা করব এবং সঠিকভাবে সেট আপ করার উপায় দেখাব। কোনো বাড়তি কথা নয়, শুধু আজই প্রয়োগযোগ্য ব্যবহারিক জ্ঞান।

TLS হ্যান্ডশেক: প্রথম বাইটের আগে কী ঘটে

যখন একটি ক্লায়েন্ট (ব্রাউজার) HTTPS-এর মাধ্যমে সার্ভারের সাথে সংযোগ করে, তারা একটি TLS হ্যান্ডশেক সম্পাদন করে। এটি একটি নিরাপদ চ্যানেল প্রতিষ্ঠা করে। এখানে একটি সরলীকৃত সংস্করণ (TLS 1.3):

1. ক্লায়েন্ট হ্যালো: ক্লায়েন্ট সমর্থিত সাইফার স্যুট, একটি র‍্যান্ডম মান এবং একটি কী শেয়ার (কী এক্সচেঞ্জের জন্য) পাঠায়।
2. সার্ভার হ্যালো: সার্ভার একটি সাইফার স্যুট বেছে নেয়, নিজের র‍্যান্ডম মান ও কী শেয়ার পাঠায় এবং তার সার্টিফিকেট চেইন উপস্থাপন করে।
3. প্রমাণীকরণ: ক্লায়েন্ট বিশ্বস্ত CA-এর বিরুদ্ধে সার্ভারের সার্টিফিকেট যাচাই করে এবং হোস্টনেম পরীক্ষা করে।
4. কী ডেরিভেশন: উভয় পক্ষ ECDHE (এলিপ্টিক কার্ভ ডিফি-হেলম্যান এফিমেরাল) ব্যবহার করে শেয়ার্ড সিক্রেট গণনা করে।
5. সমাপ্ত: উভয় পক্ষ হ্যান্ডশেক নিশ্চিত করতে এনক্রিপ্টেড "Finished" বার্তা পাঠায়।

এর পরে, অ্যাপ্লিকেশন ডেটা সিমেট্রিক কী দিয়ে এনক্রিপ্ট করা হয়। TLS 1.3 রাউন্ড ট্রিপ কমিয়ে এক করে, যা লেটেন্সি উন্নত করে।

কী এক্সচেঞ্জ: ECDHE বনাম RSA

পুরোনো TLS সংস্করণগুলি RSA কী এক্সচেঞ্জ ব্যবহার করত, যাতে ফরোয়ার্ড সিক্রেসি নেই। যদি সার্ভারের প্রাইভেট কী আপস হয়, অতীতের ট্রাফিক ডিক্রিপ্ট করা যেতে পারে। আধুনিক সেটআপ ECDHE ব্যবহার করে, যা ফরোয়ার্ড সিক্রেসি প্রদান করে—প্রতিটি সেশনের জন্য অনন্য কী থাকে।

# উদাহরণ: সমর্থিত কী এক্সচেঞ্জ অ্যালগরিদম পরীক্ষা করুন
openssl s_client -connect example.com:443 -cipher 'ECDHE'

সার্টিফিকেট: বিশ্বাসের অ্যাঙ্কর

একটি সার্টিফিকেট একটি পাবলিক কী-কে একটি পরিচয় (ডোমেইন নাম) এর সাথে বাঁধে। এটি একটি সার্টিফিকেট অথরিটি (CA) দ্বারা স্বাক্ষরিত যা ক্লায়েন্ট বিশ্বাস করে। ব্রাউজারগুলি বিশ্বস্ত রুট CA-এর একটি স্টোর নিয়ে আসে।

যখন আপনি একটি সাইটে যান, সার্ভার একটি চেইন পাঠায়: লিফ সার্টিফিকেট (আপনার ডোমেইনের জন্য) → ইন্টারমিডিয়েট CA → রুট CA। ক্লায়েন্ট একটি বিশ্বস্ত রুট পর্যন্ত প্রতিটি স্বাক্ষর যাচাই করে।

সার্টিফিকেটের ধরন

• ডোমেইন ভ্যালিডেটেড (DV): শুধুমাত্র ডোমেইনের নিয়ন্ত্রণ প্রমাণ করে। দ্রুত এবং বিনামূল্যে (যেমন, Let's Encrypt)।
• অর্গানাইজেশন ভ্যালিডেটেড (OV): যাচাইকৃত প্রতিষ্ঠানের বিবরণ অন্তর্ভুক্ত করে।
• এক্সটেন্ডেড ভ্যালিডেশন (EV): কঠোর যাচাই; ব্রাউজার আর সবুজ বার দেখায় না, তবে কিছু এন্টারপ্রাইজ এখনও ব্যবহার করে।

সার্টিফিকেট যাচাইয়ের ধাপ

ব্রাউজারগুলি পরীক্ষা করে:

• স্বাক্ষর চেইন একটি বিশ্বস্ত রুটে পৌঁছায়।
• সার্টিফিকেট তার বৈধতার সময়কালের মধ্যে আছে।
• হোস্টনেম মেলে (সাবজেক্ট অল্টারনেটিভ নেম)।
• সার্টিফিকেট প্রত্যাহার করা হয়নি (OCSP বা CRL-এর মাধ্যমে)।

যদি কোনো পরীক্ষা ব্যর্থ হয়, আপনি একটি সতর্কতা পাবেন। প্রোডাকশনে কখনও এই সতর্কতাগুলি উপেক্ষা করবেন না।

আপনার সার্ভারে HTTPS কনফিগার করা

আধুনিক TLS সেটিংসের সাথে HTTPS-এর জন্য একটি সাধারণ Nginx কনফিগারেশন দেখুন।

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers off;

    # HSTS (সতর্কতার সাথে ব্যবহার করুন)
    add_header Strict-Transport-Security "max-age=63072000" always;
}

নোট:

• শুধুমাত্র TLS 1.2 এবং 1.3 ব্যবহার করুন; পুরোনো সংস্করণ নিষ্ক্রিয় করুন।
• ফরোয়ার্ড সিক্রেসির জন্য ECDHE সাইফার পছন্দ করুন।
• কর্মক্ষমতার জন্য HTTP/2 সক্রিয় করুন।
• HSTS ব্রাউজারকে HTTPS ব্যবহার করতে বাধ্য করে; পরীক্ষার পরে শুধুমাত্র সক্রিয় করুন।

Let's Encrypt দিয়ে সার্টিফিকেট প্রাপ্তি

Let's Encrypt বিনামূল্যে DV সার্টিফিকেট প্রদান করে। ইস্যু এবং নবায়ন স্বয়ংক্রিয় করতে Certbot ব্যবহার করুন:

sudo certbot --nginx -d example.com -d www.example.com

Certbot আপনার Nginx কনফিগারেশন পরিবর্তন করে এবং নবায়নের জন্য একটি cron জব সেট আপ করে। সর্বদা --dry-run দিয়ে নবায়ন পরীক্ষা করুন।

সাধারণ ভুল এবং কীভাবে এড়াবেন

• মেয়াদোত্তীর্ণ সার্টিফিকেট: মনিটরিং এবং স্বয়ংক্রিয় নবায়ন সেট আপ করুন।
• অসম্পূর্ণ চেইন: ইন্টারমিডিয়েট সার্টিফিকেট অন্তর্ভুক্ত করুন (fullchain.pem)।
• দুর্বল সাইফার: RC4, DES এবং এক্সপোর্ট সাইফার নিষ্ক্রিয় করুন।
• মিশ্র কন্টেন্ট: নিশ্চিত করুন সমস্ত রিসোর্স (ছবি, স্ক্রিপ্ট) HTTPS-এর মাধ্যমে লোড হয়।
• HSTS নেই: HSTS ছাড়া, ব্যবহারকারীদের HTTP-তে ডাউনগ্রেড করা যেতে পারে।

আপনার HTTPS কনফিগারেশন পরীক্ষা করা

আপনার সেটআপ যাচাই করতে SSL Labs বা কমান্ড-লাইন টুলের মতো অনলাইন টুল ব্যবহার করুন।

# সার্টিফিকেটের বিবরণ পরীক্ষা করুন
openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -text

# TLS 1.3 সমর্থন পরীক্ষা করুন
openssl s_client -connect example.com:443 -tls1_3

খুঁজুন:

• বৈধ সার্টিফিকেট চেইন।
• কোনো দুর্বল প্রোটোকল নেই (SSLv3, TLS 1.0, TLS 1.1)।
• ফরোয়ার্ড সিক্রেসি সক্রিয়।
• HSTS হেডার উপস্থিত।

সাধারণ প্রশ্নোত্তর

TLS এবং SSL-এর মধ্যে পার্থক্য কী?

SSL হল TLS-এর পূর্বসূরি। TLS 1.0 মূলত SSL 3.1 ছিল। আজ, "SSL" প্রায়শই কথ্য ভাষায় ব্যবহৃত হয়, তবে আপনার সর্বদা TLS 1.2 বা 1.3 ব্যবহার করা উচিত।

HTTPS-এর জন্য কি পেইড সার্টিফিকেট প্রয়োজন?

না। Let's Encrypt থেকে বিনামূল্যে DV সার্টিফিকেট সমস্ত প্রধান ব্রাউজার দ্বারা বিশ্বস্ত এবং পেইড সার্টিফিকেটের মতো একই এনক্রিপশন প্রদান করে। পেইড সার্টিফিকেট ওয়ারেন্টি এবং সহায়তা দেয়, তবে এনক্রিপশন অভিন্ন।

HTTPS কীভাবে কর্মক্ষমতাকে প্রভাবিত করে?

TLS হ্যান্ডশেকের কারণে লেটেন্সি যোগ করে, তবে TLS 1.3 এটি এক রাউন্ড ট্রিপে কমিয়ে দেয়। সেশন রিজাম্পশন এবং HTTP/2-এর সাথে, ওভারহেড ন্যূনতম। আধুনিক CPU-তে এনক্রিপশন/ডিক্রিপশন খরচ কম।

আপনার সার্ভারের TLS কনফিগারেশন পরিদর্শন করতে প্রস্তুত? অস্বাভাবিক ট্রাফিক প্যাটার্ন সনাক্ত করতে এবং আপনার HTTPS সেটআপ প্রত্যাশিতভাবে কাজ করছে কিনা তা নিশ্চিত করতে আমাদের Nginx Log Analyzer ব্যবহার করুন।