HTTPS কী এবং SSL/TLS Certificate কীভাবে কাজ করে

কোনো ওয়েবসাইট খুললে Browser-এর Address Bar-এ সাধারণত https:// লেখা দেখা যায়। কোনো Browser আবার ঠিকানার পাশে নিরাপত্তা বা Site Information চিহ্ন দেখায়। অনেকের ধারণা, এই চিহ্ন থাকলেই ওয়েবসাইটটি সম্পূর্ণ নিরাপদ এবং সেখানে কোনো ধরনের প্রতারণা বা তথ্য চুরির আশঙ্কা নেই। বাস্তবে বিষয়টি এত সরল নয়।

HTTPS মূলত ব্যবহারকারীর Browser এবং সংশ্লিষ্ট Server-এর মধ্যে তথ্য আদান–প্রদানের পথ সুরক্ষিত করে। এর ফলে মাঝপথে থাকা অননুমোদিত কেউ সহজে তথ্য পড়তে বা পরিবর্তন করতে পারে না। তবে ওয়েবসাইটের নিজস্ব নিরাপত্তা দুর্বল হলে, Server আক্রান্ত হলে কিংবা ব্যবহারকারী ভুল ওয়েবসাইটে তথ্য দিলে শুধু HTTPS তাকে সব বিপদ থেকে রক্ষা করতে পারবে না।

তাই HTTPS বোঝার সময় দুটি বিষয় আলাদা রাখা জরুরি। প্রথমটি হচ্ছে সংযোগের নিরাপত্তা, দ্বিতীয়টি ওয়েবসাইটের সামগ্রিক বিশ্বাসযোগ্যতা। এই নিবন্ধে HTTPS, SSL/TLS Certificate, Encryption, Certificate যাচাই এবং ওয়েবসাইটে নিরাপদ সংযোগ চালুর বিষয়গুলো সহজভাবে ব্যাখ্যা করা হয়েছে।

HTTPS কী?

HTTPS বলতে সাধারণভাবে Hypertext Transfer Protocol Secure বোঝানো হয়। আরও নির্ভুলভাবে বললে, এটি TLS দিয়ে সুরক্ষিত একটি HTTP সংযোগ।

একটি ওয়েবসাইট শুধু লেখা বা HTML দিয়ে তৈরি হয় না। সেখানে ছবি, Video, Font, Stylesheet, Script, Form এবং বিভিন্ন API থেকে আসা তথ্য থাকতে পারে। ব্যবহারকারী যখন কোনো ওয়েবসাইট খোলেন, তখন Browser এসব উপাদান Server-এর কাছ থেকে চায়। Server প্রয়োজনীয় তথ্য পাঠায় এবং Browser সেগুলো সাজিয়ে পর্দায় দেখায়।

এই অনুরোধ ও উত্তর আদান–প্রদানের নিয়ম হচ্ছে HTTP। কিন্তু সাধারণ HTTP সংযোগে তথ্য সুরক্ষিতভাবে Encrypt করা থাকে না। ফলে অনিরাপদ Network বা মাঝপথে থাকা আক্রমণকারী নির্দিষ্ট পরিস্থিতিতে তথ্য দেখতে কিংবা পরিবর্তন করতে পারে।

HTTPS ব্যবহার করলে একই HTTP যোগাযোগ TLS নামের নিরাপত্তা ব্যবস্থার ভেতর দিয়ে পরিচালিত হয়। ফলে Browser এবং Server-এর মধ্যে চলমান তথ্য Encrypt করা থাকে। আধুনিক TLS সংযোগের প্রধান লক্ষ্য হচ্ছে পরিচয় যাচাই, তথ্যের গোপনীয়তা এবং তথ্য পরিবর্তন ঠেকানো। IETF-এর বর্তমান TLS 1.3 মান এবং MDN-এর TLS নির্দেশনা বিষয়টি বিস্তারিতভাবে ব্যাখ্যা করেছে।

HTTP ও HTTPS-এর মধ্যে পার্থক্য

HTTP এবং HTTPS উভয় ব্যবস্থাতেই Browser ও Server তথ্য আদান–প্রদান করে। পার্থক্য তৈরি হয় সেই তথ্য কোন পথে এবং কী ধরনের সুরক্ষায় পাঠানো হচ্ছে তার ওপর।

এখানে একটি বিষয় মনে রাখা দরকার—HTTPS শুধু Login, Banking বা E-commerce ওয়েবসাইটের জন্য নয়। সাধারণ Blog, News Portal, ব্যক্তিগত Website কিংবা শুধু তথ্য প্রকাশ করা Business Website-এর জন্যও এটি গুরুত্বপূর্ণ। কারণ ব্যবহারকারী কোনো Form পূরণ না করলেও তার দেখা Page, ছবি, Script ও Cookie অনিরাপদ HTTP সংযোগে ঝুঁকির মধ্যে পড়তে পারে। Google-এর HTTPS নির্দেশনা সব ওয়েবসাইটে নিরাপদ সংযোগ ব্যবহারের পরামর্শ দেয়।

Smart TV গোপনীয়তা: ব্যক্তিগত তথ্য সংগ্রহ সীমিত করে নিরাপদ থাকবেন যেভাবে

SSL ও TLS কি একই প্রযুক্তি?

ওয়েবসাইটের নিরাপত্তা নিয়ে আলোচনা করলে এখনো “SSL Certificate” কথাটি বেশি শোনা যায়। Hosting প্রতিষ্ঠান, Domain বিক্রেতা এবং সাধারণ ব্যবহারকারীরাও এই নামটি ব্যবহার করেন। তবে আধুনিক ওয়েব সংযোগে পুরোনো SSL প্রযুক্তি ব্যবহার করা হয় না।

