واسطه های مخرب را با امنیت حمل و نقل HTTPS و HTTP گیج کنید

با توجه به حجم داده‌های شخصی که از طریق سری بزرگ لوله‌ها که اینترنت است، جریان می‌یابد، رمزگذاری چیزی نیست که بتوانیم یا باید به راحتی نادیده بگیریم. مرورگرهای مدرن مکانیسم‌های مختلفی را ارائه می‌کنند که می‌توانید از آنها برای اطمینان از ایمن بودن داده‌های کاربران خود در حین انتقال استفاده کنید: کوکی‌های امن و امنیت حمل‌ونقل دقیق دو مورد از مهم‌ترین آنها هستند. آنها به شما این امکان را می دهند که به طور یکپارچه از کاربران خود محافظت کنید، اتصالات آنها را به 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

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

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

آیا این یک خط امن است؟

تغییر از HTTP متن ساده به اتصال HTTPS ایمن بهترین دفاع شما را در برابر واسطه ها ارائه می دهد. اتصالات HTTPS قبل از ارسال هرگونه داده، کل کانال را به صورت سرتاسر رمزگذاری می‌کند و خواندن یا تغییر داده‌ها را برای ماشین‌های بین شما و مقصدتان غیرممکن می‌کند.

Omnibox کروم جزئیات کاملی در مورد وضعیت اتصال ارائه می دهد.
Omnibox کروم جزئیات کاملی در مورد وضعیت اتصال ارائه می دهد.

امنیت ارائه شده توسط HTTPS ریشه در مفهوم کلیدهای رمزنگاری عمومی و خصوصی دارد. بحث عمیق درباره جزئیات (خوشبختانه) فراتر از محدوده این مقاله است، اما فرض اصلی نسبتاً ساده است: داده های رمزگذاری شده با یک کلید عمومی معین را فقط می توان با کلید خصوصی مربوطه رمزگشایی کرد. هنگامی که یک مرورگر برای ایجاد یک کانال امن، دست دادن HTTPS را آغاز می کند، سرور گواهی ارائه می دهد که تمام اطلاعات لازم را به مرورگر می دهد تا هویت خود را با بررسی اینکه سرور دارای کلید خصوصی مناسب است، تأیید کند. تمام ارتباطات از آن نقطه به بعد به گونه ای رمزگذاری می شود که ثابت کند درخواست ها به سرور احراز هویت شده تحویل داده شده و پاسخ ها دریافت می شوند.

بنابراین، HTTPS به شما اطمینان می دهد که با سروری صحبت می کنید که فکر می کنید با آن صحبت می کنید و هیچ کس دیگری به آن گوش نمی دهد یا بیت ها را روی سیم می چرخاند. این نوع رمزگذاری یک پیش نیاز مطلق برای امنیت در وب است. اگر برنامه شما در حال حاضر از طریق HTTPS تحویل داده نمی شود، در برابر حمله آسیب پذیر است. درستش کن Ars Technica یک راهنمای عالی برای دریافت و نصب گواهینامه (به صورت رایگان) دارد که توصیه می کنم برای جزئیات فنی به آن نگاهی بیندازید. پیکربندی از ارائه دهنده ای به ارائه دهنده دیگر و سروری به سرور دیگر متفاوت خواهد بود، اما فرآیند درخواست گواهی در همه جا یکسان است.

ایمن به صورت پیش فرض

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

این راه لطفا

هنگامی که کاربر از http://example.com/ بازدید می کند، با ارسال یک پاسخ 301 Moved Permanently با سرصفحه Location مناسب، او را به 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 ارسال نمی‌شوند.

بستن پنجره باز

تغییر مسیر شفاف به HTTPS به این معنی است که اکثر اوقات کاربران شما در سایت شما هستند، از یک اتصال امن استفاده می کنند. با این حال، فرصت کوچکی برای حمله باقی می‌گذارد: اتصال HTTP اولیه کاملاً باز است، در برابر حذف SSL و حملات مرتبط آسیب‌پذیر است. با توجه به اینکه یک مرد در وسط به درخواست اولیه HTTP دسترسی کامل دارد، می تواند به عنوان یک پروکسی بین شما و سرور عمل کند و بدون توجه به نیت سرور شما را در یک اتصال HTTP ناامن نگه دارد.

