নিজেকে লক আউট না করে কীভাবে HSTS সেট আপ করবেন

HSTS সহজ—যতক্ষণ না তা আর সহজ থাকে

HTTP Strict Transport Security, সাধারণত HSTS নামে সংক্ষিপ্ত, ব্রাউজারকে বলে: “এই সাইটের জন্য, সবসময় HTTPS ব্যবহার করো।” কোনো ব্রাউজার বৈধ HTTPS সংযোগের মাধ্যমে হেডারটি পেলে, আপনার নির্ধারিত সময়সীমা পর্যন্ত নিয়মটি মনে রাখে।

এটি কার্যকর। এটি প্রোটোকল ডাউনগ্রেড আক্রমণ ঠেকায়, ভুলবশত অনিরাপদ অনুরোধ কমায়, এবং ব্যবহারকারী example.com টাইপ করলে redirect হওয়ার আগে অল্প সময়ের জন্য plain HTTP স্পর্শ করার অস্বস্তিকর মুহূর্ত এড়ায়।

এটি আবার স্থায়ীভাবেও লেগে থাকে। আপনি ভুল HSTS নীতি প্রকাশ করলে, সার্ভার থেকে হেডার সরিয়ে নেওয়ার অনেক পরেও ব্রাউজার সেটি প্রয়োগ করতে পারে। এভাবেই দলগুলো নিজেদের লক আউট করে: ঠিক নিজেদের admin panel থেকে নয়, বরং ব্যবহারকারীদের ব্রাউজার, সাবডোমেইন, staging সিস্টেম, legacy endpoint, এবং জোরপূর্বক HTTPS-এর জন্য প্রস্তুত নয় এমন ভুলে যাওয়া সার্ভিস থেকে।

লক্ষ্য HSTS এড়িয়ে যাওয়া নয়। লক্ষ্য হলো এটিকে toggle-এর মতো নয়, migration-এর মতো deploy করা।

HSTS header আসলে কী করে

একটি সাধারণ HSTS header দেখতে এমন:

Strict-Transport-Security: max-age=31536000; includeSubDomains

এর তিনটি গুরুত্বপূর্ণ অংশ আছে:

• max-age: কত সেকেন্ড পর্যন্ত ব্রাউজার এই host-এর জন্য HTTPS বাধ্যতামূলক করবে।
• includeSubDomains: নিয়মটি প্রতিটি subdomain-এর ক্ষেত্রেও প্রযোজ্য হবে কি না।
• preload: domain-টি browser preload list-এ অন্তর্ভুক্ত করতে চান—এমন একটি সংকেত।

ব্রাউজার এই header কেবল তখনই বিশ্বাস করে, যখন এটি বৈধ HTTPS-এর মাধ্যমে পায়। Certificate invalid, expired, বা mismatched হলে, ব্রাউজারের ওই response থেকে নতুন HSTS policy গ্রহণ করা উচিত নয়।

Policy সংরক্ষিত হয়ে গেলে, ভবিষ্যতে http://example.com ভিজিট করার চেষ্টা করলে request পাঠানোর আগেই ব্রাউজার সেটিকে https://example.com-এ upgrade করে। গোপনীয়তার লাভটি এখানেই: অনিরাপদ request ডিভাইস ছেড়েই বের হয় না।

যে lockout পরিস্থিতিগুলো এড়াতে হবে

বেশিরভাগ HSTS ব্যর্থতা main website-এর কারণে হয় না। এগুলো প্রান্তে ঘটে।

1. ভুলে যাওয়া কোনো subdomain HTTPS-ready নয়

includeSubDomains পরিপাটি শোনায়, কিন্তু এটি সম্পূর্ণ। আপনি যদি example.com-এ সেট করেন, এটি প্রযোজ্য হবে:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• ওই domain-এর অধীনে অন্য সবকিছুতে

এর কোনো host যদি valid HTTPS serve করতে না পারে, HSTS policy cached থাকা ব্যবহারকারীরা HTTP দিয়ে সেখানে পৌঁছাতে পারবেন না।