SSL বা Secure Sockets Layer ছিল নিরাপদ Network যোগাযোগের পুরোনো ব্যবস্থা। পরে এর উন্নত সংস্করণ হিসেবে TLS বা Transport Layer Security এসেছে। বর্তমানে নিরাপদ ওয়েব সংযোগের জন্য TLS ব্যবহৃত হয়।

তাই বাজারে কোনো সেবা “SSL Certificate” নামে বিক্রি হলেও সেটি সাধারণত আধুনিক TLS সংযোগ চালু করার Digital Certificate। প্রচলিত নাম হিসেবে SSL Certificate বলা হলেও প্রযুক্তিগতভাবে TLS Certificate বলা বেশি নির্ভুল।

পুরোনো SSL সংস্করণ এবং TLS 1.0 ও TLS 1.1 নিরাপদ হিসেবে বিবেচিত নয়। আধুনিক Server ও Browser-এ TLS 1.3 অগ্রাধিকার পাওয়া উচিত। সামঞ্জস্যের প্রয়োজনে কিছু ব্যবস্থায় এখনো TLS 1.2 থাকতে পারে, তবে পুরোনো সংস্করণ চালু রাখা ঠিক নয়।

SSL/TLS Certificate কী?

SSL/TLS Certificate হচ্ছে একটি Digital Certificate, যা কোনো নির্দিষ্ট Domain-এর সঙ্গে একটি Public Key-এর সম্পর্ক প্রমাণ করতে সাহায্য করে। এটি সাধারণত বিশ্বস্ত Certificate Authority বা CA থেকে নেওয়া হয়।

সহজভাবে বললে, Certificate Browser-কে জানায়—সে যে Domain-এ সংযোগ দেওয়ার চেষ্টা করছে, Server-টি সেই Domain-এর জন্য বৈধ Certificate উপস্থাপন করছে এবং Certificate-টি Browser-এর বিশ্বস্ত তালিকায় থাকা কোনো Authority-এর মাধ্যমে যাচাই করা হয়েছে।

Certificate সাধারণত নিচের তথ্যগুলো ধারণ করে:

• Certificate কোন Domain বা Domain-গুলোর জন্য তৈরি;
• সংশ্লিষ্ট Public Key;
• Certificate প্রদানকারী Certificate Authority;
• Certificate চালু ও মেয়াদ শেষ হওয়ার সময়;
• Certificate-এর ক্রমিক নম্বর;
• Certificate প্রদানকারীর Digital Signature;
• ব্যবহৃত Signature ও Cryptographic Algorithm;
• প্রয়োজনে বিকল্প Domain-এর তালিকা।

Certificate-এর বিপরীতে থাকা Private Key অত্যন্ত সংবেদনশীল। এটি Server বা অনুমোদিত নিরাপত্তা ব্যবস্থার মধ্যে গোপন রাখতে হয়। কেউ Private Key পেয়ে গেলে সংশ্লিষ্ট সংযোগের নিরাপত্তা গুরুতর ঝুঁকির মধ্যে পড়তে পারে। তাই Certificate প্রকাশ করা গেলেও Private Key কখনো প্রকাশ করা উচিত নয়।

Certificate Authority কী কাজ করে?

Certificate Authority এমন একটি প্রতিষ্ঠান বা ব্যবস্থা, যা নির্দিষ্ট নিয়ম অনুসরণ করে Digital Certificate প্রদান করে। Browser এবং Operating System কিছু Root Certificate-কে আগে থেকেই বিশ্বাসযোগ্য হিসেবে সংরক্ষণ করে রাখে।

কোনো ওয়েবসাইট Certificate চাইলে Authority প্রথমে যাচাই করে আবেদনকারী সেই Domain নিয়ন্ত্রণ করতে পারে কি না। এটি যাচাই করার জন্য Domain-এর DNS Record, Server-এর নির্দিষ্ট File অথবা অন্য অনুমোদিত পদ্ধতি ব্যবহার করা হতে পারে।

উদাহরণ হিসেবে Let’s Encrypt একটি বিনা মূল্যের ও স্বয়ংক্রিয় Certificate Authority। তাদের ACME পদ্ধতিতে আবেদনকারীকে প্রথমে Domain-এর নিয়ন্ত্রণ প্রমাণ করতে হয়। যাচাই সফল হলে Certificate দেওয়া হয় এবং নির্দিষ্ট সময় পর আবার যাচাইয়ের মাধ্যমে সেটি নবায়ন করা যায়। Let’s Encrypt কীভাবে Certificate দেয় পাতায় এই প্রক্রিয়ার বিস্তারিত রয়েছে।

তবে Domain-এর নিয়ন্ত্রণ প্রমাণ করা এবং ওয়েবসাইটের মালিক নৈতিক বা বিশ্বাসযোগ্য—দুটি এক বিষয় নয়। কোনো প্রতারণামূলক ওয়েবসাইটও নিজের Domain-এর জন্য বৈধ Certificate নিতে পারে। Certificate নিশ্চিত করে যে Browser নির্দিষ্ট Domain-এর সঙ্গে নিরাপদ সংযোগ স্থাপন করেছে; এটি ওয়েবসাইটের প্রতিটি দাবি সত্য বলে নিশ্চয়তা দেয় না।

TLS Handshake কীভাবে সম্পন্ন হয়?

ব্যবহারকারী কোনো HTTPS ঠিকানা খোলার পর মূল Page আসার আগে Browser ও Server-এর মধ্যে খুব অল্প সময়ে একটি নিরাপত্তা আলোচনা হয়। একে TLS Handshake বলা হয়।

প্রক্রিয়াটি বোঝাতে techtipsdesk.com উদাহরণ হিসেবে ধরা যাক। ব্যবহারকারী Browser-এ https://techtipsdesk.com লিখে প্রবেশ করলে সাধারণভাবে নিচের ঘটনাগুলো ঘটে।

১. Browser Server খুঁজে বের করে

