ইন্টারনেট নামক টিউবের বিশাল সিরিজের মাধ্যমে যে পরিমাণ ব্যক্তিগত ডেটা আদানপ্রদান করা হয়, তা বিবেচনা করে এনক্রিপশনকে আমরা হালকাভাবে উপেক্ষা করতে পারি না বা করা উচিত নয়। ট্রানজিটে আপনার ব্যবহারকারীর ডেটা সুরক্ষিত আছে কিনা তা নিশ্চিত করতে আধুনিক ব্রাউজারগুলি বেশ কয়েকটি মেকানিজম অফার করে: সুরক্ষিত কুকি এবং স্ট্রিক্ট ট্রান্সপোর্ট সিকিউরিটি হল সবচেয়ে গুরুত্বপূর্ণ দুটি মেকানিজম। এগুলি আপনাকে নির্বিঘ্নে আপনার ব্যবহারকারীদের রক্ষা করতে, তাদের কানেকশন HTTPS-এ আপগ্রেড করতে এবং ব্যবহারকারীর ডেটা কখনই স্পষ্টভাবে পাঠানো হয় না তার গ্যারান্টি প্রদান করতে দেয়।
আপনি কেন যত্ন নেবেন? এটি বিবেচনা করুন:
এনক্রিপ্ট না করা HTTP কানেকশনের মাধ্যমে ওয়েব পেজ ডেলিভার করা অনেকটা রাস্তায় প্রথম যে ব্যক্তিকে পোস্ট অফিসের দিকে যেতে দেখছেন তার হাতে সিল না করা খাম তুলে দেওয়ার মতো। আপনি ভাগ্যবান হলে, তিনি নিজেই এটি সেখানে নিয়ে যেতে পারেন অথবা তিনি সঠিক পথে যাচ্ছেন এমন কোনও ব্যক্তিকে এটি দিয়ে দিতে পারেন। সেই ব্যক্তিও একই কাজ করতে পারেন এবং এইভাবে চলতে থাকবে।
এই তাৎক্ষণিক চেনের বেশিরভাগ অপরিচিত ব্যক্তিই বিশ্বস্ত এবং তারা কখনই আপনার খোলা চিঠি উঁকি দিয়ে দেখবে না বা পরিবর্তন করবে না। তবে, যত বেশিবার চিঠিটি হাতবদল হবে, তত বেশি সংখ্যক লোক আপনার পাঠানো চিঠিতে সম্পূর্ণ অ্যাক্সেস পাবেন। শেষ পর্যন্ত, আপনার চিঠির প্রাপক চিঠিতে কিছু পাবেন, তবে সেই কিছুটি আপনি প্রথমে যে কিছু দিয়েছিলেন তার সাথে মিলবে কিনা তা নিয়ে প্রশ্ন থেকে যায়। হয়ত তোমার খামটা সিল করা উচিত ছিল…
দালাল
ভালো হোক বা খারাপ, ইন্টারনেটের বিশাল অংশ অপরিচিতদের বিশ্বাসযোগ্যতার উপর নির্ভর করে। সার্ভারগুলি একে অপরের সাথে সরাসরি কানেক্ট করা থাকে না, তবে টেলিফোনের একটি বিশাল গেমে রাউটার থেকে রাউটারে অনুরোধ এবং উত্তর পাস করে।
আপনি traceroute-এর মাধ্যমে এইসব হপ অ্যাকশনে দেখতে পারবেন। আমার কম্পিউটার থেকে HTML5Rocks-এ যাওয়ার রুট কিছুটা এইরকম দেখতে:
$ traceroute html5rocks.com
traceroute to html5rocks.com (173.194.71.102), 30 hops max, 60 byte packets
1 router1-lon.linode.com (212.111.33.229) 0.453 ms
2 212.111.33.233 (212.111.33.233) 1.067 ms
3 217.20.44.194 (217.20.44.194) 0.704 ms
4 google1.lonap.net (193.203.5.136) 0.804 ms
5 209.85.255.76 (209.85.255.76) 0.925 ms
6 209.85.253.94 (209.85.253.94) 1.226 ms
7 209.85.240.28 (209.85.240.28) 48.714 ms
8 216.239.47.12 (216.239.47.12) 22.575 ms
9 209.85.241.193 (209.85.241.193) 36.033 ms
10 72.14.233.180 (72.14.233.180) 43.222 ms
11 72.14.233.170 (72.14.233.170) 43.242 ms
12 *
13 lb-in-f102.1e100.net (173.194.71.102) 44.523 ms
১৩ বার লাফানো খারাপ নয়, সত্যি। তবে, আমি যদি HTTP-এর মাধ্যমে অনুরোধ পাঠাই, তাহলে সেইসব ইন্টারমিডিয়েট রাউটারের প্রতিটি আমার অনুরোধ এবং সার্ভারের উত্তরে সম্পূর্ণ অ্যাক্সেস পায়। সব ডেটা আনএনক্রিপ্টেড প্লেইনটেক্সট হিসেবে ট্রান্সফার করা হচ্ছে, এবং এইসব মধ্যস্থতাকারীদের মধ্যে যেকোনও একটি ম্যান ইন দ্য মিডল হিসেবে কাজ করতে পারে, আমার ডেটা পড়তে পারে, এমনকি ট্রানজিটের সময় সেটি ম্যানিপুলেটও করতে পারে।
আরও খারাপ হল, এই ধরনের ইন্টারসেপশন কার্যত শনাক্ত করা যায় না। ক্ষতিকরভাবে পরিবর্তিত HTTP রেসপন্স দেখতে একদম সঠিক রেসপন্সের মতোই হয়, কারণ এমন কোনও মেকানিজম নেই যা আপনাকে নিশ্চিত করতে সাহায্য করবে যে আপনি যে ডেটা পেয়েছেন তা পাঠানো ডেটার _একদম _অনুরূপ। কেউ যদি মজা করার জন্য আমার ইন্টারনেট উলটপালট করে দেওয়ার সিদ্ধান্ত নেয়, তাহলে আমার কপাল খারাপ।
এটি কি একটি নিরাপদ লাইন?
প্লেনটেক্সট HTTP থেকে সুরক্ষিত HTTPS কানেকশনে পরিবর্তন করলে, তা মধ্যস্থতাকারীদের বিরুদ্ধে সবচেয়ে ভালো সুরক্ষা প্রদান করে। HTTPS কানেকশন কোনও ডেটা পাঠানোর আগে সম্পূর্ণ চ্যানেলটি এন্ড-টু-এন্ড এনক্রিপ্ট করে, যার ফলে আপনার এবং আপনার গন্তব্যের মধ্যে থাকা মেশিনের পক্ষে ট্রানজিটে ডেটা পড়া বা পরিবর্তন করা অসম্ভব হয়ে পড়ে।
HTTPS যে নিরাপত্তা প্রদান করে তা সর্বজনীন ও ব্যক্তিগত ক্রিপ্টোগ্রাফিক কী-এর ধারণার উপর ভিত্তি করে তৈরি। এই নিবন্ধের পরিধি থেকে (সৌভাগ্যবশত) এই বিবরণের গভীর আলোচনা অনেক দূরে, তবে মূল ভিত্তিটি বেশ সহজ: প্রদত্ত সর্বজনীন কী দিয়ে এনক্রিপ্ট করা ডেটা শুধুমাত্র সংশ্লিষ্ট ব্যক্তিগত কী দিয়ে ডিক্রিপ্ট করা যেতে পারে। একটি সুরক্ষিত চ্যানেল তৈরি করার জন্য যখন কোনও ব্রাউজার HTTPS হ্যান্ডশেক শুরু করে, তখন সার্ভার একটি সার্টিফিকেট প্রদান করে যা ব্রাউজারকে সার্ভারের পরিচয় যাচাই করার জন্য প্রয়োজনীয় সমস্ত তথ্য দেয়। সার্ভারের কাছে সঠিক ব্যক্তিগত কী আছে কিনা তা পরীক্ষা করে এই যাচাইকরণ করা হয়। সেই সময় থেকে সমস্ত যোগাযোগ এমনভাবে এনক্রিপ্ট করা হয় যা প্রমাণ করে যে অনুরোধগুলি যাচাইকরণ সার্ভারে পৌঁছেছে এবং সেখান থেকে উত্তর পাওয়া গেছে।
তাই, HTTPS আপনাকে এই বিষয়ে আশ্বস্ত করে যে আপনি যে সার্ভারের সাথে কথা বলছেন বলে ভাবছেন, আসলে সেই সার্ভারের সাথেই কথা বলছেন এবং অন্য কেউ আপনার কথা শুনছে না বা আপনার ডেটা চুরি করছে না। এই ধরনের এনক্রিপশন হল ওয়েবে নিরাপত্তার জন্য একটি পরম পূর্বশর্ত; আপনার অ্যাপ্লিকেশন বর্তমানে HTTPS-এর মাধ্যমে ডেলিভার না হলে, এটি আক্রমণের জন্য ঝুঁকিপূর্ণ। ঠিক করুন। Ars Technica-এর কাছে সার্টিফিকেট পাওয়া এবং ইনস্টল করার (ফ্রিতে) দারুণ নির্দেশিকা আছে যা আমি আপনাকে টেকনিক্যাল বিবরণের জন্য দেখার সাজেশন দেব। কনফিগারেশন পরিষেবা প্রদানকারী ও সার্ভার অনুযায়ী আলাদা হবে, তবে সার্টিফিকেট অনুরোধ করার প্রসেস সব জায়গাতেই এক।
ডিফল্ট হিসেবে নিরাপদ
সার্টিফিকেট অনুরোধ ও ইনস্টল করার পরে, আপনার পরিশ্রমের ফল যাতে ব্যবহারকারীরা পান তা নিশ্চিত করুন: HTTP রিডাইরেকশনের ম্যাজিকের মাধ্যমে আপনার বর্তমান ব্যবহারকারীদের HTTPS কানেকশনে স্বচ্ছভাবে মাইগ্রেট করুন এবং কুকি যাতে শুধুমাত্র সুরক্ষিত কানেকশনের মাধ্যমে ডেলিভার করা হয় তা নিশ্চিত করুন।
এই দিকে আসুন
কোনও ব্যবহারকারী http://example.com/-এ গেলে, তাকে https://example.com/-এ রিডাইরেক্ট করুন। এর জন্য উপযুক্ত Location হেডার সহ 301 Moved
Permanently রেসপন্স পাঠান:
$ curl -I http://mkw.st/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.3.7
...
Keep-Alive: timeout=20
Location: https://mkw.st/
আপনি Apache বা Nginx-এর মতো সার্ভারে এই ধরনের রিডাইরেকশন সহজেই সেট-আপ করতে পারবেন।
যেমন, Nginx কনফিগারেশন যা http://example.com/
থেকে https://example.com/-এ রিডাইরেক্ট করে, সেটি এইরকম দেখতে হয়:
server {
listen [YOUR IP ADDRESS HERE]:80;
server_name example.com www.example.com;
location "/" {
rewrite ^(.*) https://www.example.com$1 permanent;
}
}
কুকি জার লক করুন
স্টেটলেস HTTP প্রোটোকলের মাধ্যমে ব্যবহারকারীদের বাধাহীন লগ-ইন অভিজ্ঞতা প্রদান করার ক্ষমতা কুকি আমাদের দেয়। সেশন আইডির মতো সংবেদনশীল তথ্য সহ কুকিতে স্টোর করা ডেটা প্রতিটি অনুরোধের সাথে পাঠানো হয়, যা সার্ভারকে বুঝতে সাহায্য করে যে এটি এই মুহূর্তে কোন ব্যবহারকারীকে উত্তর দিচ্ছে। ব্যবহারকারীরা HTTPS-এর মাধ্যমে আমাদের সাইট অ্যাক্সেস করছেন কিনা তা নিশ্চিত করার পরে, আমাদের এটিও নিশ্চিত করতে হবে যে কুকিতে স্টোর করা সংবেদনশীল ডেটা শুধুমাত্র সুরক্ষিত কানেকশনের মাধ্যমে ট্রান্সফার করা হচ্ছে এবং কখনও স্পষ্ট টেক্সট হিসেবে পাঠানো হচ্ছে না।
কুকি সেট করার সময় সাধারণত একটি HTTP হেডার থাকে যা দেখতে অনেকটা এইরকম:
set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT
আপনি ব্রাউজারকে নির্দেশ দিতে পারেন যাতে কুকির ব্যবহার সুরক্ষিত সেশনে সীমাবদ্ধ থাকে, এর জন্য একটি কীওয়ার্ড যোগ করতে হবে:
Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT; secure
secure কীওয়ার্ড দিয়ে সেট করা কুকি HTTP-এর মাধ্যমে কখনও পাঠানো হবে না।
খোলা উইন্ডো বন্ধ করা হচ্ছে
HTTPS-এ স্বচ্ছ রিডাইরেকশনের অর্থ হল, আপনার ব্যবহারকারীরা বেশিরভাগ সময় আপনার সাইটে থাকলে, তারা একটি নিরাপদ কানেকশন ব্যবহার করবেন। তবে, এটি অ্যাটাকের জন্য একটি ছোট সুযোগ রেখে দেয়: প্রাথমিক HTTP কানেকশন খোলা থাকে, যা SSL স্ট্রিপিং এবং এই ধরনের অ্যাটাকের জন্য অসুরক্ষিত। প্রাথমিক HTTP অনুরোধে ম্যান-ইন-দ্য-মিডলের সম্পূর্ণ অ্যাক্সেস থাকার কারণে, এটি আপনার এবং সার্ভারের মধ্যে প্রক্সি হিসেবে কাজ করতে পারে, সার্ভারের উদ্দেশ্য যাই হোক না কেন, আপনাকে একটি অসুরক্ষিত HTTP কানেকশনে রাখে।
ব্রাউজারকে HTTP স্ট্রিক্ট ট্রান্সপোর্ট সিকিউরিটি
(HSTS) এনফোর্স করতে বলে আপনি এই ধরনের অ্যাটাকের ঝুঁকি কমাতে পারেন। Strict-Transport-Security HTTP হেডার পাঠালে, ব্রাউজারকে HTTP থেকে HTTPS-এ রিডাইরেক্ট করার নির্দেশ দেওয়া হয়,
ক্লায়েন্ট-সাইড, নেটওয়ার্ক স্পর্শ না করেই (এটি পারফর্ম্যান্সের জন্যও
দারুণ; সবচেয়ে ভালো অনুরোধ হল সেটি যেটি আপনাকে করতে হয় না):
$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000
যেসব ব্রাউজার এই হেডারকে সমর্থন করে (বর্তমানে Firefox, Chrome এবং Opera: caniuse-এ বিস্তারিত তথ্য আছে) সেগুলি নোট করবে যে এই নির্দিষ্ট সাইটটি শুধুমাত্র HTTPS অ্যাক্সেসের জন্য অনুরোধ করেছে, যার অর্থ হল ব্যবহারকারী যেভাবে সাইটে আসুক না কেন, তিনি HTTPS-এর মাধ্যমে ভিজিট করবেন। এমনকি সে ব্রাউজারে http://example.com/ টাইপ করলেও, HTTP কানেকশন তৈরি না করেই HTTPS-এ পৌঁছে যাবে। আরও ভাল হয়, যদি ব্রাউজার কোনও ভুল সার্টিফিকেট শনাক্ত করে (সম্ভবত আপনার সার্ভারের পরিচয় স্পুফ করার চেষ্টা করছে), ব্যবহারকারীদের HTTP-এর মাধ্যমে চালিয়ে যাওয়ার অনুমতি দেওয়া হবে না; হয় সব, নয় কিছুই নয়, যা খুবই ভাল।
ব্রাউজার max-age সেকেন্ড পরে সার্ভারের HSTS স্ট্যাটাসের মেয়াদ শেষ করে দেবে
(এই উদাহরণে প্রায় এক মাস); এটি যুক্তিসঙ্গতভাবে বেশি কিছুতে সেট করুন।
এছাড়াও, আপনি হেডার-এ includeSubDomains নির্দেশিকা যোগ করে নিশ্চিত করতে পারেন যে কোনও অরিজিনের সব সাবডোমেন সুরক্ষিত আছে:
$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000
নিরাপদে এগিয়ে যান
আপনার পাঠানো ডেটা যে প্রাপকের কাছে অক্ষত অবস্থায় পৌঁছেছে তা নিশ্চিত করার একমাত্র উপায় হল HTTPS। আপনার সাইট ও অ্যাপ্লিকেশনের জন্য আজই সুরক্ষিত কানেকশন
সেট-আপ করা উচিত। এটি একটি সহজ প্রক্রিয়া এবং আপনার গ্রাহকদের ডেটা সুরক্ষিত রাখতে সাহায্য করবে। আপনি এনক্রিপ্ট করা চ্যানেল সেট-আপ করার পরে, ব্যবহারকারী আপনার সাইটে যেভাবে এসেছেন তা নির্বিশেষে, ৩০১ HTTP রেসপন্স পাঠিয়ে, এই সুরক্ষিত কানেকশনে ব্যবহারকারীকে স্বচ্ছভাবে রিডাইরেক্ট করতে হবে। তারপর
নিশ্চিত করুন যে আপনার ব্যবহারকারীদের সমস্ত সংবেদনশীল সেশন তথ্য শুধুমাত্র
সেই নিরাপদ কানেকশন ব্যবহার করে, কুকি সেট করার সময় নিরাপদ কীওয়ার্ড যোগ করে।
আপনি এই সমস্ত কিছু করে ফেলার পরে, আপনার ব্যবহারকারীরা যাতে কখনও ভুলবশত
বাস থেকে পড়ে না যান তা নিশ্চিত করুন: তাদের ব্রাউজার যাতে Strict-Transport-Security হেডার পাঠিয়ে
সঠিক কাজ করে তা নিশ্চিত করে তাদের সুরক্ষিত করুন।
HTTPS সেট-আপ করতে খুব বেশি পরিশ্রম করতে হয় না এবং আপনার সাইট ও ব্যবহারকারীদের জন্য এটি খুবই সুবিধাজনক। চেষ্টা করলে ভালই হবে।
রিসোর্স
- StartSSL ফ্রি ডোমেন-যাচাই করা সার্টিফিকেট অফার করে। ফ্রির থেকে ভাল আর কিছু হয় না। আরও উন্নত গ্রেডের যাচাইকরণে আপগ্রেড করা অবশ্যই সম্ভব এবং এর জন্য যুক্তিসঙ্গত দাম নেওয়া হয়।
- SSL সার্ভার টেস্ট: আপনার সার্ভারের জন্য HTTPS সেট-আপ করার পরে, SSL ল্যাব সার্ভার টেস্টের মাধ্যমে এটি রান করে আপনি ঠিকভাবে করেছেন কিনা তা যাচাই করুন। আপনি একটি সুন্দরভাবে বিস্তারিত রিপোর্ট পাবেন যা আপনাকে দেখায় আপনি সত্যিই আপ এবং রানিং কিনা।
- Ars Technica-এর সাম্প্রতিক নিবন্ধ "SSL/TLS-এর মাধ্যমে আপনার ওয়েব সার্ভার সুরক্ষিত করা" সার্ভার সেট-আপ করার খুঁটিনাটি সম্পর্কে আরও একটু ব্যাকগ্রাউন্ড তথ্য জানার জন্য পড়া যেতে পারে।
Strict-Transport-Securityহেডারের ব্যাপারে আপনার প্রয়োজনীয় সব টেকনিক্যাল তথ্য জানতে HTTP স্ট্রিক্ট ট্রান্সপোর্ট সিকিউরিটি স্পেসিফিকেশন (RFC6797) একবার পড়ে নেওয়া ভাল।- আপনি কী করছেন তা একবার ভালভাবে বুঝে গেলে, পরবর্তী সম্ভাব্য পদক্ষেপ হবে
আপনার সাইট যে শুধুমাত্র নির্দিষ্ট সেট অফ সার্টিফিকেটের মাধ্যমে অ্যাক্সেস করা যাবে
তা বিজ্ঞাপন দিয়ে জানানো। IETF-এ কিছু কাজ চলছে যা আপনাকে
Public-Key-Pinsহেডার-এর মাধ্যমে ঠিক সেটাই করতে দেবে; এখনও প্রাথমিক পর্যায়ে আছে, তবে আকর্ষণীয় এবং অনুসরণ করার মতো।