2. একটি certificate expire হয়ে যায়

HSTS ছাড়া, ব্যবহারকারীরা কখনও কখনও certificate warning পাশ কাটিয়ে এগিয়ে যান। এটি ভালো security practice নয়, কিন্তু ঘটে।

HSTS থাকলে, আধুনিক ব্রাউজার ওই host-এর certificate error সহজে bypass করতে দেয় না। সেটাই উদ্দেশ্য। এর অর্থ আরও হলো certificate renewal বিরক্তিহীন, monitored, এবং tested হতে হবে।

3. Staging বা internal tools production domain-এর অধীনে থাকে

Internal tools-কে *.example.com-এর অধীনে রাখা parent domain-এ includeSubDomains ব্যবহারের পর কষ্টকর হতে পারে। যদি ওই tools self-signed certificates, private certificate authorities, পুরোনো TLS configuration, বা একেবারেই HTTPS না ব্যবহার করে, HSTS সেই shortcut প্রকাশ করে দেবে।

এ কারণেই অনেক দল internal এবং experimental system-গুলো আলাদা domain-এর অধীনে রাখে, যার নিজস্ব security policy থাকে।

4. Preload-কে routine checkbox হিসেবে ধরা হয়

HSTS preload আরেকটি directive মাত্র নয়। এর মানে হলো কোনো ব্যবহারকারী আপনার site ভিজিট করার আগেই আপনার domain ব্রাউজারের ভেতরে HTTPS-only হিসেবে shipped হতে পারে।

এটি “first visit” gap বন্ধ করে, কিন্তু undo করা অনেক কঠিন। Browser release cycle-এর ওপর নির্ভর করে preload list থেকে removal ব্যবহারকারীদের কাছে পৌঁছাতে কয়েক সপ্তাহ বা মাস লাগতে পারে। Preload স্থিতিশীল, পরিণত domain-এর জন্য উপযুক্ত। যে site এখনও নিজের subdomain inventory খুঁজে বের করছে, তার জন্য এটি উপযুক্ত নয়।

নিরাপদ rollout plan

Step 1: আপনার নিয়ন্ত্রণে থাকা প্রতিটি hostname audit করুন

includeSubDomains সেট করার আগে domain-এর অধীনে থাকা প্রতিটি hostname তালিকাভুক্ত করুন। DNS records একটি শুরু, কিন্তু পুরো গল্প নয়। CDN configuration, hosting dashboard, email-related hostname, পুরোনো marketing tools, storage buckets, এবং internal documentation পরীক্ষা করুন।

প্রতিটি hostname-এর জন্য উত্তর দিন:

• এটি কি HTTP, HTTPS, নাকি দুটিই serve করে?
• HTTPS certificate কি valid এবং automatically renewed?
• এটি কি HTTP থেকে HTTPS-এ পরিষ্কারভাবে redirect করে?
• এটি কি public হওয়ার কথা?
• এটি কি এখনও দরকার?

আপনার দলের যদি ইতিমধ্যেই production header debugging-এর অভ্যাস থাকে, এটি redirect ও header check-এর পাশে স্বাভাবিকভাবেই ফিট করে। আমরা সেই workflow নিয়ে লিখেছি production-এ redirects এবং HTTP headers debug করার একটি ছোট toolkit-এ।

Step 2: HSTS যোগ করার আগে HTTPS ঠিক করুন

HSTS ভাঙা HTTPS setup-কে secure করে না। এটি শুধু HTTPS বাধ্যতামূলক করে।

এটি enable করার আগে যাচাই করুন:

• TLS certificates সঠিক hostnames cover করে।
• Certificates automatically renew হয়।
• সম্ভব হলে HTTP একটিমাত্র clean hop-এ HTTPS-এ redirect করে।
• Canonical host redirects consistent, যেমন non-www থেকে www, বা উল্টো।
• Application assets অনিরাপদ http:// URL-এর ওপর নির্ভর করে না।

Mixed content আগের তুলনায় কম দেখা যায়, কিন্তু পুরোনো CMS theme, analytics snippet, embedded media, এবং hard-coded image path-এ এখনও দেখা যায়।

