HTTPS এবং HTTP কঠোর পরিবহন নিরাপত্তা সহ দূষিত মধ্যস্থতাকারীদের বিভ্রান্ত করুন

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

কেন আপনি যত্ন করা উচিত? এই বিবেচনা:

একটি এনক্রিপ্ট না করা HTTP সংযোগের মাধ্যমে একটি ওয়েব পৃষ্ঠা সরবরাহ করা কমবেশি একটি সিলবিহীন খাম তুলে দেওয়ার মতোই যা আপনি রাস্তায় প্রথম যে ব্যক্তিকে দেখেন যাকে দেখে মনে হচ্ছে সে পোস্ট অফিসের দিকে হাঁটছে৷ যদি আপনি ভাগ্যবান হন, তাহলে তিনি হয়তো এটিকে নিজের কাছে নিয়ে যেতে পারেন, অথবা তিনি এটিকে পরের ব্যক্তির হাতে তুলে দিতে পারেন যে তিনি দেখেন কে সঠিক পথে চলেছে। যে ব্যক্তি একই কাজ করতে পারে, এবং তাই.

এই অবিলম্বে চেইনের বেশিরভাগ অপরিচিত ব্যক্তি বিশ্বস্ত, এবং তারা কখনই আপনার খোলা চিঠিতে উঁকি দেবে না বা এটি পরিবর্তন করবে না। যতবার চিঠির হাত পরিবর্তন হয়, তবে, আপনি যে চিঠিটি পাঠাচ্ছেন তাতে সম্পূর্ণ অ্যাক্সেস সহ লোকেদের সংখ্যা তত বেশি হবে। শেষ পর্যন্ত, আপনার চিঠির উদ্দেশ্যপ্রণোদিত প্রাপক মেইলে কিছু পাওয়ার সম্ভাবনা রয়েছে, তবে আপনি প্রথম স্থানে যেটি হস্তান্তর করেছিলেন সেটি একই জিনিস কিনা তা একটি খোলা প্রশ্ন। সম্ভবত আপনার সেই খামটি সিল করা উচিত ছিল…

মধ্যস্বত্বভোগী

ভাল বা খারাপ, ইন্টারনেটের বিশাল অংশগুলি অপরিচিতদের বিশ্বস্ততার উপর নির্ভর করে। সার্ভারগুলি একে অপরের সাথে সরাসরি সংযুক্ত নয়, তবে টেলিফোনের একটি বিশাল গেমে রাউটার থেকে রাউটারে অনুরোধ এবং প্রতিক্রিয়াগুলি পাস করে।

আপনি ট্রেসারউটের সাথে এই হপগুলিকে অ্যাকশনে দেখতে পারেন। আমার কম্পিউটার থেকে 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

13 হপস সত্যিই খারাপ নয়। যাইহোক, যদি আমি HTTP এর মাধ্যমে অনুরোধ পাঠাই, তাহলে সেই মধ্যবর্তী রাউটারগুলির প্রত্যেকের আমার অনুরোধ এবং সার্ভারের প্রতিক্রিয়াগুলিতে সম্পূর্ণ অ্যাক্সেস রয়েছে। সমস্ত ডেটা এনক্রিপ্ট করা প্লেইনটেক্সট হিসাবে স্থানান্তরিত হচ্ছে, এবং এই মধ্যস্থতাকারীগুলির মধ্যে যেকোন একজন মধ্যস্থতাকারী হিসাবে কাজ করতে পারে, আমার ডেটার মাধ্যমে পড়তে পারে, বা এমনকি ট্রানজিটে এটিকে হেরফের করতে পারে।