প্রথমে Browser বা Operating System DNS ব্যবস্থার মাধ্যমে techtipsdesk.com কোন Server বা Network ঠিকানায় রয়েছে তা খুঁজে বের করে। ওয়েবসাইটে CDN বা Reverse Proxy ব্যবহার করা হলে Browser প্রথমে সেই মধ্যবর্তী সেবার Server-এ পৌঁছাতে পারে।

২. Browser নিরাপত্তার প্রস্তাব পাঠায়

Browser একটি ClientHello বার্তা পাঠায়। এতে Browser কোন TLS সংস্করণ, Cryptographic ব্যবস্থা এবং Key Exchange পদ্ধতি সমর্থন করে তার প্রয়োজনীয় তথ্য থাকে।

৩. Server উপযুক্ত ব্যবস্থা নির্বাচন করে

Server একটি ServerHello বার্তার মাধ্যমে সমর্থিত নিরাপত্তা পদ্ধতি নির্বাচন করে। আধুনিক সংযোগে Browser ও Server এমন Algorithm ঠিক করে, যার মাধ্যমে নিরাপদভাবে একটি যৌথ গোপন Key তৈরি করা সম্ভব হয়।

৪. Server Certificate পাঠায়

Server তার Digital Certificate এবং প্রয়োজনীয় মধ্যবর্তী Certificate পাঠায়। Certificate-এ Domain ও Public Key-সংক্রান্ত তথ্য থাকে। Server নিজের Private Key দিয়ে Handshake-এর নির্দিষ্ট অংশে Digital Signature তৈরি করে প্রমাণ করে যে সে সংশ্লিষ্ট Private Key-এর অধিকারী।

এখানে একটি প্রচলিত ভুল ধারণা পরিষ্কার করা দরকার। আধুনিক TLS 1.3 সংযোগে Certificate-এর Private Key দিয়ে ব্যবহারকারীর প্রতিটি তথ্য সরাসরি Encrypt বা Decrypt করা হয় না। Private Key মূলত Server-এর পরিচয় প্রমাণের কাজে ব্যবহৃত হয়। পরবর্তী তথ্য আদান–প্রদানের জন্য আলাদা, সাময়িক Session Key তৈরি করা হয়।

৫. Browser Certificate যাচাই করে

Browser কয়েকটি গুরুত্বপূর্ণ বিষয় পরীক্ষা করে:

• Certificate-এর Domain এবং খোলা Domain এক কি না;
• Certificate-এর মেয়াদ বৈধ কি না;
• Certificate বিশ্বস্ত Authority-এর Signature বহন করছে কি না;
• প্রয়োজনীয় Certificate Chain ঠিক আছে কি না;
• Server সংশ্লিষ্ট Private Key-এর অধিকার প্রমাণ করতে পেরেছে কি না;
• সংযোগের নিরাপত্তা নীতিতে গুরুতর অসামঞ্জস্য আছে কি না।

এই পরীক্ষায় বড় সমস্যা পাওয়া গেলে Browser সাধারণত Your connection is not private, Certificate expired অথবা Domain সম্পর্কিত সতর্কতা দেখায়।

৬. যৌথ Session Key তৈরি হয়

Browser ও Server Key Exchange-এর মাধ্যমে এমন গোপন Keying Material তৈরি করে, যা মাঝপথে সরাসরি পাঠাতে হয় না। এখান থেকে সংযোগের জন্য প্রয়োজনীয় Session Key তৈরি হয়।

এই Session Key সাধারণত Symmetric Encryption ব্যবস্থায় ব্যবহৃত হয়। Symmetric Encryption দ্রুত কাজ করে বলে Page, ছবি, Form Data, Cookie, Header এবং অন্যান্য তথ্য আদান–প্রদানে এটি কার্যকর।

৭. Encrypted যোগাযোগ শুরু হয়

Handshake সফল হলে Browser ওয়েবপৃষ্ঠার জন্য HTTP Request পাঠায়, তবে সেটি তখন TLS-এর নিরাপদ স্তরের ভেতরে থাকে। Server-এর উত্তরও একইভাবে সুরক্ষিত থাকে।

এই পুরো প্রক্রিয়া সাধারণত এত দ্রুত সম্পন্ন হয় যে ব্যবহারকারী আলাদাভাবে কিছু বুঝতে পারেন না। আধুনিক TLS 1.3 মানে Handshake, Server Authentication, Shared Key এবং Encrypted Application Data কীভাবে কাজ করে তা RFC 9846-এ নির্ধারিত হয়েছে।

স্মার্টফোন হ্যাক হওয়া থেকে বাঁচানোর ৭টি কার্যকর উপায়

Encryption ও Decryption কী?

Encryption হচ্ছে পাঠযোগ্য তথ্যকে নির্দিষ্ট Cryptographic Algorithm ও Key ব্যবহার করে এমন রূপে পরিবর্তন করা, যা অনুমোদিত Key ছাড়া অর্থপূর্ণভাবে পড়া কঠিন। মূল পাঠযোগ্য তথ্যকে Plaintext এবং রূপান্তরিত তথ্যকে Ciphertext বলা হয়।

Decryption হচ্ছে সঠিক Key ব্যবহার করে Ciphertext থেকে মূল তথ্য ফিরে পাওয়ার প্রক্রিয়া।

ধরা যাক, একজন ব্যবহারকারী কোনো Login Form-এ Username ও Password লিখে পাঠালেন। HTTPS চালু থাকলে Browser থেকে Server বা TLS শেষ হওয়ার অনুমোদিত Endpoint পর্যন্ত তথ্যটি Encrypt করা অবস্থায় যায়। মাঝখানের Wi-Fi পরিচালনাকারী, সাধারণ Network পর্যবেক্ষক বা অননুমোদিত ব্যক্তি সহজে সেই Password পড়তে পারে না।

