HTTPS এবং TLS আসলে কীভাবে কাজ করে: হ্যান্ডশেক ও সার্টিফিকেট
আপনি একটি SSL সার্টিফিকেট যোগ করেন, আপনার ডোমেইন একটি সার্ভারে পয়েন্ট করেন, এবং প্যাডলক দেখা যায়। বেশিরভাগ ডেভেলপার এখানেই থামেন। তারপর একদিন একটি API ক্লায়েন্ট UNABLE_TO_VERIFY_LEAF_SIGNATURE ত্রুটি নিয়ে ব্যর্থ হয়, একটি মোবাইল অ্যাপ পুরানো অ্যান্ড্রয়েডে আপনার সার্টিফিকেট প্রত্যাখ্যান করে, অথবা একটি লোড ব্যালেন্সার TLS টার্মিনেট করে এবং আপনার অ্যাপ সবকিছু সাধারণ HTTP হিসেবে দেখে। হঠাৎ করে আপনার জানা দরকার TCP সংযোগ এবং প্রথম HTTP অনুরোধের মধ্যে আসলে কী ঘটে।
এই নিবন্ধে HTTPS এবং TLS আসলে কীভাবে কাজ করে তা আলোচনা করা হয়েছে: হ্যান্ডশেক কী করে, সার্টিফিকেট কীভাবে যাচাই করা হয়, TLS 1.3-এ কী পরিবর্তন হয়েছে, এবং আপনি যে ত্রুটিগুলি সম্মুখীন হবেন সেগুলি কীভাবে নির্ণয় করবেন।
HTTPS আসলে কী যোগ করে
HTTPS হল TLS সংযোগের মাধ্যমে পাঠানো HTTP। TLS তিনটি গ্যারান্টি প্রদান করে:
- গোপনীয়তা — হ্যান্ডশেকের সময় আলোচিত সিমেট্রিক কী দিয়ে ট্রাফিক এনক্রিপ্ট করা হয়।
- অখণ্ডতা — প্রতিটি রেকর্ডে একটি প্রমাণীকরণ ট্যাগ থাকে, তাই টেম্পারিং সনাক্ত করা যায়।
- প্রমাণীকরণ — সার্ভার প্রমাণ করে যে এটি আপনার অনুরোধকৃত হোস্টনামের সাথে মেলে এমন সার্টিফিকেটের জন্য ব্যক্তিগত কী নিয়ন্ত্রণ করে।
লক্ষ্য করুন সেই তালিকায় কী নেই: ক্লায়েন্ট ডিফল্টভাবে প্রমাণীকৃত হয় না। TLS সার্ভারকে প্রমাণীকরণ করে; আপনার অ্যাপ্লিকেশন ব্যবহারকারীকে প্রমাণীকরণ করে।
TLS 1.2 হ্যান্ডশেক, ধাপে ধাপে
TLS 1.2 এখনও পুরানো অবকাঠামো এবং অনেক কর্পোরেট প্রক্সিতে সাধারণ, তাই এটি বোঝা মূল্যবান। একটি সম্পূর্ণ হ্যান্ডশেক এইরকম দেখায়:
- ClientHello — ক্লায়েন্ট সমর্থিত TLS সংস্করণ, একটি র্যান্ডম মান, সাইফার স্যুটের একটি তালিকা এবং (যদি প্রযোজ্য হয়) SNI হোস্টনাম পাঠায়।
- ServerHello — সার্ভার একটি সংস্করণ এবং সাইফার স্যুট বেছে নেয়, নিজের র্যান্ডম মান ফেরত দেয় এবং তার সার্টিফিকেট চেইন পাঠায়।
- কী বিনিময় — ECDHE-এর সাথে, সার্ভার একটি এফেমেরাল পাবলিক কী পাঠায়; ক্লায়েন্ট তার নিজেরটি পাঠায়। উভয়ই একই শেয়ার্ড সিক্রেট তৈরি করে। সার্ভার তার সার্টিফিকেটের ব্যক্তিগত কী দিয়ে হ্যান্ডশেক ট্রান্সক্রিপ্টে স্বাক্ষর করে।
- Finished — উভয় পক্ষ হ্যান্ডশেক ট্রান্সক্রিপ্টের উপর একটি MAC পাঠায়, নিশ্চিত করে যে কিছু টেম্পার করা হয়নি।
- অ্যাপ্লিকেশন ডেটা — HTTP অনুরোধ এবং প্রতিক্রিয়া এনক্রিপ্টেড অবস্থায় প্রবাহিত হয়।
গুরুত্বপূর্ণ বিবরণ হল এফেমেরাল কী বিনিময়। ECDHE-এর সাথে, প্রতি সংযোগে একটি নতুন কী জোড়া তৈরি হয়। এমনকি যদি একজন আক্রমণকারী বছরের পর বছর ট্রাফিক রেকর্ড করে এবং পরে সার্ভারের ব্যক্তিগত কী চুরি করে, তারা অতীতের সেশনগুলি ডিক্রিপ্ট করতে পারবে না। এই বৈশিষ্ট্যটিকে ফরওয়ার্ড সিক্রেসি বলা হয়, এবং এটি স্ট্যাটিক RSA কী বিনিময়কে বাতিল করার প্রধান কারণ।
TLS 1.3 কীভাবে খেলাটি বদলে দিল
TLS 1.3 হ্যান্ডশেককে একক রাউন্ড ট্রিপে সরল করে এবং লিগ্যাসি অ্যালগরিদম সম্পূর্ণভাবে সরিয়ে দেয়।
| দিক | TLS 1.2 | TLS 1.3 |
|---|---|---|
| রাউন্ড ট্রিপ (সম্পূর্ণ হ্যান্ডশেক) | ২ | ১ |
| কী বিনিময় | RSA বা ECDHE | শুধুমাত্র ECDHE (ফরওয়ার্ড সিক্রেট) |
| সাইফার স্যুট | আলাদা সাইফার, MAC, কী বিনিময় | শুধুমাত্র AEAD স্যুট, যেমন TLS_AES_128_GCM_SHA256 |
| স্ট্যাটিক RSA, CBC, RC4 | অনুমোদিত | সরানো হয়েছে |
| সেশন পুনরায় শুরু | সেশন আইডি / টিকিট | PSK সহ 0-RTT বিকল্প |
TLS 1.3-এ ক্লায়েন্ট কী বিনিময় গ্রুপ অনুমান করে এবং প্রথম বার্তায় তার শেয়ার পাঠায়, তাই সার্ভার অবিলম্বে কী চুক্তি সম্পূর্ণ করতে পারে। সার্টিফিকেট এখনও পাঠানো হয়, কিন্তু সেগুলি এখন এনক্রিপ্ট করা হয়, যার মানে প্যাসিভ পর্যবেক্ষকরা আর দেখতে পায় না কোন হোস্টনাম পরিবেশন করা হচ্ছে — শুধুমাত্র ClientHello-এ SNI এটি প্রকাশ করে যদি এনক্রিপ্টেড ক্লায়েন্ট হ্যালো ব্যবহার না করা হয়।
0-RTT পুনরায় শুরু একটি ফিরে আসা ক্লায়েন্টকে প্রথম ফ্লাইটের সাথে অ্যাপ্লিকেশন ডেটা পাঠানোর অনুমতি দেয়। এটি দ্রুত, কিন্তু 0-RTT ডেটা রিপ্লে-যোগ্য, তাই পেমেন্টের মতো নন-আইডেম্পোটেন্ট অনুরোধের জন্য এটি কখনই ব্যবহার করবেন না।
সার্টিফিকেট এবং চেইন যাচাইকরণ
একটি সার্টিফিকেট একটি পাবলিক কীকে একটি হোস্টনামের সাথে বেঁধে দেয়। যাচাইকরণ হল একটি চেইন ওয়াক:
- সার্ভার তার লিফ সার্টিফিকেট এবং ইন্টারমিডিয়েট সার্টিফিকেট পাঠায়।
- ক্লায়েন্ট তার স্টোরে একটি বিশ্বস্ত রুট খোঁজে, তারপর চেইনের উপরে প্রতিটি স্বাক্ষর যাচাই করে।
- এটি Subject Alternative Name (SAN) ক্ষেত্রের বিরুদ্ধে হোস্টনাম পরীক্ষা করে — Common Name আধুনিক ক্লায়েন্ট দ্বারা উপেক্ষা করা হয়।
- এটি বৈধতার তারিখ এবং প্রত্যাহার অবস্থা (CRL বা OCSP, প্রায়শই স্ট্যাপল করা) পরীক্ষা করে।
unable to verify ত্রুটির সবচেয়ে সাধারণ কারণ হল অনুপস্থিত ইন্টারমিডিয়েট সার্টিফিকেট। ব্রাউজারগুলি কখনও কখনও ইন্টারমিডিয়েট ক্যাশ করে এটি ঢেকে রাখে, কিন্তু কমান্ড-লাইন টুল এবং মোবাইল অ্যাপগুলি কঠোরভাবে ব্যর্থ হয়। সর্বদা সম্পূর্ণ চেইন পরিবেশন করুন, লিফ প্রথমে, তারপর ইন্টারমিডিয়েট — কখনই রুট নয়।
OpenSSL দিয়ে ব্যবহারিক ডিবাগিং
যখন কিছু ভেঙে যায়, ক্লায়েন্টকে দোষারোপ করার আগে সার্ভার আসলে কী পাঠায় তা পরীক্ষা করুন।
# সার্ভার যে সার্টিফিকেট চেইন উপস্থাপন করে তা দেখান
openssl s_client -connect example.com:443 -servername example.com -showcerts
# শুধুমাত্র TLS 1.3 নেগোশিয়েট করুন এবং নির্বাচিত সাইফার তালিকা করুন
openssl s_client -connect example.com:443 -tls1_3
# এক লাইনে সার্টিফিকেটের মেয়াদ শেষের তারিখ পরীক্ষা করুন
echo | openssl s_client -connect example.com:443 2>/dev/null \
| openssl x509 -noout -dates -subject -ext subjectAltNameযদি s_client রিপোর্ট করে verify error:num=21:unable to verify the first certificate, তাহলে চেইন অসম্পূর্ণ। যদি এটি হোস্টনাম মিসম্যাচ রিপোর্ট করে, SAN তালিকা পরীক্ষা করুন — ওয়াইল্ডকার্ড সার্টিফিকেট শুধুমাত্র একটি লেবেল কভার করে, তাই *.example.com api.example.com-এর সাথে মেলে কিন্তু a.b.example.com-এর সাথে মেলে না।
সাধারণ ভুল কনফিগারেশন
- মিশ্র কন্টেন্ট — একটি HTTPS পৃষ্ঠা
http://স্ক্রিপ্ট বা ছবি লোড করছে। ব্রাউজারগুলি সক্রিয় মিশ্র কন্টেন্ট ব্লক করে এবং প্যাসিভ কন্টেন্ট স্বয়ংক্রিয়ভাবে আপগ্রেড করতে পারে। - লোড ব্যালেন্সারে TLS টার্মিনেটেড — ব্যাকএন্ড সাধারণ HTTP দেখে।
X-Forwarded-Protoফরওয়ার্ড করুন এবং শুধুমাত্র পরিচিত প্রক্সি থেকে এটি বিশ্বাস করুন, নাহলে আপনার অ্যাপ ভুল রিডাইরেক্ট URL তৈরি করতে পারে। - দুর্বল প্রোটোকল সংস্করণ সক্রিয় — TLS 1.0 এবং 1.1 নিষ্ক্রিয় করা উচিত। শুধুমাত্র TLS 1.2 এবং 1.3 লক্ষ্য করুন।
- HSTS নেই —
Strict-Transport-Securityহেডার ছাড়া, প্রথম অনুরোধ এখনও ডাউনগ্রেড করা যেতে পারে। একটি সংক্ষিপ্তmax-ageদিয়ে শুরু করুন, তারপর আত্মবিশ্বাসী হলে এটি বাড়ান। - প্রোডাকশনে স্ব-স্বাক্ষরিত সার্টিফিকেট — অভ্যন্তরীণ পরীক্ষার জন্য ঠিক আছে, কিন্তু তারা ব্যবহারকারী এবং ক্লায়েন্টদের সতর্কতা উপেক্ষা করতে প্রশিক্ষণ দেয়।
একটি যুক্তিসঙ্গত সার্ভার কনফিগারেশন
Nginx-এর জন্য, একটি আধুনিক বেসলাইন এইরকম দেখায়:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;TLS 1.3-এ সার্ভারকে সাইফার বেছে নিতে দিন — সেখানে ক্লায়েন্ট পছন্দ ঠিক আছে কারণ স্যুটগুলি সবই শক্তিশালী। সেশন টিকিট বন্ধ রাখুন যদি না আপনি টিকিট কী রোটেট করেন, কারণ একটি ফাঁস হওয়া টিকিট কী পুনরায় শুরু করার নিরাপত্তা compromize করতে পারে।
সচরাচর জিজ্ঞাসিত প্রশ্ন
HTTPS কি হোস্টনাম এনক্রিপ্ট করে?
ডিফল্টভাবে না। ClientHello-এ SNI এক্সটেনশন প্লেইনটেক্সটে পাঠানো হয় যাতে সার্ভার জানে কোন সার্টিফিকেট উপস্থাপন করতে হবে। এনক্রিপ্টেড ক্লায়েন্ট হ্যালো (ECH) এটি লুকায়, কিন্তু গ্রহণযোগ্যতা এখনও সীমিত। পাথ এবং কোয়েরি স্ট্রিং সর্বদা এনক্রিপ্ট করা হয়।
কেন আমার সার্টিফিকেট ব্রাউজারে কাজ করে কিন্তু curl বা মোবাইল অ্যাপে ব্যর্থ হয়?
প্রায় সবসময় একটি অনুপস্থিত ইন্টারমিডিয়েট সার্টিফিকেট। ব্রাউজারগুলি প্রায়শই নিজেরাই ইন্টারমিডিয়েটগুলি আনে বা ক্যাশ করে, যখন কঠোর ক্লায়েন্টদের সার্ভারকে সম্পূর্ণ চেইন পাঠাতে হয়। openssl s_client -showcerts দিয়ে যাচাই করুন।
TLS 1.3 কি সর্বদা TLS 1.2-এর চেয়ে দ্রুত?
নতুন সংযোগের জন্য, হ্যাঁ — দুইয়ের পরিবর্তে এক রাউন্ড ট্রিপ। পুনরায় শুরু করা সংযোগের জন্য ব্যবধান কমে যায়, এবং 0-RTT TLS 1.3-কে আরও দ্রুত করতে পারে, নন-আইডেম্পোটেন্ট অনুরোধে রিপ্লে ঝুঁকির বিনিময়ে।
যদি আপনি TLS পরিবর্তনের পরে একটি ওয়েব সার্ভার অডিট করছেন, লগ বিশ্লেষণ প্রায়শই প্রকৃত প্রভাব প্রকাশ করে: ভাঙা রিডাইরেক্ট, অপ্রত্যাশিত 4xx স্পাইক, বা ক্লায়েন্টরা এখনও HTTP হিট করছে। আপনি একটি অ্যাক্সেস লগ Nginx লগ অ্যানালাইজার-এ ফেলে স্ট্যাটাস কোড বিতরণ দেখতে পারেন এবং যে ক্লায়েন্টরা কখনও HTTPS-এ আপগ্রেড সম্পূর্ণ করেনি তাদের চিহ্নিত করতে পারেন।