انتقال امن به HTTPS با کمک HSTS

با معرفی HTTPS تصور بر آن بود که این پروتکل می‌تواند به‌طور کامل تضمین‌کننده‌ی امنیت ارتباطات بر بستر اینترنت باشد، اما آن‌چه از نظر دور مانده بود پیشینه‌ی این پروتکل یعنی HTTP بود. کشف آسیب‌پذیری امنیتی هنگام انتقال یک آدرس از HTTP به HTTPS محققان را بر آن داشت تا روشی به‌منظور الزام بر برقراری ارتباط صرفن بر پایه‌ی HTTPS پیدا کنند و این روش HSTS نام داشت.

شناسایی مساله

تصور کنید در یک عصر دل‌انگیز، در کافی‌شاپ مورد علاقه‌ی خود نشسته‌اید و قصد دارید تا از سکوت و آرامش این محیط بیش‌تر بهره را ببرید و کارهای خود را نیز که بخش عمده‌ای از آن‌ها امور اینترنتی هستند، انجام دهید. مانند همیشه به شبکه‌ی Wi-Fi کافی‌شاپ متصل می‌شوید و از اینترنت رایگانی که این مجموعه در اختیار شما قرار داده، استفاده می‌کنید. به‌ظاهر همه‌چیز عالی است و هیچ مشکلی وجود ندارد.

اما در همین حال که شما در فضای آرام کافی‌شاپ مشغول انجام کارهای خود هستید و از ضعف امنیتی این ‌شبکه Wi-Fi عمومی خبر ندارید، شخصی در ساختمانی حوالی آن‌جا در اتاق خود نشسته و با نرم‌افزاری که به‌رایگان از اینترنت دانلود کرده، با خونسردی در حال شنود ترافیک (یا به عبارتی اطلاعات) در حال دریافت و ارسال روی شبکه‌ی Wi-Fi کافی‌شاپ است.

ممکن است این پرسش در ذهن شما ایجاد شود که «شنود ترافیک از جانب این شخص مگر چه مشکلی می‌تواند برای من ایجاد کند؟ یا این شخص با شنود این ترافیک، مگر چه اطلاعاتی می‌تواند به‌دست آورد که ممکن است برای من خطرناک و مشکل‌ساز باشد؟»

پیش از پاسخ به این پرسش‌ها، بهتر است نخست به این امر بپردازیم که هنگام استفاده از مرورگر یا نرم‌افزارهای مختلفی که می‌توانند به اینترنت وصل شوند و داده‌هایی را ارسال و دریافت کنند، چه اتفاقی می‌افتد.

پروتکل HTTP