তবে এটি বোঝাতে সাধারণ অক্ষর এক ধাপ আগে–পরে সরিয়ে দেওয়ার উদাহরণ যথেষ্ট নয়। আধুনিক TLS শক্তিশালী গাণিতিক পদ্ধতি, Key Exchange, Digital Signature, Authenticated Encryption এবং অখণ্ডতা যাচাইয়ের সমন্বয়ে কাজ করে। তাই সাধারণ বর্ণ বদলানোর কৌশলের সঙ্গে এর নিরাপত্তা তুলনা করা ঠিক হবে না।

HTTPS কোন তিনটি প্রধান নিরাপত্তা দেয়?

গোপনীয়তা

Browser ও Server-এর মধ্যে চলাচলকারী তথ্য Encrypt করা থাকে। ফলে মাঝপথে থাকা অননুমোদিত ব্যক্তি সাধারণভাবে Page-এর মূল লেখা, Password, Form Data, Cookie বা সম্পূর্ণ Request পড়তে পারে না।

তবে গন্তব্যের IP Address, সংযোগের সময়, তথ্যের আনুমানিক পরিমাণ এবং কিছু Network Metadata দৃশ্যমান থাকতে পারে। তাই HTTPS ব্যবহারকারীকে পুরোপুরি অজ্ঞাতপরিচয় করে না।

তথ্যের অখণ্ডতা

তথ্য চলাচলের সময় কেউ গোপনে Script, Page, ছবি বা Form-এর উত্তর পরিবর্তন করার চেষ্টা করলে নিরাপদ সংযোগ সেটি শনাক্ত করতে পারে। এর ফলে অনিরাপদ Wi-Fi বা মাঝপথের আক্রমণকারীর মাধ্যমে Page-এ ক্ষতিকর Code বা বিজ্ঞাপন ঢুকিয়ে দেওয়ার ঝুঁকি কমে।

Server-এর পরিচয় যাচাই

Certificate Browser-কে নির্দিষ্ট Domain-এর জন্য Server-এর পরিচয় যাচাই করতে সাহায্য করে। অর্থাৎ Browser নিশ্চিত হওয়ার চেষ্টা করে যে ব্যবহারকারী সত্যিই techtipsdesk.com-এর বৈধ Certificate উপস্থাপনকারী Endpoint-এর সঙ্গে যুক্ত হয়েছেন।

কিন্তু ব্যবহারকারী যদি ভুল বানানের অন্য Domain-এ যান, সেই ভিন্ন Domain-এরও নিজের বৈধ Certificate থাকতে পারে। তাই শুধু নিরাপত্তা চিহ্ন নয়, Address Bar-এর Domain-ও ভালোভাবে দেখতে হবে।

HTTPS কী কী সুরক্ষা দিতে পারে না?

HTTPS গুরুত্বপূর্ণ হলেও এটি ওয়েবসাইটের সম্পূর্ণ নিরাপত্তাব্যবস্থা নয়। এর সীমাবদ্ধতা না বুঝলে নিরাপত্তা চিহ্ন দেখে ভুল সিদ্ধান্ত নেওয়ার আশঙ্কা থাকে।

ক্ষতিকর ওয়েবসাইট থেকে নিশ্চয়তা দেয় না

একটি Phishing ওয়েবসাইট নিজের Domain-এর জন্য বৈধ Certificate নিতে পারে। সেই সাইটের সঙ্গে সংযোগ Encrypt করা থাকলেও ব্যবহারকারী সরাসরি প্রতারকের Server-এ তথ্য পাঠাচ্ছেন। তাই অচেনা Domain-এ Password, Card তথ্য বা পরিচয়পত্র দেওয়া উচিত নয়।

Server আক্রান্ত হওয়া ঠেকায় না

দুর্বল WordPress Plugin, পুরোনো Theme, অনুমানযোগ্য Password, ভুল File Permission বা নিরাপত্তা ত্রুটির কারণে Server আক্রান্ত হতে পারে। HTTPS এসব দুর্বলতা নিজে থেকে বন্ধ করে না।

ব্যবহারকারীর Device নিরাপদ করে না

কম্পিউটার বা ফোনে Malware, ক্ষতিকর Browser Extension অথবা Screen Recording ধরনের আক্রমণ থাকলে তথ্য Encrypt হওয়ার আগে কিংবা Decrypt হওয়ার পরে চুরি হতে পারে।

তথ্য সংরক্ষণের নিরাপত্তা নিশ্চিত করে না

HTTPS মূলত চলমান তথ্য বা Data In Transit রক্ষা করে। Server-এর Database-এ তথ্য কীভাবে সংরক্ষণ করা হচ্ছে, Backup সুরক্ষিত কি না এবং কারা তথ্য দেখতে পারে—এসব আলাদা বিষয়।

অনলাইন অনুসরণ পুরোপুরি বন্ধ করে না

ওয়েবসাইটের নিজস্ব Analytics, Cookies, Login Account এবং অনুমোদিত বিজ্ঞাপনসেবা ব্যবহারকারীর কার্যক্রম সম্পর্কে তথ্য সংগ্রহ করতে পারে। HTTPS Network-এর মাঝপথে তথ্য পড়া কঠিন করে, কিন্তু ওয়েবসাইটের নিজস্ব তথ্য সংগ্রহ বন্ধ করে না।

ওয়েবসাইটের HTTPS সংযোগ যাচাই করার উপায়

একসময় Address Bar-এর তালা চিহ্নকে নিরাপদ ওয়েবসাইটের প্রধান লক্ষণ হিসেবে ধরা হতো। আধুনিক Browser-এ চিহ্নের নকশা বদলেছে এবং সব Browser একই ধরনের চিহ্ন দেখায় না। কোথাও Site Controls চিহ্ন, কোথাও নিরাপত্তাসংক্রান্ত অন্য প্রতীক দেখা যেতে পারে।