আরও খারাপ, এই ধরণের বাধা কার্যত সনাক্ত করা যায় না। একটি দূষিতভাবে সংশোধিত HTTP প্রতিক্রিয়া দেখতে একটি বৈধ প্রতিক্রিয়ার মতো দেখায়, কারণ এমন কোনও ব্যবস্থা নেই যা আপনাকে নিশ্চিত করতে সক্ষম করবে যে প্রাপ্ত ডেটা _ঠিকভাবে _প্রেরিত ডেটা। কেউ যদি হাসির জন্য আমার ইন্টারনেটকে উল্টে দেওয়ার সিদ্ধান্ত নেয়, তাহলে আমি কমবেশি ভাগ্যের বাইরে আছি।

এটি একটি নিরাপদ লাইন?

প্লেইনটেক্সট HTTP থেকে একটি সুরক্ষিত HTTPS সংযোগে স্যুইচ করা মধ্যস্থতাকারীদের বিরুদ্ধে আপনার সর্বোত্তম প্রতিরক্ষা প্রদান করে। এইচটিটিপিএস সংযোগগুলি কোনও ডেটা পাঠানোর আগে পুরো চ্যানেল এন্ড-টু-এন্ড এনক্রিপ্ট করে, যা আপনার এবং আপনার গন্তব্যের মধ্যে মেশিনগুলির পক্ষে ট্রানজিটে ডেটা পড়া বা পরিবর্তন করা অসম্ভব করে তোলে।

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

এইচটিটিপিএস, তাই, আপনাকে কিছু আশ্বাস দেয় যে আপনি যে সার্ভারের সাথে কথা বলছেন বলে আপনি মনে করেন তার সাথে কথা বলছেন এবং অন্য কেউ তারের বিটগুলিতে শুনছে না বা ঘুরছে না। এই ধরনের এনক্রিপশন হল ওয়েবে নিরাপত্তার জন্য একটি পরম পূর্বশর্ত; যদি আপনার অ্যাপ্লিকেশনটি বর্তমানে HTTPS-এর মাধ্যমে বিতরণ করা না হয়, তবে এটি আক্রমণের ঝুঁকিপূর্ণ। ঠিক কর. আরস টেকনিকার একটি শংসাপত্র (বিনামূল্যে) প্রাপ্ত এবং ইনস্টল করার জন্য একটি দুর্দান্ত নির্দেশিকা রয়েছে যা আমি আপনাকে প্রযুক্তিগত বিবরণের জন্য একবার দেখার পরামর্শ দেব। কনফিগারেশন প্রদানকারী থেকে প্রদানকারী এবং সার্ভার থেকে সার্ভারে ভিন্ন হবে, কিন্তু সার্টিফিকেট অনুরোধ প্রক্রিয়া সর্বত্র একই।

ডিফল্টরূপে সুরক্ষিত

একবার আপনি একটি শংসাপত্রের অনুরোধ এবং ইনস্টল করার পরে, নিশ্চিত করুন যে আপনার ব্যবহারকারীরা আপনার কঠোর পরিশ্রম থেকে উপকৃত হচ্ছেন: HTTP পুনঃনির্দেশের ম্যাজিকের মাধ্যমে স্বচ্ছভাবে আপনার বিদ্যমান ব্যবহারকারীদের HTTPS সংযোগে স্থানান্তর করুন এবং নিশ্চিত করুন যে কুকিজ শুধুমাত্র নিরাপদ সংযোগের মাধ্যমে বিতরণ করা হয়েছে।

অনুগ্রহপূবর্ক এই পথে

যখন একজন ব্যবহারকারী http://example.com/ পরিদর্শন করেন, একটি উপযুক্ত Location শিরোনাম সহ একটি 301 Moved Permanently প্রতিক্রিয়া পাঠিয়ে তাদের https://example.com/ এ পুনঃনির্দেশ করুন:

$ 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

নিরাপদ কীওয়ার্ড সহ সেট করা কুকিগুলি কখনই HTTP এর মাধ্যমে পাঠানো হবে না।

খোলা জানালা বন্ধ করে