(Hypertext Transfer Protocol (HTTP پروتکل مسوول انتقال اطلاعات (متن، عکس، فیلم و…) میان دستگاه‌ها روی (World Wide Web (www است.

زمانی‌که در مرورگر خود صفحه‌ای را جست‌وجو یا به‌شکل مستقیم با درج آدرس باز می‌کنیم در واقع در حال استفاده از HTTP هستیم. البته گفتنی است که این پروتکل، تنها پروتکل مورد استفاده‌ی مرورگرها نیست. تقریبن هر ابزاری که به اینترنت متصل می‌شود از همین پروتکل برای انتقال داده‌های خود بهره می‌گیرد.

طرح اولیه‌ی این پروتکل نخستین‌بار در سال 1991 با نام HTTP 0.9 را  Tim Berners-Leeارایه داد، اما HTTP 0.9 صرفن طرحی ابتدایی بود که نیاز به کار فراوان داشت. در سال 1996، کارگروه (HTTP (HTTP-WG در IETF نخستین RFC را در رابطه با این پروتکل با نام HTTP 1.0 در قالب RFC 1945 به ثبت رساندند اما این RFC نیز به یک RFC استاندارد تبدیل نشد. شش ماه پس از ارایه‌ی این RFC، در سال 1997 درنهایت نسخه‌ی استاندارد RFC این پروتکل با نام HTTP 1.1 در قالب RFC 2068 به ثبت رسید.

در این سال‌ها که HTTP در حال توسعه و ارتقا بود، یک ضعف امنیتی جدی در آن پیدا شد؛ در این پروتکل هیچ روشی برای رمزنگاری داده‌ها در نظر گرفته نشده بود. بدین معنا که، تمام داده‌هایی که به‌وسیله‌ی این پروتکل میان دو سیستم بر بستر اینترنت تبادل می‌شدند، به‌راحتی به‌وسیله‌ی شخص سومی قابل شنود بودند.

برای نمونه تصور کنید، در مرورگر خود صفحه‌ی پرداخت بانکی را باز و اطلاعات کارت بانکی خود را وارد کرده‌اید و منتظر انجام تراکنش هستید. در طی باز کردن این صفحه‌ی پرداخت، میان مرورگر شما و سروری که وب‌سایت بانک روی آن قرار دارد، ارتباط HTTP برقرار شده است. حال اگر در همین زمان، شخص سومی ترافیک HTTP میان شما و سرور بانک را شنود کند، به تمام اطلاعات کارت بانکی شما دست یافته و می‌تواند از آن‌ها برای برآوردن مقاصد خود بهره گیرد.

ظهور HTTPS

روشی که برای حل مشکل امن نبودن HTTP ارایه شد، نسخه‌ای امن از آن با نام (Hypertext transfer protocol secure (HTTPS بود. HTTPS با بهره‌گیری از پروتکلی دیگر با نام (Transport Layer Security (TLS، ارتباطی امن میان دو سیستم (client و سرور) برقرار می‌کند.

TLS برای امن کردن ارتباطات از (Public Key Infrastructure (PKI یا زیرساخت کلید عمومی استفاده می‌کند. به‌شکل خلاصه این پروتکل برای برقراری ارتباط امن میان دو سیستم از سه مولفه بهره می‌گیرد:

• احراز هویتی دوطرفه (Authentication)
• امضای دیجیتال به‌منظور حفظ صحت ارتباط (Integrity)
• رمزنگاری اطلاعات به‌منظور حفظ حریم خصوصی (Encryption)

فارغ از عملکرد TLS، در آخرین سطح آن‌چه شما در مرورگر خود مشاهده می‌کنید و می‌توانید مطمین شوید که ارتباط مابین مرورگر شما و وب‌سایتی که در حال مشاهده اطلاعات آن هستید، HTTPS است، درج عبارت https:// به‌جای http:// در ابتدای آدرس سایت است.

با این توضیحات و اندکی دقت در آدرس سایت‌هایی که به‌تازگی از آن‌ها بازدید کرده‌اید احتمالن در حال حاضر به این فکر می‌کنید که «اکنون بیش‌تر سایت‌ها از HTTPS پشتیبانی می‌کنند. پس اگر شخصی ترافیک شبکه‌ی Wi-Fi کافی‌شاپ را شنود کند نمی‌تواند به اطلاعات من دسترسی پیدا کند!»

متاسفانه خبر بد آن است که هنوز هم احتمال شنود اطلاعات شما به‌وسیله‌ی آن شخص خونسرد نشسته در ساختمان مجاور وجود دارد.

ربودن گواهینامه‌ی SSL

برای پشتیبانی یک وب‌سایت از HTTPS، نخست باید برای آن گواهینامه‌ی SSL تهیه شود. گواهینامه‌های (TLS/SSL (TLS/SSL certificate را مراجع مسوول صدور گواهینامه‌های دیجیتال (certification authority (CA) صادر می‌کنند. به‌طور خلاصه، مرجع صدور گواهینامه، نقش سوم شخصی را در یک ارتباط دو (برای نمونه میان مرورگر و وب ‌سرور) یا چندطرفه ایفا می‌کند که برای طرفین این ارتباط یک شخص امن به‌شمار می‌آید و تضمین‌کننده‌ی آن است اطلاعاتی که در این ارتباط میان طرفین مبادله می‌شوند (که این اطلاعات شامل کلید عمومی (public key) و هویت شخص ارسال‌کننده‌ی این کلید می‌شود) همگی امن و مطمین هستند. CA با امضای (یا sign) گواهینامه‌ی SSL این ضمانت را انجام می‌دهد.

پس از دریافت گواهینامه‌ی SSL، ارتباط میان کاربران و سایت می‌تواند بر پایه‌ی HTTPS باشد. به‌ این ‌ترتیب، مسوول سایت برای وب‌سرور مشخص می‌کند که به هنگام دریافت درخواست دسترسی به سایت بر پایه‌ی HTTP، بی‌درنگ در پاسخ، با ارسال یک کد و آدرس سایت به همراه https، از درخواست‌کننده، برقراری ارتباط بر پایه‌ی HTTPS را تقاضا کند. کدی که وب‌سرور در این موقعیت ارسال می‌کند، HTTP code 301 یا 301 redirect است.

برای درک بهتر، تصویر زیر را در نظر بگیرید:

۱. کاربر در مرورگر خود آدرس http://example.com را وارد می‌کند و مرورگر روی TCP port 80 (که مورد استفاده‌ی HTTP است) درخواست دسترسی به این سایت را برای سرور ارسال می‌کند.

۲. سرور با دریافت این درخواست از سمت مرورگر، بلافاصله HTTP code 301 به همراه آدرس https://example.com را برای مرورگر ارسال می‌کند.

۳. مرورگر با دریافت این پیام از سمت سرور، این بار درخواستی را مبنی‌بر دسترسی به https://example.com روی پورت 443 (پورت مخصوص HTTPS) برای سرور ارسال می‌کند.

۴. با دریافت این درخواست، سرور گواهینامه‌ای حاوی امضای دیجیتال را برای مرورگر می‌فرستد.

۵. مرورگر با دریافت گواهی و مقایسه‌ی آن با فهرست مراجع صدور گواهینامه‌ی مجاز خود، گواهی را تصدیق می‌کند. در پی این تصدیق، ارتباط میان مرورگر و وب‌سرور برقرار شده و کاربر به اطلاعات سایت دسترسی پیدا می‌کند.

حال چه اتفاقی می‌افتد اگر در همان نقطه‌ی ابتدای این روند که ارتباط میان مرورگر و سرور بر پایه‌ی HTTP است، شخص سومی که در حال شنود این ارتباط است، میان مرورگر و سرور قرار گرفته و کد 301 ارسالی از جانب سرور، به‌جای مرورگرِ کاربر، به‌وسیله‌ی این مهاجم دریافت شده و مهاجم نیز به‌جای ارسال این کد برای مرورگر کاربر، صفحه‌ی جعلی خود که مشابه سایت اصلی و بر پایه‌ی HTTP است، برای مرورگر کاربر ارسال کند؟

برای درک بهتر این موضوع تصویر زیر را در نظر گیرید:

مشابه مورد قبل، مرورگر کاربر درخواستی را مبنی‌بر دسترسی به http://example.com برای سرور ارسال می‌کند. اما در این‌جا یک مهاجم در حال شنود این ارتباط است. به‌محض ارسال این درخواست از سمت مرورگر کاربر، شخص مهاجم وارد عمل می‌شود و ارتباط میان مرورگر و سرور را قطع می‌کند. هنگامی‌که سرور این درخواست را با کد 301 redirect پاسخ می‌دهد، مهاجم به‌جای ارسال این پیام به مرورگر کاربر، اطلاعات صفحه جعلی خود را برای مرورگر ارسال می‌کند و کاربر نیز از جعلی بودن این صفحه و آن‌چه در حال رخ دادن است، آگاه نمی‌شود.

مهاجم، درخواست https://example.com را برای سرور ارسال می‌کند و گواهینامه‌ی SSL را به‌دست می‌آورد. از سوی دیگر، کاربر که در جریان هیچ‌یک از این امور نیست، با وارد کردن اطلاعات خود (این اطلاعات می‌تواند اطلاعات کارت بانکی، گذرواژه‌ی یک شبکه‌ی اجتماعی، ایمیل یا… باشد) در صفحه‌ی جعلی مهاجم، این اطلاعات را در اختیار مهاجم قرار می‌دهد. حال که مهاجم هم گواهینامه‌ی SSL و هم اطلاعات کاربر را دارد به‌راحتی می‌تواند از این اطلاعات سوءاستفاده کند.

به این حمله، SSL stripping attack گویند که یکی از انواع حملات Man-in-the-Middle است. نخستین‌بار این آسیب‌پذیری امنیتی را Moxie Marlinspike کشف کرد و این موضوع منجر به ایجاد مکانیسمی با نام HSTS شد.

انتقالی امن به HTTPS با (HTTP Strict Transport Security (HSTS

در پی کشف آسیب‌پذیری SSL stripping ، این موضوع مطرح شد که برخلاف تصور، ارتباط HTTPS همیشه نیز امن نیست. پس باید روشی برای حل این ضعف امنیتی ارایه می‌شد.

در سال 2012 طی RFC 6797، پروتکلی با نام HTTP Strict Transport Security (HSTS)‎ معرفی شد. این مکانیزم وب‌سایت‌ها را قادر می‌سازد تا تنها از طریق ارتباطات امن (یعنی ارتباطات HTTPS) دردسترس باشند و از سوی دیگر کاربران نیز تنها با وب‌سایت‌های پشتیبانی‌کننده از HTTPS، ارتباط برقرار کنند.

این پروتکل برای برآوردن این هدف از header مخصوص خود با نام Strict-Transport-Security بهره می‌گیرد. وب‌سرور با ارسال HSTS header برای مرورگر پشتیبانی‌کننده از HSTS، برقراری ارتباط بر پایه‌ی HTTPS در ارتباطات بعدی را مشخص می‌کند. به ‌این ‌ترتیب حتا اگر در مرورگر، آدرس سایت با http وارد شود، مرورگر پیش از برقراری هر ارتباطی، بی‌درنگ آدرس وارد شده را به https تغییر می‌دهد، سپس از طریق HTTPS ارتباط با وب‌سرور را برقرار می‌کند. هم‌چنین اگر لینک وارد شده را امن تشخیص ندهد، پیغام خطایی به کاربر نشان می‌دهد و اجازه دسترسی به آن سایت را نمی‌دهد.

در پیام ارسالی سرور برای مرورگر که حاوی HSTS header است، یک مدت‌زمان (به ثانیه) نیز مشخص می‌شود (فیلد max-age). این بازه‌ی زمانی مشخص‌کننده‌ی طول مدت اعتبار سیاست HSTS است. برای نمونه، یک HSTS header می‌تواند چیزی شبیه خط زیر باشد:

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

این هدر برای مرورگر مشخص می‌کند که سیاست HSTS به‌شکل تقریبی برای شش ماه پابرجاست. به این معنا که در شش ماه آینده هر زمان مرورگر قصد دسترسی به وب‌سایت را داشته باشد باید این ارتباط را از طریق HTTPS برقرار کند. از سوی دیگر، عبارت انتهای این خط نیز بیان‌گر آن است که این قانون افزون‌بر دامنه‌ی اصلی سایت، برای تمام زیردامنه‌های آن نیز صدق می‌کند.

احتمالن اکنون با خود می‌گویید «با این توضیحات، پس مشکل امنیتی ارتباطات HTTPS نیز حل می‌شود و دیگر جای نگرانی نیست!». اما، HSTS نیز دچار ضعف‌هایی بود.

نقاط ضعف HSTS

اول آن‌که، هنگامی مرورگر HSTS Header را دریافت می‌کند که برای نخستین بار با سرور ارتباط برقرار کند. پس در این نخستین ارتباط میان مرورگر و سرور، هم‌چنان احتمال برقراری ارتباط بر پایه‌ی HTTP وجود دارد.

دوم آن‌که، همان‌طور که در بخش قبل گفته شد، سیاست HSTS برای مدت‌زمان مشخصی دارای اعتبار است که این مدت‌زمان را max-age مشخص می‌کند. پس امکان آن‌که مرورگر پس از اتمام این زمان، از HTTP برای نخستین ارتباط با سرور استفاده کند، بالا خواهد بود.

برای حل این دو مشکل از فهرستی با نام HSTS Preload استفاده شد.

HSTS Preload List

HSTS Preload List، فهرستی از اسامی دامنه‌هایی است که از HSTS پشتیبانی می‌کنند و ارتباط با آن‌ها حتمن باید بر پایه‌ی HTTPS باشد. این فهرست در نرم‌افزار مرورگرهای پشتیبانی‌کننده از HSTS اصطلاحن hardcode می‌شود. به این معنا که، این فهرست به بخشی از کدهای اصلی نرم‌افزار مرورگر اضافه می‌شود و به هیچ روشی (مگر تغییر کدهای اصلی نرم‌افزار یا هنگام ارایه‌ی به‌روزرسانی از جانب سازندگان مرورگر) قابلیت تغییر یا حذف ندارد.

پس اگر در مرورگرهای پشتیبانی‌کننده از HSTS، یک دامنه‌ی HSTS حتا بدون https یا حتا بدون آن‌که قبلن به آن سایت رجوعی شده و HSTS header دریافت شده باشد، وارد شود بی‌درنگ با آن سایت از طریق HTTPS ارتباط برقرار می‌شود.

در حال حاضر مرورگرهای زیر از HSTS پشتیبانی می‌کنند:

• Google Chrome از نسخه‌ی 0.211.0 به بعد
• Firefox از نسخه 4 به بعد
• Safari از سیستم‌عامل OS X Mavericks به بعد
• Opera از نسخه 12 به بعد
• Internet Explorer 11
• Microsoft Edge
• مرورگر سیستم‌عامل BlackBerry 10

ابر آروان و HSTS

شما می‌توانید نام سایت خود را با دارا بودن شروط زیر به Preload List اضافه کنید:

• داشتن یک certificate معتبر
• انتقال تمام ترافیک‌های HTTP به HTTPS
• دردسترس بودن تمام زیردامنه‌ها تنها از طریق HTTPS
• ارسال هدری درست برای کاربران برای تنظیمات

البته نگران نباشید. ابر آروان تمام این موارد را به‌شکل خودکار برای شما انجام می‌دهد. تنها کافی است که شما نام دامنه‌ی خود را به گوگل اعلام کنید. برای انجام تنظیمات مربوط به HSTS می‌توانید راهنمای بخش تنظیمات HTTPS پنل ابر آروان چیست؟ را بخوانید.

در این مطلب سعی شد تا به بررسی چرایی ایجاد مکانیسم HSTS و عملکرد کلی آن پرداخته شود. هرچند HTTPS روشی برای رمزنگاری و ایجاد ارتباط امن میان سیستم‌هاست، اما پیاده‌سازی مکانیزم‌هایی هم‌چون HSTS نیز می‌تواند تضمینی بر الزام انجام این عمل باشد. بدیهی است هرچه تعداد سایت‌های بیش‌تری در HSTS Preload List ثبت شوند، امنیت در کل اینترنت نیز به همان میزان افزایش خواهد یافت.