Google Chrome-এ ওয়েব ঠিকানার পাশের Site Information চিহ্ন নির্বাচন করলে Connection Status, Cookies, Site Data এবং Permission-সংক্রান্ত তথ্য দেখা যায়। Google নিজেও সতর্ক করেছে—নিরাপদ সংযোগ থাকলেও ব্যক্তিগত তথ্য দেওয়ার আগে Address Bar-এর Domain ঠিক আছে কি না যাচাই করতে হবে। Google Chrome-এর নিরাপদ সংযোগ যাচাই নির্দেশনা থেকে বর্তমান চিহ্নগুলোর ব্যাখ্যা পাওয়া যায়।

কোনো ওয়েবসাইট যাচাইয়ের সময় নিচের বিষয়গুলো দেখুন:

1. Domain-এর বানান ঠিক আছে কি না;
2. সংযোগের ঠিকানা https:// দিয়ে শুরু হয়েছে কি না;
3. Browser কোনো Certificate বা Privacy সতর্কতা দেখাচ্ছে কি না;
4. Page-এর ভেতরে অস্বাভাবিক Login Form বা Download নির্দেশনা আছে কি না;
5. পরিচিত প্রতিষ্ঠানের নামে তৈরি নকল Domain কি না;
6. Browser Dangerous বা Not Secure সতর্কতা দিচ্ছে কি না।

অনেক Browser Address Bar-এ https:// অংশ লুকিয়ে রাখতে পারে। সে ক্ষেত্রে Site Information চিহ্ন নির্বাচন করে সংযোগের অবস্থা দেখা যায়।

Password পাঠানোর পর কী ঘটে?

ব্যবহারকারী Login Form পূরণ করলে HTTPS সেই তথ্য Browser থেকে Server পর্যন্ত চলাচলের সময় সুরক্ষিত করে। কিন্তু Server-এ পৌঁছানোর পর Password কীভাবে যাচাই করা হবে, সেটি Website Application-এর দায়িত্ব।

নিরাপদ ব্যবস্থায় ব্যবহারকারীর Password সাধারণ লেখা হিসেবে Database-এ রাখা উচিত নয়। আবার এমনভাবে Encrypt করে রাখাও আদর্শ নয়, যেখান থেকে সহজে মূল Password ফিরিয়ে আনা যায়।

Password সাধারণত নিরাপদ, একমুখী Password Hash হিসেবে সংরক্ষণ করা উচিত। ব্যবহারকারী Login করার সময় দেওয়া Password একই অনুমোদিত Hashing প্রক্রিয়ার মধ্য দিয়ে যায়। নতুন ফলাফল সংরক্ষিত Hash-এর সঙ্গে মিললে Login অনুমোদন করা হয়।

OWASP আধুনিক ও ধীরগতির Password Hashing ব্যবস্থা ব্যবহারের পরামর্শ দেয় এবং সাধারণ লেখা বা ফেরতযোগ্য Encryption হিসেবে Password সংরক্ষণ না করতে বলে। তাদের Password Storage নির্দেশনা অনুযায়ী যথাযথ Salt-সহ উপযুক্ত Hashing ব্যবস্থা ব্যবহার করা জরুরি।

অর্থাৎ HTTPS এবং Password Hashing একে অন্যের বিকল্প নয়। প্রথমটি চলমান Password রক্ষা করে, দ্বিতীয়টি Server-এ সংরক্ষিত Password নিরাপদ রাখতে সাহায্য করে।

কোন ধরনের ওয়েবসাইটে HTTPS প্রয়োজন?

বর্তমান ওয়েবে প্রায় সব ধরনের প্রকাশ্য ওয়েবসাইটে HTTPS প্রয়োজন। শুধু অনেক ব্যবহারকারীর Account আছে এমন সাইটের জন্য এটি সীমাবদ্ধ নয়।

বিশেষভাবে প্রয়োজনীয় ক্ষেত্রগুলো হলো:

• E-commerce ও Online Payment Website;
• Banking ও Financial Service;
• Social Media ও Community Website;
• Login ও Registration সুবিধাসম্পন্ন Website;
• News Portal ও Blog;
• ব্যক্তিগত ও Professional Portfolio;
• Business ও প্রতিষ্ঠানের Website;
• সরকারি ও শিক্ষাপ্রতিষ্ঠানের Website;
• স্বাস্থ্য ও ব্যক্তিগত তথ্যভিত্তিক Website;
• Form বা Newsletter থাকা Website;
• Software বা File Download Website।

সাধারণ Blog-এ Login Form না থাকলেও HTTPS প্রয়োজন। কারণ অনিরাপদ সংযোগে Page, Script, বিজ্ঞাপন বা Download Link পরিবর্তনের ঝুঁকি থাকতে পারে। এছাড়া অনেক আধুনিক Browser সুবিধা শুধু নিরাপদ সংযোগে কাজ করে।

SSL/TLS Certificate কি অবশ্যই কিনতে হয়?

না, Certificate ব্যবহারের জন্য সবসময় আলাদাভাবে অর্থ দিতে হয় না। অনেক Hosting Package-এ বিনা মূল্যের Certificate, AutoSSL অথবা Let’s Encrypt সুবিধা থাকে। কিছু CDN সেবাও ব্যবহারকারীর Browser-এর সঙ্গে নিরাপদ সংযোগের Certificate পরিচালনা করে।

বিনা মূল্যের Certificate খারাপ এবং অর্থ দিয়ে কেনা Certificate সবসময় বেশি শক্তিশালী—এমন ধারণাও ঠিক নয়। উভয় ক্ষেত্রেই আধুনিক ও সঠিকভাবে কনফিগার করা TLS ব্যবহার করা সম্ভব।