می‌توانید خطر این دسته از حملات را با درخواست از مرورگر برای اجرای HTTP Strict Transport Security (HSTS) کاهش دهید. ارسال سرصفحه HTTP Strict-Transport-Security به مرورگر دستور می دهد تا تغییر مسیر HTTP به HTTPS را در سمت سرویس گیرنده انجام دهد، بدون اینکه هرگز شبکه را لمس کند (این نیز برای عملکرد عالی است؛ بهترین درخواست، درخواستی است که شما مجبور نیستید انجام دهید. ساختن):

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

مرورگرهایی که از این هدر پشتیبانی می‌کنند (در حال حاضر فایرفاکس، کروم و اپرا: caniuse دارای جزئیات است ) یادداشت می‌کنند که این سایت خاص درخواست دسترسی فقط HTTPS کرده است، به این معنی که بدون در نظر گرفتن نحوه ورود کاربر به سایت، او از آن بازدید خواهد کرد. از طریق HTTPS حتی اگر http://example.com/ را در مرورگر تایپ کند، بدون اینکه هرگز اتصال HTTP برقرار کند، در HTTPS کار می کند. بهتر از آن، اگر مرورگر گواهی نامعتبر را تشخیص دهد (احتمالاً سعی در جعل هویت سرور شما دارد)، کاربران اجازه نخواهند داشت از طریق HTTP به کار ادامه دهند. این همه یا هیچ است، که عالی است.

مرورگر وضعیت HSTS سرور را پس از 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 تنها راه برای اطمینان از اینکه داده هایی که ارسال می کنید دست نخورده به گیرنده مورد نظر می رسد، حتی از راه دور مطمئن شوید. امروز باید اتصالات ایمن را برای سایت ها و برنامه های خود راه اندازی کنید. این یک فرآیند نسبتاً ساده است و به حفظ امنیت اطلاعات مشتریان شما کمک می کند. هنگامی که یک کانال رمزگذاری شده را در محل خود ایجاد کردید، باید کاربران را بدون توجه به اینکه چگونه به سایت شما می آیند با ارسال یک پاسخ HTTP 301 به طور شفاف به این اتصال امن هدایت کنید. سپس با افزودن کلمه کلیدی امن هنگام تنظیم کوکی ها، مطمئن شوید که تمام اطلاعات جلسه حساس کاربران شما فقط از آن اتصال ایمن استفاده می کند. پس از انجام همه این کارها، اطمینان حاصل کنید که کاربران شما هرگز تصادفاً از اتوبوس سقوط نخواهند کرد: با اطمینان از اینکه مرورگر آنها کار درستی را انجام می دهد با ارسال سرصفحه Strict-Transport-Security از آنها محافظت کنید.

راه اندازی HTTPS کار چندانی نیست و مزایای زیادی برای سایت شما و کاربران آن دارد. ارزش تلاش را دارد.

منابع

  • StartSSL گواهینامه های رایگان تأیید شده توسط دامنه را ارائه می دهد. شما نمی توانید آزادانه شکست دهید. البته صعود به درجه های بالاتر تأیید هم امکان پذیر است و هم قیمت مناسب.
  • تست سرور SSL : هنگامی که HTTPS را برای سرورهای خود تنظیم کردید، با اجرای آن از طریق تست سرور SSL Labs بررسی کنید که آن را به درستی انجام داده اید. شما یک گزارش خوب و دقیق دریافت خواهید کرد که به شما نشان می دهد آیا واقعاً آماده هستید یا خیر.
  • مقاله اخیر Ars Technica "ایمن سازی وب سرور خود با SSL/TLS" برای اطلاعات کمی بیشتر در زمینه جزئیات بیشتر در مورد پیچ ​​و مهره های راه اندازی یک سرور ارزش خواندن دارد.
  • مشخصات HTTP Strict Transport Security Security (RFC6797) برای تمام اطلاعات فنی در مورد هدر Strict-Transport-Security که احتمالاً می خواهید، ارزش بررسی را دارد.
  • هنگامی که شما واقعاً می دانید چه کاری انجام می دهید، یکی از گام های ممکن بعدی این است که تبلیغ کنید که سایت شما فقط باید از طریق مجموعه ای خاص از گواهی ها قابل دسترسی باشد. کارهایی در IETF در حال انجام است که به شما امکان می‌دهد این کار را از طریق هدر Public-Key-Pins انجام دهید. هنوز روزهای اولیه است، اما جالب است و ارزش دنبال کردن را دارد.