Step 3: খুব ছোট max-age দিয়ে শুরু করুন

এক বছর দিয়ে শুরু করবেন না। পাঁচ মিনিট দিয়ে শুরু করুন:

Strict-Transport-Security: max-age=300

এটি শুধু সেই hostname-এ deploy করুন যা আপনি test করছেন, সাধারণত canonical production website। আপাতত includeSubDomains বাদ দিন।

এরপর real browser এবং command-line request দিয়ে test করুন:

curl -I https://example.com

আপনার ঠিক একটি Strict-Transport-Security header দেখা উচিত। App server এবং CDN থেকে duplicate HSTS header বিভ্রান্তির সাধারণ উৎস। Browser সাধারণত effective policy প্রয়োগ করে, কিন্তু incident debug করা মানুষের ambiguity দরকার নেই।

Step 4: ধীরে ধীরে বাড়ান

কিছু না ভাঙলে, duration ধাপে ধাপে বাড়ান:

Strict-Transport-Security: max-age=86400

তারপর:

Strict-Transport-Security: max-age=604800

তারপর হয়তো:

Strict-Transport-Security: max-age=2592000

একটি ব্যবহারিক schedule হলো:

• 5 minutes
• 1 day
• 1 week
• 1 month
• 6 months or 1 year

তাড়াহুড়োর জন্য কোনো পুরস্কার নেই। Staged rollout-এর মূল উদ্দেশ্য হলো আপনার monitoring, support inbox, এবং edge case-গুলোকে সময় দেওয়া, যাতে checklist যা মিস করেছে তা তারা জানাতে পারে।

Step 5: audit সত্যিকারের হওয়ার পরই includeSubDomains যোগ করুন

প্রতিটি public subdomain HTTPS-ready হলে, আপনি বিবেচনা করতে পারেন:

Strict-Transport-Security: max-age=31536000; includeSubDomains

এটাই conservative হওয়ার সময়। যদি কোনো legacy service-এর এখনও HTTP দরকার হয়, parent domain-এ includeSubDomains যোগ করবেন না। হয় সেই service migrate করুন, অন্য domain-এ সরান, অথবা মেনে নিন যে আপাতত আপনার HSTS policy আরও narrow থাকতে হবে।

Security headers বাস্তবতা প্রতিফলিত করা উচিত। ভবিষ্যতে যে infrastructure পাবেন বলে আশা করেন, তার motivational poster হিসেবে এগুলো ব্যবহার করা উচিত নয়।

Step 6: preload-কে আলাদা project হিসেবে ধরুন

শুধু তখনই preload বিবেচনা করুন, যখন নিচের সবকিছু সত্য:

• Domain এবং সব subdomain valid HTTPS support করে।
• HTTP থেকে HTTPS-এ redirect হয়।
• HSTS header অন্তত 31536000 seconds-এর max-age ব্যবহার করে।
• Header-এ includeSubDomains আছে।
• Header-এ preload আছে।
• আপনি নিশ্চিত যে domain-এর অধীনে কোথাও plain HTTP দরকার হবে না।

Preload-ready header দেখতে এমন:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Preload list-এ submit করা একটি long-term commitment। Site যদি campaign microsite, temporary product domain, বা অস্পষ্ট ownership boundary-সহ কোনো domain হয়, এটি বাদ দিন।

Configuration examples

Nginx

always ব্যবহার করুন, যাতে error response-এও header পাঠানো হয়:

add_header Strict-Transport-Security "max-age=300" always;

Rollout stable হওয়ার পর:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Apache

mod_headers enabled থাকলে:

Header always set Strict-Transport-Security "max-age=300"

পরে:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

CDN or edge platform

আপনার CDN response headers set করলে, HSTS এক জায়গায় manage করাই ভালো। খুব পরিষ্কার কারণ না থাকলে origin-এ এক policy এবং edge-এ আরেক policy set করবেন না।

CDN redirects, cached errors, এবং custom error pages-এ headers apply করে কি না সেটিও পরীক্ষা করুন। Production site কেবল তার 200 OK response নয়।