অর্থমূল্যের পার্থক্য তৈরি হতে পারে প্রতিষ্ঠান যাচাইয়ের স্তর, গ্রাহক সহায়তা, Certificate পরিচালনা, Warranty, একাধিক Domain সুবিধা এবং ব্যবসায়িক প্রয়োজনের কারণে। শুধু বেশি দাম দিলেই Encryption স্বয়ংক্রিয়ভাবে বেশি শক্তিশালী হয়ে যায় না।

ছোট Blog, ব্যক্তিগত Website এবং অনেক সাধারণ Business Website-এর জন্য Hosting-এ থাকা স্বয়ংক্রিয় বিনা মূল্যের Certificate যথেষ্ট হতে পারে। বড় প্রতিষ্ঠানকে তাদের নিজস্ব নিরাপত্তা নীতি, অবকাঠামো ও পরিচয় যাচাইয়ের প্রয়োজন অনুযায়ী Certificate নির্বাচন করতে হয়।

ওয়েবসাইটে HTTPS চালু করার সাধারণ ধাপ

Hosting প্রতিষ্ঠান ও Server অনুযায়ী পদ্ধতি কিছুটা ভিন্ন হতে পারে। তবে সাধারণভাবে নিচের কাজগুলো করতে হয়।

Domain সঠিকভাবে Server-এ যুক্ত করা

Domain-এর DNS Record সঠিক Server, Hosting বা CDN-এর দিকে নির্দেশ করতে হবে। Domain অন্য জায়গায় নির্দেশ করলে Certificate যাচাই ব্যর্থ হতে পারে।

Certificate সংগ্রহ করা

Hosting Panel-এর SSL/TLS, Security, AutoSSL বা Let’s Encrypt অংশ থেকে Certificate চালু করা যায়। নিজস্ব Server হলে অনুমোদিত ACME Client ব্যবহার করে Certificate সংগ্রহ ও নবায়ন স্বয়ংক্রিয় করা যেতে পারে।

Domain Control যাচাই করা

Certificate Authority DNS Record, নির্দিষ্ট HTTP File অথবা অনুমোদিত অন্য পদ্ধতিতে Domain-এর নিয়ন্ত্রণ যাচাই করে। যাচাই সফল হলে Certificate প্রদান করা হয়।

Certificate ও Private Key স্থাপন করা

Certificate, প্রয়োজনীয় Intermediate Certificate এবং সংশ্লিষ্ট Private Key Server-এ সঠিকভাবে স্থাপন করতে হয়। Managed Hosting-এ এই কাজ সাধারণত স্বয়ংক্রিয়ভাবে সম্পন্ন হয়।

HTTP থেকে HTTPS Redirect করা

পুরোনো http:// ঠিকানায় কেউ প্রবেশ করলে তাকে স্থায়ীভাবে https:// ঠিকানায় পাঠানো উচিত। সাধারণত 301 Redirect ব্যবহার করা হয়।

সব অভ্যন্তরীণ Link হালনাগাদ করা

Menu, ছবি, Script, Stylesheet, Canonical URL এবং অন্য অভ্যন্তরীণ ঠিকানায় পুরোনো http:// Link থাকলে সেগুলো সংশোধন করতে হবে।

Certificate নবায়ন স্বয়ংক্রিয় করা

Certificate-এর মেয়াদ শেষ হওয়ার আগেই নবায়ন করতে হয়। স্বয়ংক্রিয় নবায়ন চালু থাকলেও নিয়মিত পরীক্ষা করা ভালো। ভুল DNS, Server পরিবর্তন বা বন্ধ হয়ে থাকা Validation পদ্ধতির কারণে নবায়ন ব্যর্থ হতে পারে।

বাংলাদেশে অ্যাফিলিয়েট মার্কেটিং শুরু করার ধাপে ধাপে পূর্ণাঙ্গ গাইড

WordPress ওয়েবসাইটে HTTPS চালুর পর যা যাচাই করবেন

WordPress Website-এ Certificate সক্রিয় করেই কাজ শেষ করা উচিত নয়। পুরো Website সঠিকভাবে HTTPS ব্যবহার করছে কি না তা পরীক্ষা করতে হবে।

প্রথমে Website-এর পূর্ণ Backup রাখা উচিত। এরপর Hosting Panel থেকে Certificate চালু করে WordPress Address ও Site Address-এ সঠিক https:// URL আছে কি না দেখতে হবে।

পুরোনো Content-এর ভেতরে http:// দিয়ে শুরু হওয়া Image বা Internal Link থাকতে পারে। প্রয়োজন হলে নিরাপদ Backup নিয়ে উপযুক্ত Search and Replace ব্যবস্থা ব্যবহার করা যায়। তবে সরাসরি Database পরিবর্তনের আগে অবশ্যই Backup নিতে হবে।

এরপর নিচের বিষয়গুলো যাচাই করুন:

• Home Page এবং গুরুত্বপূর্ণ Post HTTPS-এ খুলছে কি না;
• http:// ঠিকানা স্বয়ংক্রিয়ভাবে HTTPS-এ যাচ্ছে কি না;
• Browser Console-এ Mixed Content Error আছে কি না;
• Logo, Font, Image, Script ও Stylesheet ঠিকভাবে লোড হচ্ছে কি না;
• Canonical URL-এ HTTPS ব্যবহার হয়েছে কি না;
• Sitemap-এর সব URL HTTPS কি না;
• robots.txt Googlebot-এর প্রয়োজনীয় Page Crawl করতে বাধা দিচ্ছে কি না এবং HTTP থেকে HTTPS Redirect সঠিকভাবে কাজ করছে কি না;
• Cache ও CDN পুরোনো HTTP সংস্করণ দেখাচ্ছে কি না;
• Login, Form ও Comment ব্যবস্থা ঠিকভাবে কাজ করছে কি না;
• Certificate-এর মেয়াদ ও Domain Coverage ঠিক আছে কি না।