এইচটিটিপিএস-এ স্বচ্ছ পুনঃনির্দেশের অর্থ হল আপনার ব্যবহারকারীরা আপনার সাইটে থাকা বেশিরভাগ সময়, তারা একটি সুরক্ষিত সংযোগ ব্যবহার করবে। যাইহোক, এটি আক্রমণের জন্য সুযোগের একটি ছোট উইন্ডো রেখে দেয়: প্রাথমিক HTTP সংযোগ বিস্তৃত, SSL স্ট্রিপিং এবং সম্পর্কিত আক্রমণগুলির জন্য ঝুঁকিপূর্ণ। প্রদত্ত যে মাঝখানের একজন ব্যক্তির প্রাথমিক HTTP অনুরোধে সম্পূর্ণ অ্যাক্সেস রয়েছে, এটি আপনার এবং সার্ভারের মধ্যে একটি প্রক্সি হিসাবে কাজ করতে পারে, সার্ভারের উদ্দেশ্য নির্বিশেষে আপনাকে একটি অনিরাপদ HTTP সংযোগে রাখতে পারে।

আপনি ব্রাউজারকে HTTP স্ট্রিক্ট ট্রান্সপোর্ট সিকিউরিটি (HSTS) প্রয়োগ করতে বলে এই শ্রেণীর আক্রমণের ঝুঁকি কমাতে পারেন। Strict-Transport-Security HTTP শিরোনাম পাঠানো ব্রাউজারকে নির্দেশ দেয় HTTP থেকে HTTPS থেকে HTTPS পুনঃনির্দেশ ক্লায়েন্ট-সাইডে , কখনো নেটওয়ার্ক স্পর্শ না করে (এটি পারফরম্যান্সের জন্যও দুর্দান্ত হতে পারে; সর্বোত্তম অনুরোধটি হল যা আপনাকে করতে হবে না তৈরি করুন):

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

যে ব্রাউজারগুলি এই শিরোনামটিকে সমর্থন করে (বর্তমানে ফায়ারফক্স, ক্রোম এবং অপেরা: ক্যানিউসের বিবরণ রয়েছে ) একটি নোট করবে যে এই নির্দিষ্ট সাইটটি শুধুমাত্র HTTPS-অ্যাক্সেসের জন্য অনুরোধ করেছে, যার অর্থ এই যে কোনও ব্যবহারকারী যেভাবেই সাইটে আসেন না কেন, সে ভিজিট করবে HTTPS এর উপর। এমনকি যদি সে ব্রাউজারে http://example.com/ টাইপ করে, সে কখনোই HTTP সংযোগ না করেই HTTPS-এ শেষ হবে। আরও ভাল, যদি ব্রাউজার একটি অবৈধ শংসাপত্র সনাক্ত করে (সম্ভবত আপনার সার্ভারের পরিচয় ফাঁকি দেওয়ার চেষ্টা করছে), ব্যবহারকারীদের HTTP এর মাধ্যমে চালিয়ে যাওয়ার অনুমতি দেওয়া হবে না; এটা সব বা কিছুই, চমৎকার যা.

ব্রাউজার সার্ভারের এইচএসটিএস স্ট্যাটাস max-age সেকেন্ডের পরে শেষ হয়ে যাবে (এই উদাহরণে প্রায় এক মাস); যুক্তিসঙ্গতভাবে উচ্চ কিছু এই সেট.

আপনি শিরোনামে includeSubDomains নির্দেশিকা যোগ করে একটি মূলের সমস্ত সাবডোমেন সুরক্ষিত আছে তা নিশ্চিত করতে পারেন:

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

নিরাপদে, এগিয়ে যান

