وقتی HTTPS روی یک سایت فعال است، هنوز ممکن است مرورگر در بعضی درخواستها ابتدا سراغ HTTP برود. HSTS برای بستن همین مسیر طراحی شده است و به مرورگر اعلام میکند که این دامنه باید فقط از طریق HTTPS باز شود. در این مقاله ابتدا بررسی میکنیم که پروتکل HSTS چیست و چگونه کار میکند، سپس سراغ فعالسازی آن در Nginx و Apache، خطاهای رایج و روش درست عیبیابی آن میرویم. تا انتهای این مطلب با ما همراه باشید.
HSTS چیست؟
HSTS مخفف HTTP Strict Transport Security است؛ یک سیاست امنیتی که مرورگر را ملزم میکند برای اتصال به یک دامنه فقط از HTTPS استفاده کند. سایت این سیاست را با هدر Strict-Transport-Security به مرورگر میفرستد و در همان هدر مشخص میکند این الزام چه مدت باید اعتبار داشته باشد.
اگر کاربر بعداً آدرس سایت را با HTTP وارد کند، مرورگری که قبلاً هدر HSTS را دریافت کرده است، درخواست را پیش از برقراری اتصال به HTTPS تغییر میدهد. به این ترتیب، فرصت سوءاستفاده از مسیر ناامن HTTP کمتر میشود و ریسک حملاتی مانند SSL Stripping کاهش پیدا میکند.
البته این سازوکار جای SSL/TLS را نمیگیرد. HSTS زمانی کاربرد دارد که HTTPS از قبل درست و پایدار راهاندازی شده باشد. اگر هنوز گواهی مناسبی برای سایت ندارید، ابتدا باید سراغ خرید ssl یا استفادۀ از ssl رایگان بروید و بعد HSTS را فعال کنید.
پروتکل HSTS چگونه کار میکند؟
هستۀ عملکرد HSTS همان هدر Strict-Transport-Security است. وبسرور این هدر را پس از برقراری اتصال HTTPS در پاسخ خود میفرستد؛ برای مثال:
Strict-Transport-Security: max-age=31536000; includeSubDomains
در نمونۀ بالا، دو دستور اصلی، رفتارِ HSTS را مشخص میکنند:
- دستور max-age: تعیین میکند مرورگر این سیاست را چند ثانیه نگه دارد.
- دستور includeSubDomains: مشخص میکند HSTS علاوه بر دامنۀ اصلی، برای زیردامنهها هم اعمال شود.
بعد از دریافت هدر، مرورگر آن را ذخیره میکند و از آن پس تا پایان زمان تعیینشده در max-age، درخواستهای مربوط به دامنه را از مسیر HTTPS میفرستد و اجازۀ بازگشت عادی به HTTP را نمیدهد.
HSTS چه تفاوتی با HTTPS و TLS دارد؟
HSTS و HTTPS و TLS در یک زنجیرۀ امنیتی کنار هم قرار میگیرند، اما کار یکسانی انجام نمیدهند. TLS دادههای در حال انتقال را رمزنگاری و از صحت ارتباط محافظت میکند، HTTPS همان ارتباط امن را برای وب فراهم میکند، و HSTS به مرورگر میگوید همیشه از همین مسیر استفاده کند. بنابراین اگر میخواهید دقیقتر بدانید TLS چیست، بهتر است نقش آن را از HSTS جدا ببینید. جدول زیر تفاوت این سه مفهوم را به صورت خلاصه نمایش میدهد.
|
TLS |
HTTPS | HSTS |
معیار |
|
پروتکل رمزنگاری |
روش ارتباط امن بر بستر HTTP | سیاست امنیتی | نوع |
|
رمزنگاری و حفاظت از ارتباط |
ایجاد ارتباط امن بین کاربر و سایت | اجبار مرورگر به استفاده از HTTPS | وظیفۀ اصلی |
| تأمین محرمانگی و صحت داده | رمزنگاری ترافیک | جلوگیری از بازگشت به HTTP |
نقش در امنیت |
|
بخشی از زیرساخت ارتباط امن |
بله | بله، برای استفاده صحیح | نیاز به گواهی TLS/SSL |
| هنگام برقراری اتصال امن | هنگام اتصال HTTPS | با اعمال سیاست HSTS در مرورگر |
اجرا در مرورگر |
مزایای استفاده از HSTS
وقتی HTTPS بهدرستی پیکربندی شده باشد، HSTS با حذف مسیر بازگشت به HTTP چند مزیت امنیتی مهم ایجاد میکند، از جمله:
- جلوگیری از Downgrade: احتمال اینکه ارتباط از HTTPS به HTTP برگردد کمتر میشود.
- مقابله با SSL Stripping: مهاجم نمیتواند بهسادگی کاربر را از نسخۀ امن سایت به HTTP هدایت کند.
- محافظت بهتر از اطلاعات ورود: دادههای حساسی مثل نام کاربری و رمز عبور در مسیر ناامن HTTP ارسال نمیشوند.
- رفتار یکدست مرورگر: مرورگر پس از دریافت هدر میداند که این دامنه باید فقط با HTTPS باز شود و همین سیاست را در مراجعههای بعدی هم رعایت میکند.
این مزایا زمانی به دست میآیند که HSTS با دقت تنظیم شده باشد. اگر includeSubDomains را بدون بررسی زیردامنهها فعال کنید، سایتی که روی یکی از آنها HTTPS سالم ندارد ممکن است برای کاربران از دسترس خارج شود. به همین دلیل، پیش از سختگیرانهتر کردن سیاست باید مطمئن شوید HTTPS روی دامنه و زیردامنههای موردنظر بدون خطا کار میکند.
نصب HSTS چگونه انجام میشود؟
HSTS نرمافزار یا پکیجی نیست که روی سرور نصب شود. اصطلاح «نصب hsts» در عمل به معنی اضافهکردن هدر Strict-Transport-Security به تنظیمات وبسرور است. محل قرارگیری این هدر اهمیت زیادی دارد، چون مرورگر آن را فقط از یک پاسخ معتبر HTTPS میپذیرد.
در Nginx باید هدر HSTS را داخل Server Block مربوط به HTTPS و پورت 443 قرار دهید، نه در بلاک HTTP روی پورت 80. اگر دستور را در بخش اشتباه بگذارید، ممکن است Nginx همچنان بدون خطا اجرا شود، اما مرورگر هدر موردنیاز را در پاسخ HTTPS دریافت نکند.
add_header Strict-Transport-Security "max-age=31536000" always;
بعد از افزودن هدر، قبل از هر کاری صحت Configuration را بررسی کنید:
sudo nginx -t
اگر تست بدون خطا بود، تنظیمات جدید را با Reload کردن Nginx اعمال کنید:
sudo systemctl reload nginx
پس از Reload، سرور باید هدر HSTS را همراه پاسخهای HTTPS ارسال کند. بهتر است در مرحلۀ بعد، دریافت این هدر را نیز از سمت مرورگر یا با curl بررسی کنید.
هشداری که باید جدی بگیرید: HSTS را فقط زمانی فعال کنید که HTTPS سایت پایدار و بدون خطا باشد. اگر میخواهید includeSubDomains را هم به هدر اضافه کنید، پیش از آن گواهی و دسترسی HTTPS همه زیردامنههای مشمول این سیاست را بررسی کنید.
نصب پروتکل HSTS در Apache
در Apache منطق انجام کار مانند مرحلۀ قبل است، اما ابتدا باید مطمئن شوید ماژول headers فعال است. اگر این ماژول غیرفعال باشد، Apache نمیتواند هدر HSTS را به پاسخ اضافه کند. برای فعالکردن ماژول و بارگذاری دوبارۀ سرویس میتوانید از دستورهای زیر استفاده کنید:
sudo a2enmod headers sudo systemctl reload apache2
بعد از فعالشدن ماژول، هدر HSTS را در Virtual Host مربوط به HTTPS و پورت 443 قرار دهید. اگرچه تعریف آن در بلاک HTTP یا یک Virtual Host دیگر ممکن است هیچ خطای آشکاری ایجاد نکند، اما هدر در پاسخ واقعی دامنه ارسال نخواهد شد. برای نمونه، تنظیم HSTS در Apache میتواند به شکل زیر باشد:
Header always set Strict-Transport-Security "max-age=31536000"
در پایان، Configuration را بررسی و Apache را Reload یا Restart کنید. نام فایلها و دستور دقیق این مرحله بسته به سیستمعامل و ساختار Virtual Host سرور میتواند متفاوت باشد، اما اصل کار یکی است و هدر باید در پاسخ معتبر HTTPS همان دامنه دیده شود.
ارور HSTS چیست؟
همان سختگیریای که HSTS را به یک لایۀ امنیتی مفید تبدیل میکند، هنگام بروز مشکل در HTTPS هم خودش را نشان میدهد. اگر مرورگر از قبل بداند یک دامنه باید فقط با HTTPS باز شود اما نتواند اتصال امن معتبری برقرار کند، بهجای برگشتن به HTTP اتصال را متوقف میکند و این وضعیت معمولاً با عنوان ارور hsts دیده میشود.
در چنین شرایطی خود HSTS معمولاً علت اصلی مشکل نیست. باید بررسی کنید چه چیزی مانع برقراری یک اتصال معتبر HTTPS شده است: گواهی SSL/TLS، نام دامنه، زنجیره Certificate یا تنظیمات وبسرور از مهمترین مواردی هستند که باید بررسی شوند.
برای مثال، اگر گواهی منقضی شده باشد یا نام دامنه با اطلاعات Certificate تطابق نداشته باشد، مرورگر نمیتواند اتصال را معتبر بداند. چون سیاست HSTS فعال است، امکان دورزدن مشکل با بازکردن نسخه HTTP هم وجود ندارد. این رفتار عمدی است. اگر مرورگر در چنین موقعیتی اجازۀ بازگشت به HTTP را بدهد، همان مسیری دوباره باز میشود که HSTS برای جلوگیری از آن طراحی شده است.
رفع خطای HSTS چگونه انجام میشود؟
برای رفع خطای hsts بهتر است از خود HTTPS شروع کنید، نه از تنظیمات مرورگر. ابتدا بررسی کنید پورت 443 در دسترس است، گواهی اعتبار دارد و پاسخ HTTPS از Virtual Host یا Server Block درست ارسال میشود. سپس سراغ هدر Strict-Transport-Security بروید و مطمئن شوید در جای مناسب تعریف شده است.
پاککردن اطلاعات HSTS از مرورگر ممکن است در بعضی آزمایشها موقتاً مفید باشد، اما راهحل اصلی نیست. اگر گواهی یا پیکربندی سرور مشکل داشته باشد، با حذف این اطلاعات فقط نشانۀ خطا را برای مدتی پنهان میکنید و علت اصلی همچنان باقی میماند. برای پیدا کردن ریشه مشکل، این موارد را بهترتیب بررسی کنید:
- اعتبار گواهی: تاریخ انقضا و وضعیت اعتبار Certificate را بررسی کنید.
- نام دامنه: مطمئن شوید گواهی برای همان دامنهای صادر شده که کاربر در مرورگر باز میکند.
- زنجیرۀ Certificate: بررسی کنید Certificate Chain کامل است و تمام گواهیهای واسط بهدرستی ارسال میشوند.
- تنظیمات Configuration HTTPS: وبسرور و Virtual Host یا Server Block مربوط به پورت 443 را بررسی کنید.
- زیردامنهها: اگر includeSubDomains فعال است، اتصال HTTPS همه زیردامنههایی را که زیر این سیاست قرار میگیرند آزمایش کنید.
اگر HSTS را تازه فعال کردهاید و هنوز در بخشی از دامنه یا زیردامنهها مشکل HTTPS دارید، اول همان مشکلات را برطرف کنید. بعد از اینکه اتصال امن در تمام بخشها پایدار شد، میتوانید سیاست را با اطمینان بیشتری سختگیرانهتر کنید.
خطای HSTS در مرورگر چگونه بررسی شود؟
بعد از تنظیم HSTS یا هنگام عیبیابی، بهتر است مطمئن شوید سرور واقعاً هدر موردنظر را در پاسخ میفرستد. این کار را میتوانید از بخش Network در ابزارهای توسعهدهندۀ مرورگر انجام دهید یا از دستور curl کمک بگیرید:
curl -I https://example.com
در پاسخ باید هدر Strict-Transport-Security را ببینید؛ برای مثال:
Strict-Transport-Security: max-age=31536000
اگر این هدر وجود ندارد، احتمالاً دستور در بخش درستی از تنظیمات وبسرور قرار نگرفته یا پاسخ HTTPS دامنه از Server Block یا Virtual Host دیگری میآید. در این حالت، مسیر واقعی پاسخ را پیدا کنید و تنظیم HSTS را همانجا قرار دهید.
آیا HSTS همیشه باید فعال باشد؟
HSTS برای بیشتر سایتهایی که HTTPS را بهصورت کامل و پایدار اجرا میکنند، انتخاب مناسبی است، اما بهتر است از همان ابتدا سراغ سختگیرانهترین تنظیمات نروید. چون مرورگر سیاست را برای مدتی ذخیره میکند، یک اشتباه در تنظیمات میتواند اثرش را حتی بعد از اصلاح سرور هم برای مدتی حفظ کند.
رویکرد مطمئنتر این است که ابتدا max-age کوتاهتری انتخاب کنید و پس از اطمینان از عملکرد صحیح HTTPS، آن را افزایش دهید. دربارۀ includeSubDomains نیز همین احتیاط لازم است؛ فعالکردن آن زمانی منطقی است که همۀ زیردامنههای مشمول سیاست بهطور دائم از HTTPS معتبر استفاده کنند.
HSTS و HSTS Preload
HSTS معمولی یک محدودیت دارد: اینکه مرورگر باید دستکم یکبار از طریق HTTPS به سایت وصل شود و هدر را دریافت کند تا سیاست را بشناسد. HSTS Preload برای پوشش همین فاصله استفاده میشود. در این حالت، دامنه در فهرستی قرار میگیرد که مرورگر از قبل در اختیار دارد؛ بنابراین حتی اولین مراجعه نیز مستقیماً با HTTPS انجام میشود.
برای استفاده از HSTS Preload، باید شرایط لازم این سرویس را رعایت کنید و دایرکتیو preload را نیز به هدر HSTS اضافه کنید:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
پس از آمادهسازی تنظیمات، میتوان دامنه را برای بررسی و ثبت در فهرست رسمی HSTS Preload در hstspreload.org معرفی کرد. این مرحله را نباید عجولانه انجام داد؛ به این دلیل که همۀ زیردامنههای مشمول سیاست باید همیشه از HTTPS استفاده کنند، چون حذف دامنه از فهرست Preload فوری نیست و ممکن است زمان ببرد.
به همین دلیل، Preload گزینهای برای «گرفتن امتیاز امنیتی بیشتر» نیست. زمانی سراغ آن بروید که ساختار HTTPS دامنه و زیردامنهها تثبیت شده است و مطمئن هستید در آیندۀ نزدیک به HTTP نیاز نخواهید داشت. در نتیجه، تفاوت HSTS معمولی و Preload بیشتر به زمان اعمال سیاست برمیگردد؛ به این صورت که HSTS بعد از دریافت هدر فعال میشود، اما Preload اجازه میدهد مرورگر از همان اولین مراجعۀ دامنه را فقط با HTTPS باز کند.
جمعبندی
HSTS خودش ارتباط را رمزنگاری نمیکند و وظیفۀ آن این است که مرورگر را روی مسیر امن HTTPS نگه دارد و اجازه بازگشت عادی به HTTP را ندهد. همین رفتار میتواند احتمال حملاتی مانند Downgrade و SSL Stripping را کمتر کند.
برای فعالسازی آن هم نیازی به نصب نرمافزار جداگانه نیست. کافی است هدر Strict-Transport-Security را در بخش HTTPS تنظیمات Nginx یا Apache قرار دهید و بعد از اعمال تغییرات، ارسال صحیح هدر را بررسی کنید. شرط اصلی این است که HTTPS پیش از HSTS بدون خطا کار کند.
اگر قصد استفاده از includeSubDomains یا Preload را دارید، بررسی باید دقیقتر باشد؛ چون این دو گزینۀ دامنه اثر سیاست را گستردهتر میکنند و بازگشت از یک تنظیم اشتباه را دشوارتر. پس ابتدا زیرساخت HTTPS را پایدار کنید و بعد سراغ این تنظیمات بروید.
سؤالات متداول
HSTS چیست؟
HSTS یا HTTP Strict Transport Security یک سیاست امنیتی است که به مرورگر میگوید یک دامنه را فقط از طریق HTTPS باز کند. مرورگر پس از دریافت هدر مربوط به HSTS، این تصمیم را برای مدت تعیینشده ذخیره میکند و در این بازه به HTTP برنمیگردد.
آیا HSTS همان HTTPS است؟
خیر. HTTPS ارتباط میان کاربر و سرور را با کمک TLS امن میکند، اما HSTS تعیین میکند مرورگر برای دسترسی به دامنه همیشه از همین ارتباط امن استفاده کند. به همین دلیل، HSTS جایگزین SSL/TLS نیست و بدون HTTPS سالم کاربردی ندارد.
نصب HSTS چگونه انجام میشود؟
HSTS پکیج جداگانهای برای نصب ندارد. برای فعالکردن آن باید هدر Strict-Transport-Security را در تنظیمات HTTPS وبسرور قرار دهید. در Nginx این هدر در Server Block مربوط به پورت 443 تعریف میشود و پس از بررسی Configuration، با Reload سرویس اعمال خواهد شد.
ارور HSTS چرا ایجاد میشود؟
این خطا معمولاً زمانی رخ میدهد که مرورگر میداند دامنه باید با HSTS فقط از طریق HTTPS باز شود، اما اتصال امن معتبر برقرار نمیشود. گواهی منقضی یا نامعتبر، تطابقنداشتن نام دامنه با Certificate، ناقص بودن زنجیرۀ گواهی یا تنظیم اشتباه SSL از علتهای رایج هستند.
چگونه خطای HSTS را رفع کنیم؟
از بررسی HTTPS شروع کنید: اعتبار و نام دامنه گواهی، Certificate Chain، دسترسی پورت 443 و تنظیمات وبسرور را کنترل کنید. اگر includeSubDomains فعال است، زیردامنهها را هم جداگانه آزمایش کنید. حذف اطلاعات HSTS از مرورگر بدون برطرفکردن مشکل اصلی، راهحل پایداری نیست.