Website-এর www ও www ছাড়া উভয় সংস্করণ ব্যবহার করা হলে কোনটি প্রধান Domain হবে তা নির্ধারণ করতে হবে। প্রধান নয় এমন সংস্করণকে সঠিক HTTPS ঠিকানায় Redirect করা উচিত।

Mixed Content কী?

মূল Page HTTPS দিয়ে খোলার পরও যদি কোনো Image, Script, Font, Video বা Stylesheet HTTP দিয়ে আনা হয়, তাহলে সেটিকে Mixed Content বলা হয়।

উদাহরণ হিসেবে Page যদি নিচের নিরাপদ ঠিকানায় খোলে—

https://techtipsdesk.com/example-page/

কিন্তু সেই Page-এর একটি ছবি যদি নিচের অনিরাপদ ঠিকানা থেকে আসে—

http://techtipsdesk.com/example-image.jpg

তাহলে Page-এ Mixed Content তৈরি হতে পারে।

এটি শুধু Browser-এর সতর্কবার্তার বিষয় নয়। অনিরাপদ Script পরিবর্তন করা গেলে পুরো Page-এর আচরণ প্রভাবিত হতে পারে। ছবি বা অন্য উপাদান বদলে ব্যবহারকারীকে বিভ্রান্ত করাও সম্ভব। আধুনিক Browser অনেক ধরনের Mixed Content নিজে থেকে HTTPS-এ উন্নীত করে অথবা পুরোপুরি আটকে দেয়। Google-এর Mixed Content ব্যাখ্যা অনুযায়ী Page-এর সব উপাদান নিরাপদ ঠিকানা থেকে লোড করা উচিত।

HSTS কী এবং কখন ব্যবহার করা উচিত?

HSTS বা HTTP Strict Transport Security হচ্ছে একটি নিরাপত্তা নির্দেশনা, যা Browser-কে জানায় সংশ্লিষ্ট Domain ভবিষ্যতে শুধু HTTPS-এর মাধ্যমে খুলতে হবে।

কেউ ভুল করে http://techtipsdesk.com লিখলেও Browser আগে পাওয়া বৈধ HSTS নির্দেশনা মনে রাখলে সরাসরি HTTPS ব্যবহার করতে পারে। এটি প্রাথমিক HTTP সংযোগ আটকে দেওয়ার কিছু আক্রমণ কমাতে সাহায্য করে।

তবে HTTPS পুরোপুরি সঠিকভাবে চালু করার আগে তাড়াহুড়া করে দীর্ঘমেয়াদি HSTS চালু করা উচিত নয়। ভুল Certificate, অনিরাপদ Subdomain বা Server সমস্যার কারণে Website ব্যবহারকারীদের জন্য বন্ধ হয়ে যেতে পারে। আগে মূল Domain ও প্রয়োজনীয় Subdomain-এ HTTPS স্থিতিশীল করতে হবে। এরপর পরীক্ষিত নীতি অনুযায়ী HSTS চালু করা যায়। MDN-এর HSTS নির্দেশনা এ বিষয়ে প্রয়োজনীয় প্রযুক্তিগত তথ্য দেয়।

CDN ব্যবহার করলে HTTPS কীভাবে কাজ করে?

Website-এ CDN বা Reverse Proxy থাকলে সংযোগের পথ একাধিক অংশে ভাগ হতে পারে:

1. ব্যবহারকারীর Browser থেকে CDN-এর Server;
2. CDN-এর Server থেকে মূল Hosting বা Origin Server।

শুধু Browser ও CDN-এর মধ্যকার অংশ Encrypt থাকলেই পুরো ব্যবস্থা আদর্শভাবে সুরক্ষিত হয় না। CDN থেকে Origin Server পর্যন্ত সংযোগেও বৈধ TLS ব্যবহার করা উচিত। Origin-এর Certificate যাচাই না করে এমন দুর্বল পদ্ধতি ব্যবহার করলে মাঝের অংশে নিরাপত্তার ফাঁক থেকে যেতে পারে।

তাই CDN-এর নিরাপত্তা সেটিং নির্বাচন করার সময় Browser থেকে CDN এবং CDN থেকে Origin—দুই দিকের Certificate ও Encryption যাচাই করতে হবে।

Certificate Error দেখানোর সাধারণ কারণ

Browser Certificate-সংক্রান্ত সতর্কতা দেখালে সেটি উপেক্ষা করে ব্যক্তিগত তথ্য দেওয়া উচিত নয়। Error হওয়ার সাধারণ কারণগুলো হলো:

• Certificate-এর মেয়াদ শেষ হয়ে গেছে;
• Certificate এখনো কার্যকর হওয়ার সময় আসেনি;
• খোলা Domain Certificate-এর অন্তর্ভুক্ত নয়;
• Intermediate Certificate ঠিকভাবে স্থাপন করা হয়নি;
• Certificate বিশ্বস্ত Authority থেকে আসেনি;
• Device-এর Date ও Time ভুল;
• Server ভুল Certificate পাঠাচ্ছে;
• CDN ও Origin-এর Certificate সেটিং অসামঞ্জস্যপূর্ণ;
• Antivirus বা Network নিরাপদ সংযোগ পরীক্ষা করতে গিয়ে সমস্যা করছে;
• Private Key ও Certificate একে অন্যের সঙ্গে মিলছে না।

Website মালিককে Error-এর প্রকৃত কারণ নির্ণয় করতে হবে। শুধু Browser-এর সতর্কতা লুকানো বা ব্যবহারকারীকে Error উপেক্ষা করতে বলা নিরাপদ সমাধান নয়।

HTTPS চালু করলেই কি ওয়েবসাইট হ্যাকমুক্ত হবে?

না। HTTPS ওয়েবসাইট নিরাপত্তার একটি প্রয়োজনীয় স্তর, কিন্তু এটি একমাত্র স্তর নয়।

ওয়েবসাইট সুরক্ষিত রাখতে আরও যেসব ব্যবস্থা দরকার:

• WordPress, Plugin ও Theme নিয়মিত হালনাগাদ রাখা;
• শক্তিশালী ও আলাদা Password ব্যবহার করা;
• প্রশাসনিক Account-এ Two-Factor Authentication চালু করা;
• অপ্রয়োজনীয় Plugin ও Account সরিয়ে ফেলা;
• নিয়মিত ও পরীক্ষিত Backup রাখা;
• File Permission সঠিক রাখা;
• Login Attempt ও সন্দেহজনক কার্যক্রম পর্যবেক্ষণ করা;
• Server ও Database-এর প্রবেশাধিকার সীমিত রাখা;
• নিরাপদ Cookie ও প্রয়োজনীয় Security Header ব্যবহার করা;
• Form ও User Input যাচাই করা;
• Malware Scan এবং নিরাপত্তা পর্যবেক্ষণ চালু রাখা;
• CDN বা Firewall ব্যবহার করলে সঠিকভাবে কনফিগার করা।

Certificate থাকলেও দুর্বল Plugin-এর ত্রুটি কাজে লাগিয়ে Website আক্রান্ত হতে পারে। আবার Website নিরাপদ হলেও ব্যবহারকারীর Password অন্য জায়গা থেকে চুরি হলে Account ঝুঁকিতে পড়তে পারে। তাই নিরাপত্তাকে একটি চলমান প্রক্রিয়া হিসেবে দেখা দরকার।

শেষ কথা

HTTPS আধুনিক ওয়েবসাইটের জন্য ঐচ্ছিক সাজসজ্জা নয়; এটি Browser ও Server-এর মধ্যে বিশ্বাসযোগ্য ও সুরক্ষিত যোগাযোগ তৈরির মৌলিক ব্যবস্থা। SSL/TLS Certificate Domain-এর সঙ্গে Server-এর Cryptographic পরিচয় যুক্ত করে এবং TLS Handshake নিরাপদ Session Key তৈরির পথ প্রস্তুত করে।

তবে Address Bar-এর নিরাপত্তা চিহ্নকে ওয়েবসাইটের সামগ্রিক সততার নিশ্চয়তা ভাবা ঠিক নয়। ব্যবহারকারীকে Domain যাচাই করতে হবে, আর Website মালিককে Certificate-এর পাশাপাশি Software Update, Password নিরাপত্তা, Backup, Server Configuration ও নিয়মিত পর্যবেক্ষণ বজায় রাখতে হবে। এই পৃথক ব্যবস্থাগুলো একসঙ্গে কাজ করলেই একটি ওয়েবসাইট ও তার ব্যবহারকারীদের জন্য বাস্তবসম্মত নিরাপত্তা গড়ে ওঠে।

FAQ

০১। HTTPS-এর পূর্ণরূপ কী?

HTTPS-এর প্রচলিত পূর্ণরূপ Hypertext Transfer Protocol Secure। প্রযুক্তিগতভাবে এটি TLS দিয়ে সুরক্ষিত HTTP যোগাযোগ।

০২। SSL ও TLS-এর মধ্যে পার্থক্য কী?

SSL নিরাপদ Network যোগাযোগের পুরোনো প্রযুক্তি। এর উন্নত ও বর্তমান উত্তরসূরি হচ্ছে TLS। “SSL Certificate” নামটি প্রচলিত থাকলেও আধুনিক ওয়েবসাইটে মূলত TLS ব্যবহৃত হয়।

০৩। HTTPS থাকলে কি ওয়েবসাইট সম্পূর্ণ নিরাপদ?

না। HTTPS শুধু Browser ও Server-এর মধ্যকার যোগাযোগ সুরক্ষিত করে। Phishing, Malware, দুর্বল Plugin, চুরি হওয়া Password বা Server আক্রমণ থেকে সম্পূর্ণ সুরক্ষা দেয় না।

০৪। বিনা মূল্যের SSL/TLS Certificate কি নিরাপদ?

বিশ্বস্ত Certificate Authority থেকে নেওয়া এবং সঠিকভাবে কনফিগার করা বিনা মূল্যের Certificate নিরাপদ TLS সংযোগ দিতে পারে। Let’s Encrypt এ ধরনের বহুল ব্যবহৃত বিনা মূল্যের Certificate প্রদান করে।

ক্লাউড স্টোরেজ: কোন সেবাটি আপনার প্রয়োজনের জন্য সবচেয়ে উপযুক্ত

০৫। Certificate-এর মেয়াদ শেষ হলে কী হবে?

মেয়াদ শেষ হলে Browser নিরাপত্তা সতর্কতা দেখাতে পারে এবং ব্যবহারকারীরা Website খুলতে সমস্যায় পড়তে পারেন। তাই সময়মতো স্বয়ংক্রিয় বা হাতে Certificate নবায়ন করতে হবে।

০৬। Mixed Content কেন ক্ষতিকর?

HTTPS Page-এর কোনো ছবি, Script বা অন্য উপাদান HTTP দিয়ে লোড হলে সেই অংশ Encrypt থাকে না। আক্রমণকারী সেটি দেখতে বা পরিবর্তন করতে পারে এবং Browser উপাদানটি আটকে দিতে পারে।

০৭। HTTPS কি Password নিরাপদে সংরক্ষণ করে?

না। HTTPS Password চলাচলের সময় রক্ষা করে। Server-এ Password নিরাপদে সংরক্ষণের জন্য আধুনিক Password Hashing ও যথাযথ Salt ব্যবহার করতে হয়।

০৮। Browser-এ তালা চিহ্ন না থাকলে কি HTTPS নেই?

সবসময় নয়। আধুনিক Browser-এ তালার পরিবর্তে Site Controls বা অন্য নিরাপত্তা চিহ্ন থাকতে পারে। Address Bar-এর পাশের Site Information চিহ্ন নির্বাচন করে Connection Status দেখা উচিত।