HTTPS হল দূরবর্তীভাবে নিশ্চিত হওয়ার একমাত্র উপায় যে আপনার পাঠানো ডেটা অক্ষত প্রাপকের কাছে পৌঁছেছে। আপনার সাইট এবং অ্যাপ্লিকেশনের জন্য আজই নিরাপদ সংযোগ স্থাপন করা উচিত। এটি একটি মোটামুটি সহজবোধ্য প্রক্রিয়া, এবং আপনার গ্রাহকদের ডেটা সুরক্ষিত রাখতে সাহায্য করবে৷ একবার আপনি জায়গায় একটি এনক্রিপ্ট করা চ্যানেল পেয়ে গেলে, ব্যবহারকারীরা 301 HTTP প্রতিক্রিয়া পাঠিয়ে আপনার সাইটে যেভাবে আসুক না কেন, আপনাকে স্বচ্ছভাবে এই সুরক্ষিত সংযোগে পুনর্নির্দেশ করা উচিত। তারপর নিশ্চিত করুন যে আপনার সমস্ত ব্যবহারকারীর সংবেদনশীল সেশনের তথ্য কুকি সেট করার সময় নিরাপদ কীওয়ার্ড যোগ করে শুধুমাত্র সেই সুরক্ষিত সংযোগ ব্যবহার করে। একবার আপনি এই সব করে ফেললে, নিশ্চিত করুন যে আপনার ব্যবহারকারীরা কখনই দুর্ঘটনাবশত বাস থেকে পড়ে যাবেন না: একটি Strict-Transport-Security শিরোনাম পাঠিয়ে তাদের ব্রাউজার সঠিক কাজটি করে তা নিশ্চিত করে তাদের রক্ষা করুন।

HTTPS সেট আপ করা খুব বেশি কাজ নয় এবং আপনার সাইট এবং এর ব্যবহারকারীদের জন্য বিশাল সুবিধা রয়েছে। এটা ভাল প্রচেষ্টার মূল্য.

সম্পদ

• StartSSL বিনামূল্যে ডোমেন-যাচাইকৃত শংসাপত্র অফার করে। আপনি বিনামূল্যে বীট করতে পারবেন না. যাচাইকরণের উচ্চতর গ্রেডে পৌঁছানো অবশ্যই সম্ভব এবং যুক্তিসঙ্গত মূল্য উভয়ই।
• SSL সার্ভার পরীক্ষা : একবার আপনি আপনার সার্ভারের জন্য HTTPS সেট আপ করার পরে, SSL ল্যাবসের সার্ভার পরীক্ষার মাধ্যমে এটি চালিয়ে আপনি সঠিকভাবে করেছেন কিনা তা যাচাই করুন। আপনি একটি সুন্দর বিশদ প্রতিবেদন পাবেন যা আপনাকে দেখায় যে আপনি সত্যিই প্রস্তুত এবং চলমান কিনা।
• আরস টেকনিকার সাম্প্রতিক নিবন্ধ "SSL/TLS দিয়ে আপনার ওয়েব সার্ভার সুরক্ষিত করা" সার্ভার সেট আপ করার বাদাম এবং বোল্ট সম্পর্কে একটু বেশি পটভূমির বিশদ বিবরণ পড়ার জন্য মূল্যবান।
• এইচটিটিপি স্ট্রিক্ট ট্রান্সপোর্ট সিকিউরিটি স্পেসিফিকেশন (RFC6797) Strict-Transport-Security শিরোনাম সম্পর্কে সমস্ত প্রযুক্তিগত তথ্যের জন্য স্কিমিং করা মূল্যবান যা আপনি সম্ভবত চান।
• একবার আপনি সত্যিই জানেন যে আপনি কী করছেন, একটি সম্ভাব্য পরবর্তী পদক্ষেপ হবে বিজ্ঞাপন দেওয়া যে আপনার সাইটটি শুধুমাত্র একটি নির্দিষ্ট শংসাপত্রের মাধ্যমে পৌঁছানো উচিত। IETF-এ কিছু কাজ চলছে যা আপনাকে Public-Key-Pins হেডারের মাধ্যমে এটি করতে দেয়; এখনও প্রাথমিক দিন, কিন্তু আকর্ষণীয়, এবং অনুসরণ করা মূল্যবান।