HSTS কীভাবে নিরাপদে undo করবেন

HSTS disable করতে হলে পাঠান:

Strict-Transport-Security: max-age=0

কিন্তু একটি শর্ত আছে: ওই header পেতে browser-কে valid HTTPS-এর মাধ্যমে site-এ সফলভাবে পৌঁছাতে হবে। HTTPS নিজেই ভাঙা থাকলে, cached HSTS policy থাকা ব্যবহারকারীরা সেটি clear করার instruction আনতে পারবে না।

তাই সাধারণ recovery order হলো:

1. Valid HTTPS restore করুন।
2. Strict-Transport-Security: max-age=0 serve করুন।
3. Returning users যেন এটি পায়, সে জন্য যথেষ্ট সময় এটি রাখুন।
4. Incident resolved হওয়ার পর header remove বা replace করুন।

Domain preloaded হলে, নতুন browser profile-এর জন্য max-age=0 serve করাই যথেষ্ট নয়। আপনাকে preload list থেকে removal request করতে হবে এবং browser update-এর মাধ্যমে সেই change ship হওয়া পর্যন্ত অপেক্ষা করতে হবে।

Ship করার আগে testing checklist

max-age বাড়ানো বা includeSubDomains যোগ করার আগে এই checklist ব্যবহার করুন:

• Canonical HTTPS URL valid certificate return করে।
• HTTP থেকে HTTPS-এ redirect হয়।
• মাত্র একটি HSTS header আছে।
• যেখানে উপযুক্ত, redirects এবং error response-এ header দেখা যায়।
• সব public subdomain-এর valid HTTPS আছে।
• Certificate renewal monitored।
• একই parent domain-এর অধীনে কোনো critical internal system HTTP-এর ওপর নির্ভর করে না।
• Preload স্পষ্টভাবে আলোচনা করা হয়েছে, অভ্যাসবশত যোগ করা হয়নি।

Lighthouse কিছু context-এ missing বা weak security headers flag করতে পারে, কিন্তু এটি আপনার একমাত্র verification method হওয়া উচিত নয়। Wider review-এর অংশ হিসেবে ব্যবহার করলে findings-গুলোকে verdict নয়, signal হিসেবে পড়ুন; একই mindset প্রযোজ্য যখন আপনি আতঙ্কিত না হয়ে Lighthouse report পড়েন।

<!-- tool-cta:start -->

💡 এটি চেষ্টা করুন: প্রতিটি HSTS পরিবর্তনের আগে ও পরে, Get Headers দিয়ে Strict-Transport-Security response পরীক্ষা করুন, যাতে max-age, includeSubDomains এবং preload আপনার প্রত্যাশামতো আছে কি না নিশ্চিত করা যায়।

<!-- tool-cta:end -->

HSTS-এর privacy case

HSTS-কে প্রায়ই security header হিসেবে দেখা হয়, এবং সেটি ঠিক। এর privacy benefit-ও আছে: এটি untrusted network-এ ব্যবহারকারীর first request plain HTTP দিয়ে leak হওয়ার সম্ভাবনা কমায়।

Airport Wi-Fi, hotel networks, corporate guest networks, এবং যেখানে ব্যবহারকারীর traffic observe বা modify হতে পারে—সেখানে এটি গুরুত্বপূর্ণ। Plain HTTP request hostname, path, Secure flag ছাড়া cookies, এবং অন্যান্য request details প্রকাশ করতে পারে। HTTPS জাদু নয়, কিন্তু ধারাবাহিকভাবে এটি বাধ্যতামূলক করলে avoidable leakage-এর একটি পুরো শ্রেণি দূর হয়।

সেরা HSTS deployments আকর্ষণহীন। এগুলো ধীরে রোলআউট করা হয়, reliable certificates দ্বারা সমর্থিত থাকে, এবং এতটাই boring যে কেউ খেয়াল করে না। Failure mode dramatic হতে পারে—এমন একটি header থেকে আপনি ঠিক এটিই চান।