پروتکل امن انتقال ابرمتن

پروتکل امن انتقال ابرمتن یا HTTPS (به انگلیسی: Hypertext Transfer Protocol Secure) یک پروتکل ارتباطی برای انتقال امن اطلاعات در شبکه‌های کامپیوتری است که به صورت خاص در اینترنت استفاده می‌شود. HTTPS شامل یک ارتباط بر روی پروتکل انتقال ابرمتن است که توسط امنیت لایه انتقال رمزگذاری می‌شود. مهم‌ترین اهداف استفاده از HTTPS اصالت‌سنجی وبگاه، حفاظت از حریم خصوصی و یکپارچگی داده‌های انتقالی است.

برای پروتکل کم کاربرد S-HTTP (انتقال ابرمتنِ امن)، پروتکل انتقال ابرمتن امن را ببینید.
HTTP
روش‌های درخواست
زمینه‌های سرآیند
  • Cookie
  • ETag
  • Location
  • HTTP referer
  • DNT
  • X-Forwarded-For
کدهای وضعیت

در نسخهٔ رایج پروتکل HTTPS اصالت‌سنجی وبگاه‌ها وجود دارد. این امر جلوی حملات مرد میانی[پانویس 1] را می‌گیرد. همچنین رمزگذاری ۲طرفه بین کلاینت[پانویس 2] (یا کارخواه) و سرور[پانویس 3] (یا کارگزار) از حملات شنود و تغییر بدون اجازه جلوگیری می‌کند.[1] در عمل، این ویژگی‌ها باعث می‌شود تا این پروتکل بتواند تا حد زیادی امنیت ارتباط کاربران را تأمین نماید.

در ابتدا از این پروتکل فقط برای انجام تراکنش‌های بانکی، ارسال ای‌میل‌های مهم و کارهای حساس دیگر بر روی وب جهانی استفاده می‌شد اما با گذشت زمان، استفاده از آن بیشتر و بیشتر می‌شود.[2][3] امن کردن ارتباطات کاربران، شناسایی وبگاه‌های معتبر و مخفی کردن هویت کاربران از جمله استفاده‌های نوین این پروتکل است.[4] البته باید توجه داشت که امنیت کامل کاربران تنها در صورتی تأمین می‌شود که تمامی محتویات وبگاه از طریق همین پروتکل منتقل شود. منابعی مانند فایل‌های اسکریپت، کوکی‌ها و غیره نمونه‌هایی هستند که انتقال غیرامن آن‌ها تهدید امنیتی محسوب می‌شود.[5]

دید کلی
تصویری از ابتدای یک آدرسِ HTTPS
حروف WWW نیز در تصویر نمایان است

یوآرآی‌های[پانویس 4] HTTPS ساختاری شبیه آدرس‌های پروتکل انتقال ابرمتن دارند با این تفاوت که آن‌ها با https آغاز می‌شوند. وجود کلمهٔ HTTPS در ابتدای آدرس، به مرورگر نشان می‌دهد که برای اتصال به وبگاه باید از امنیت لایه انتقال[پانویس 5] استفاده کند.[6][7] از آنجا که در این پروتکل حتی اگر یکی از طرفین هم اصالت‌سنجی شده باشد، امنیت برقرار خواهد شد، استفادهٔ آن در وب بسیار مناسب است. در اینترنت معمولاً وبگاه‌ها گواهی اصالت‌سنجی‌شده تهیه می‌کنند. کاربران با بررسی صحت گواهی وبگاه، می‌توانند از هویت وبگاه مطمئن شده و ارتباطی امن و غیرقابل شنود داشته‌باشند.[8][9]

HTTPS بر روی یک شبکه غیر امن، مانند اینترنت، یک بستر امن ایجاد می‌کند.[10] این امر به شرطی که گواهی وبگاه مقصد مورد تأیید و الگوریتم‌های مورد استفاده مناسب باشند، تا حد زیادی جلوی انواع حملات شنود و حملهٔ مرد میانی را می‌گیرد.[5]

از آنجایی که HTTPS، پروتکل امنیت لایه انتقال را به‌طور کامل در لایه‌ای در زیر HTTP قرار می‌دهد، تمامی محتویات بستهٔ HTTP رمزگذاری می‌گردد. این اطلاعات شامل نشانی وب[پانویس 6] (آدرس صفحهٔ مقصد)، پارامترهای ارسالی (مانند نامِ کاربری و کلمهٔ عبور)، سرآیندها و کوکی‌ها می‌شوند. اما از آنجا که لایهٔ TCP/IP[پانویس 7] به آدرس IP و شمارهٔ درگاه نیازمند است، پروتکل HTTPS نمی‌تواند از آن‌ها محافظت کند. برای مثال در یک ارتباط امن با وبگاه گوگل، هیچ‌کس نمی‌تواند از روی بستهٔ کاربر متوجه محتویات درخواست او شود؛ اما از روی بسته می‌توان به آدرس، شماره درگاه، حجم اطلاعات انتقالی و طول مدت ارتباط دست یافت.[1]

مرورگرهای وب با استفاده از مراجع صدور گواهی دیجیتال که به صورت پیش‌فرض در درون آن‌ها نصب شده‌است، می‌توانند صحت یا جعلی بودن گواهی یک وبگاه را تشخیص دهند.[11][12][13] این بدان معنی است که کاربران به صورت پیش‌فرض از طریق مرورگر به شرکت‌های صادرکننده گواهی‌های دیجیتال (مانند شرکت وری‌ساین، مایکروسافت و غیره) اعتماد می‌کنند تا گواهی‌های وبگاه‌های مختلف را برایشان تأیید نمایند؛ بنابراین یک اتصال HTTPS به یک وبگاه امن است اگر و تنها اگر تمام موارد زیر صدق کند:

  1. کاربر مطمئن باشد که نرم‌افزار مرورگرش به درستی HTTPS را پیاده‌سازی کرده و مراجع مورد اعتمادی را در خود قرار داده‌است.
  2. کاربر مطمئن باشد که مراجع، تنها وبگاه‌های قانونی را تأیید می‌کنند و دچار اشتباه نمی‌شوند.
  3. وبگاه یک گواهی معتبر داشته باشد که توسط یکی از مراجع مورد اعتماد کاربر تأیید شده‌است.
  4. گواهی ارسال شده از طرف وبگاه مربوط به خود وبگاه یا شرکت اداره‌کنندهٔ آن باشد.[14] (مثلاً گواهی وبگاه گوگل باید برای شرکت گوگل (به انگلیسی: Google Inc.) صادر شده باشد. نه شرکتی دیگر)
  5. کاربر مطمئن باشد که روش‌های استفاده شده برای رمزگذاری در امنیت لایه انتقال برای جلوگیری از شنود کارا هستند.

استفاده از HTTPS در شبکه‌های عمومی (مانند شبکه‌های وای-فای) بسیار ضروری است. در این شبکه‌ها امکان شنود بسته‌ها به راحتی برای تمام افراد حاضر در شبکه وجود دارد.[1] همچنین گزارش‌هایی از ارائه دهندگان سرویس شبکه محلی بی‌سیم نشان می‌دهد که این شرکت‌ها از اطلاعات مشتریان خود سوءاستفاده کرده و در بعضی از موارد با استفاده از تغییر در ارتباط، تبلیغات خود یا حتی بدافزارهایی را به سیستم مشتری‌ها منتقل کرده‌اند.[15] بنابراین بهتر است تمامی اطلاعات بر روی این نوع شبکه‌ها توسط پروتکل‌های امن منتقل شود.

بر اساس آمارهای منتشر شده تا تاریخ ۲ اوت سال ۲۰۱۷ میلادی، از حدود ۱۴۰هزار وبگاه معتبر، ۶۰٪ این پروتکل امن را پیاده‌سازی کرده و از آن استفاده می‌کنند.[16]

در مرورگرها

تقریباً تمامی مرورگرهای وب در صورت دریافت یک گواهی نامعتبر به اشکال مختلف به کاربر هشدار می‌دهند.[13] برخی از مرورگرهای قدیمی‌تر، با نمایش یک جعبه هشدار[پانویس 8] وضعیت را به کاربر گزارش داده و برای ادامهٔ کار از او اجازه می‌گرفتند. اما مرورگرهای جدیدتر معمولاً با هشدارهای واضح که تمامی صفحه را پر می‌کنند، سعی در مطلع ساختن کاربر از خطرهای احتمالی را دارند. (مانند تصاویر)[17][18] همچنین علامت‌هایی مانند کلید یا سبز یا قرمز شدن نوار آدرس در مرورگرهای مختلف نشانهٔ مورد تأیید یا جعلی بودن گواهی ارائه شده توسط وبگاه است.[19][20] امروزه بسیاری از مرورگرها در صورتی که محتویات صفحه مخلوطی از پروتکل امن و غیر امن HTTP باشد، به کاربر هشدار خواهند داد.[21][22]

مقایسهٔ انواع گواهی‌های دیجیتال
(از مرورگر فایرفاکس برای نمونه‌برداری استفاده شده‌است)
اخطار درهنگام مشاهدهٔ گواهی نامعتبر
اخطار درهنگام مشاهدهٔ گواهی نامعتبر 
مرورگرها هنگامی که با گواهی‌های معتبر گستردهٔ تاییدشده[پانویس 9] مواجه می‌شوند، قفل سبز رنگ را به‌نمایش درمی‌آورند.
مرورگرها هنگامی که با گواهی‌های معتبر گستردهٔ تاییدشده[پانویس 10] مواجه می‌شوند، قفل سبز رنگ را به‌نمایش درمی‌آورند. 
مرورگرها هنگامی که با گواهی‌های عادی مواجه می‌شوند، قفل آبی رنگ را نمایش می‌دهند.
مرورگرها هنگامی که با گواهی‌های عادی مواجه می‌شوند، قفل آبی رنگ را نمایش می‌دهند. 

مرورگر فایرفاکس از نسخهٔ ۱۴، براساس اعلام خود، جهت «محافظت از کاربران در برابر زیرساخت‌هایی از شبکه که منجر به جمع‌آوری اطلاعات یا تغییر و سانسور کردن نتایج جستجو می‌شوند» به صورت پیش‌فرض جستجوهای وبگاه گوگل را با پروتکل HTTPS انجام می‌دهد.[23][24]

بنیاد مرزهای الکترونیکی[پانویس 11] که عقیده دارد «در یک دنیای آرمانی، تمامی درخواست‌های شبکه وب به‌طور پیش‌فرض امن خواهند بود»، اقدام به انتشار افزونه‌ای برای مرورگرهای فایرفاکس، گوگل‌کروم و کرومیوم به نام HTTPS Everywhere (همه‌جا HTTPS) نموده‌است. این افزونه تمامی صفحات ممکن را با استفاده از این پروتکل امن نمایش می‌دهد.[25]

دید فنی

تفاوت‌ها با HTTP

بر خلاف نشانی‌های وب[پانویس 6] HTTP که با «http://» آغاز می‌شوند و به صورت پیش‌فرض از درگاه شمارهٔ ۸۰ استفاده می‌کنند، آدرس‌های HTTPS با «https://» آغاز شده و به صورت پیش‌فرض از شماره درگاه ۴۴۳ استفاده می‌کنند.[26]

HTTP امن نیست و می‌تواند هدف حمله‌های مرد میانی[پانویس 1] و شنود[پانویس 12] قرار بگیرد. این حملات به مهاجم اجازه می‌دهد به اطلاعات حساس مانند حساب‌های کاربر دسترسی پیدا کند. HTTPS با این هدف طراحی شده‌است که جلوی چنین حملاتی را بگیرد و از این جهت امن است.[1] (به استثنای نسخه‌های کنارگذاشته‌شده و قدیمی‌تر آن)

سرعت پروتکل HTTPS، به ویژه در صفحاتی با محتوای زیاد، معمولاً از پروتکل غیر امن آن کمتر است. ارسال گواهی، تأیید گواهی توسط مرورگر و سربار رمزگذاری بر روی سیستم از مهم‌ترین دلایل این کندی هستند. یک اتصال امن در شروع حدوداً ۱۰٪ کندتر از یک اتصال غیر امن است. اما با استفاده از اتصال پایا این کندی در ادامهٔ ارتباط تقریباً از بین می‌رود.[27]

لایه‌های شبکه

HTTP در بالاترین لایهٔ مدل TCP/IP[پانویس 7] یعنی لایهٔ کاربرد عمل می‌کند. نسخهٔ امن آن نیز به صورت زیرلایه‌ای در همین لایه فعال می‌شود. HTTPS قبل از رسیدن بستهٔ HTTP به لایهٔ پایینی (لایهٔ انتقال)، آن را رمزگذاری می‌کند (در هنگام دریافت پاسخ، رمزگشایی می‌کند). به صورت ساده، HTTPS پروتکل جدایی نیست، بلکه همان پروتکل HTTP است بر روی امنیت لایه انتقال.[پانویس 5][10]

در یک بستهٔ HTTPS همهٔ اطلاعات لایهٔ HTTP ازجمله نشانی وب،[پانویس 6] سرآیندها، کوکی‌ها و اطلاعات ارسالی رمزگذاری می‌شوند.[10] یک حمله‌کننده پس از نفوذ می‌تواند متوجه آدرس آی‌پی مقصد، مدت زمان ارتباط و میزان اطلاعات ردوبدل‌شده شود. اما هیچ‌چیز از محتویات ارتباط برای او فاش نخواهد شد.[1]

نصب بر روی سرور

برای اینکه یک سرور وب بتواند اتصالات امن HTTPS را پشتیبانی کند، مدیر سرور[پانویس 13] باید یک گواهی کلید عمومی[پانویس 14] برای آن سرور تهیه کرده و آن را بر روی سرور نصب نماید.[28] این گواهی باید توسط یک مرجع صدور گواهی دیجیتال تأیید شود تا مرورگرها بتوانند بدون اخطار، صفحه را برای کاربر نمایش دهند. مرورگرها به صورت پیش‌فرض به تعدادی از مراجع صدور گواهی اعتماد دارند.

تهیهٔ گواهی معتبر

تهیهٔ یک گواهی دیجیتال معتبر می‌تواند رایگان یا بین ۸ تا ۱‍۵۰۰ دلار در سال هزینه داشته باشد.[29][30][31] البته باید توجه داشت که در بعضی موارد مراجع صدور گواهی رایگان مانند شرکت CACert در مرورگرهای مشهور (مانند فایرفاکس، گوگل کروم و اینترنت اکسپلورر) معتبر شناخته نمی‌شوند.[29]

مؤسسات و شرکت‌های بزرگ، در صورتی که مسئول نصب و راه‌اندازی مرورگرها در محیط کار خود باشند، می‌توانند با نصب گواهی خودشان بر رور مرورگرها، آن‌ها را در محیط کار تأیید کنند (برای مثال یک وبگاه در شبکهٔ داخلی یک شرکت بزرگ یا دانشگاه). این مؤسسات می‌توانند به راحتی کپی گواهی خود را بر روی مراجع مورد تأیید مرورگرها نیز ثبت کنند.[32]

استفاده برای مدیریت دسترسی کاربران

یکی دیگر از استفاده‌های سیستم HTTPS و گواهی‌های آن، احراز هویت کاربران برای مشخص نمودن سطح دسترسی آن‌ها در وبگاه است. برای انجام این کار دو راه وجود دارد:

  1. کاربران از مراجع معتبر صدور گواهی، گواهی تهیه کرده و آن را بر روی سیستم خوب نصب نمایند.
  2. مدیر وبگاه باید به ازای هر کاربر یک گواهی ایجاد و آن را بر روی سیستم کاربر نصب نماید.

این گواهی‌ها در درون خود اطلاعاتی مانند نام، نامِ خانوادگی و آدرس ای‌میل کاربر را ذخیره می‌کنند. این اطلاعات با هر بار اتصال به وبگاه، توسط سرور بررسی شده و کاربر بدون نیاز به ورود نام کاربری یا کلیدواژه شناسایی خواهد شد.[33]

لو رفتن گواهی (کلید خصوصی)

با به وجود آمدن سیاست Perfect Forward Secrecy در پروتکل HTTPS، لو رفتن و دزدیده شدن یک کلید خصوصی منجر به به‌دست آمدن کلیدهای جلسه‌ها و ارتباطات قبلی یا بعدی نمی‌شود.[34] پروتکل تبادل کلید دیفی-هلمن[پانویس 15] و تبادل کلید خم بیضوی دیفی-هلمن[پانویس 16] تنها الگوریتم‌هایی هستند که تاکنون (سال ۲۰۱۳) از این سیاست پیروی می‌کنند. البته این الگوریتم‌ها سربار زیادی را به دلیل رمزنگاری پیچیده بر روی سرور و کلاینت خواهند گذاشت.[35]

اما این سیاست هنوز گسترده نشده‌است. در حال حاضر تنها ۳۰٪ اتصالات مرورگرهای فایرفاکس، گوگل‌کروم و اپرا از این روش‌ها استفاده می‌کنند. این در حالی است که مرورگر سافاری و اینترنت اکسپلورر هیچ‌گاه از این الگوریتم‌ها استفاده نمی‌کنند.[36] از میان یاهو، مایکروسافت، پی‌پال، اپل، اچ‌پی، دل، گوگل و تعداد بسیاری از شرکت‌های بزرگ اینترنتی، تنها شرکت گوگل از این سیاست برای امنیت وبگاه‌های خود استفاده می‌کند.[37][38]

یک گواهی ممکن است قبل از این‌که منقضی شود، باطل گردد. دلایلی مانند لو رفتن کلید خصوصی یا دلایل امنیتی دیگر از جمله مواردی است که منجر به این موضوع می‌گردد. نسخه‌های جدید مرورگرهای مشهور مانند گوگل‌کروم، فایرفاکس، اینترنت‌اکسپلورر (از ویندوز ویستا به بعد) پروتکل برخط وضعیت گواهی[پانویس 17] را پیاده‌سازی کرده‌اند. به کمک این پروتکل مرورگرها می‌توانند باطل شدن گواهی‌های دیجیتال پیش از موعد را بررسی کنند. این عمل با ارسال شماره‌سریال گواهی به مرجع آن صورت می‌گیرد.[39]

محدودیت‌ها و مشکلات

پروتکل HTTPS دو حالت مختلف را پشتیبانی می‌کند: حالت ساده[پانویس 18] و حالت متقابل یا دوطرفه.[پانویس 19][40]

حالت دوطرفه امنیت بیشتری دارد اما برای استفاده از آن علاوه بر سرور، کاربر نیز باید گواهی تهیه کرده و بر روی سیستمِ خود نصب نماید.[40]

هر کدام از این دو حالت که استفاده شوند، امنیت ارتباط به شدت به پیاده‌سازی و الگوریتم رمزنگاری استفاده‌شده دارد. سیستم‌های مختلف بارها به دلیل مشکلاتی که در پیاده‌سازی آن‌ها وجود دارد، مورد حمله قرار گرفته‌اند.[41][42]

استفاده از ارتباط امن جلوی خزنده‌های وب را نمی‌گیرد. این خزنده‌ها به راحتی صفحات امن را نیز فهرست می‌کنند. در بسیاری از موارد آدرس صفحات وبگاه تنها از روی حجم درخواست و پاسخ رمزنگاری شده، قابل افشا است.[43] این مسئله می‌تواند به یک مهاجم این امکان را بدهد که به متن رمز شده و رمز نشده دسترسی پیدا کند. این دسترسی می‌تواند امکان حمله متن رمز شده انتخابی[پانویس 20] را فراهم سازد.

از آنجایی که پروتکل HTTPS در لایهٔ زیرین HTTP فعالیت می‌کند، هیچ اطلاعی از عملکردِ لایه‌های بالاتر ندارد. هر سرور می‌تواند برای هر جفت آدرس IP و شماره درگاه خود یک گواهی به کاربر ارائه نماید.[44] به همین دلیل در بسیاری از موارد نمی‌توان در سرورهایی که میزبانی مجازی مبتنی بر نام ارائه می‌دهند، از پروتکل HTTPS استفاده نمود. با این حال راه‌حلی به نام تشخیص نام سرور[پانویس 21] وجود دارد که نام وبگاه[پانویس 22] را قبل از آغاز رمزگذاری ارسال می‌کند. این قابلیت در مرورگرهای قدیمی پشتیبانی نمی‌شود. مرورگر فایرفاکس از نسخهٔ ۲ به بالا، اپرا از نسخهٔ ۸ به بالا، سافاری از نسخهٔ ۲٫۱ به بالا، گوگل کروم از نسخهٔ ۶ به بالا و اینترنت اکسپلورر ۷ به بالا از این قابلیت پشتیبانی می‌کنند.[45][46]

برهنه‌سازی

در کنفرانس کلاه‌سیاه در سال ۲۰۰۹ یک حملهٔ پیچیده به نام برهنه‌سازی[پانویس 23] گزارش شد. در این نوع حمله مهاجم با تغییر آدرس از پروتکل "https" به "http" کاربر را گمراه می‌کند. کاربر فکر می‌کند که ارتباط او امن است، در حالی که مهاجم به راحتی می‌تواند حملهٔ مرد میانی[پانویس 1] را ترتیب دهد.[47] در این نوع حمله از این نکته استفاده می‌شود که اکثر کاربران خودشان قسمت "https://" را در نوار آدرس تایپ نمی‌کنند و معمولاً با کلیک بر روی یک لینک به صفحهٔ امن منتقل می‌شوند.[48]

حملهٔ کانال‌های جانبی

در ماه مه سال ۲۰۱۰ طبق تحقیقاتی که تیم تحقیقات مایکروسافت با همکاری دانشگاه هند انجام دادند، مشخص شد که بسیاری از اطلاعات حساسی که از طریق HTTPS منتقل می‌شوند، از طریق روش‌ها و کانال‌های جانبی[پانویس 24] مانند مشاهدهٔ حجم بسته، برای مهاجمین قابل دسترسی هستند. به‌طور مشخص‌تر، محققان نشان دادند که با شنود بر روی ارتباطات امن نرم‌افزارها و وبگاه‌های بیمارستان‌ها، بانک‌ها و جستجوهای وب می‌توانند میزان درآمد، بیماری و نوع آن، داروهای مورد استفاده، عمل‌های جراحی صورت گرفته بر روی فرد و افراد خانوادهٔ او را تشخیص دهند.[49]

حملهٔ BEAST

در کنفرانس امنیتی اکوپارتی[پانویس 25] در سال ۲۰۱۱ که در کشور آرژانتین برگزار شد، دو نفر از محققین امنیتی به نام‌های جولیانو ریزو[پانویس 26] و ثای دونگ،[پانویس 27] که از توسعه‌دهندگان مرورگر گوگل‌کروم نیز می‌باشند، حملهٔ جدیدی را بر روی HTTPS گزارش دادند. این حمله که از طریق یک حفرهٔ امنیتی و به کمک تکه‌کد جاوااسکریپت صورت می‌گیرد، می‌تواند به مهاجم این امکان را می‌دهد که متن رمز شده را در یک زمان کوتاه به‌طور کامل رمزگشایی کند. این حمله BEAST نام گرفت که مخفف Browser Exploit Against SSL/TLS است.[50][51] این حمله حتی در وبگاه‌هایی که از پروتکل امنیت انتقال سخت‌گیرانهٔ HTTP[پانویس 28] استفاده می‌کنند قابل اجراست.[52]

این اشکال بر روی SSL نسخهٔ ۳ به پایین و TLS نسخهٔ ۱ که در زمان گزارش حمله در امنیت لایه انتقال پرکاربرد بودند، وجود دارد. در نسخه‌های بعدی TLS(نسخه‌های ۱٫۱ و ۲) این مشکل برطرف شد. امروزه مرورگرهای مشهور به صورت پیش‌فرض نسخه‌های قدیمی این پروتکل‌ها را غیرفعال می‌کنند تا از این حمله در امان باشند.[51]

حملهٔ CRIME

این حمله که مخفف عبارت Compression Ratio Info-leak Made Easy است، در سپتامبر سال ۲۰۱۲ در کنفرانس اکوپارتی[پانویس 25] گزارش شد. در این حمله مهاجم می‌تواند به کوکی‌هایی که از طریق HTTPS و پروتکل اسپیدی[پانویس 29] منتقل می‌شوند، دسترسی پیدا کند. برای جلوگیری از این حمله، کاربران باید پروتکل اسپیدی را در مرورگر خود غیرفعال نمایند.[53]

این حمله نیز توسط جولیانو ریزو[پانویس 26] و ثای دونگ[پانویس 27] گزارش شد.[53]

حملهٔ BREACH

این حمله که آخرین حملهٔ گزارش شده تاکنون می‌باشد، در ماه اوت سال ۲۰۱۳، توسط کارشناسان امنیتی گزارش شده‌است. نام این نوع حمله از مخفف کردن عبارت Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext گرفته شده‌است. BREACH که به مهاجمین اجازهٔ رمزگشایی بسته‌های HTTPS را می‌دهد با عنوان «HTTPS در کمتر از ۳۰ ثانیه هک می‌شود» در رسانه‌ها بازتاب یافت. تمامی وبگاه‌هایی که از فشرده‌سازی HTTP[پانویس 30] استفاده می‌کنند، در برابر این نوع حمله آسیب‌پذیرند. همچنین اشکالی که از آن استفاده شده‌است در تمامی نسخه‌های SSL و TLS وجود دارد.[54][55]

تا کنون هیچ راه‌حلی برای مقابله با این حمله ارائه نشده‌است.[56]

در ایران

استفاده از پروتکل HTTPS در ایران گاهی دچار مشکل شده و با کاهش سرعت یا قطع دسترسی مواجه می‌شود.[57][58] بسیاری معتقدند که دلایل این اختلالات، مسائل سیاسی و امنیتی است. مسئولین معمولاً این ادعا را رد می‌کنند[58] اما وزیر ارتباطات ایران در تیر ماه سال ۱۳۹۲ برای اولین بار اعلام کرد که دلیل افت سرعت اینترنت در زمان پیش از انتخابات، امنیتی و به دلیل انتخابات ریاست جمهوری ایران بوده‌است. وی این اقدام را راهکار و ابتکاری در جهت مقابله با ورود بیگانگان به فضای مجازی تعریف کرد.[59]

جعل گواهی گوگل و سرویس‌های آن

در ماه اوت سال ۲۰۱۱ میلادی شرکت گوگل اعلام کرد که یکی از گواهی‌های دیجیتال این شرکت که در مرجع دی‌جی‌نوتار[پانویس 31] در کشور هلند ثبت شده‌بود، به سرقت رفته‌است. تحقیقات نشان داد که منبع این سرقت کشور ایران بوده‌است. با انجام این حمله، مهاجمین توانستند در مقیاس‌های بزرگ به ویژه در داخل ایران حمله‌های مرد میانی و فیشینگ ترتیب‌دهند. بسیاری ادعا کردند که آی‌اس‌پی‌های بزرگ در ایران مانند پارس‌آنلاین و خود دولت با استفاده از این گواهی‌های دزدیده شده، از اطلاعات کاربران سوءاستفاده کردند.[60][61]

قابل ذکر است که گواهی دزدیده شده نه‌تنها مربوط به قسمت جستجوی وبگاه گوگل بود، بلکه در تمامی سرویس‌های گوگل از جمله جی‌میل، گوگل‌پلاس و غیره معتبر شناخته می‌شد. مرورگرهای مشهور با فاصله چند روز از انتشار این خبر، این مرجع را از لیست مراجع مورد تأیید خود حذف کردند. اما این گواهی ۴۰ روز قبل از انتشار این خبر دزدیده شده بود.[60]

کمپانی دی‌جی‌نوتار بعد از این اتفاق تعطیل شد.[62]

تاریخچه

کمپانی نت‌اسکیپ در سال ۱۹۹۴ میلادی HTTPS را بر پایهٔ اس‌اس‌ال در مرورگر خود(Netscape Navigator) به وجود آورد.[63] ساختار پروتکل به‌وجود آمده (اس‌اس‌ال) به‌گونه‌ای بود که قابلیت قرار گرفتن هر نرم‌افزار و سرویسی بر روی آن وجود داشت[64] با گذشت زمان پروتکل اس‌اس‌ال تغییر کرده و جای خود را به امنیت لایه انتقال داد. در واقع نسخهٔ بعد از نسخهٔ ۳٫۰ پروتکل اس‌اس‌ال، امنیت لایه انتقال نامیده‌شد. به همین دلیل عده‌ای این پروتکل را اس‌اس‌ال نسخهٔ ۳٫۱ نیز می‌نامند.[65] نسخه‌های بعدی پروتکل امنیت لایه انتقال با ایجاد تغییرات بزرگ، راه خود را از اس‌اس‌ال جدا کردند.[66] در نسخهٔ فعلی HTTPS که در ماه مه سال ۲۰۰۰ میلادی در RFC 2818 معرفی شده‌است، امنیت لایه انتقال به‌عنوان جایگزین پروتکل اس‌اس‌ال، در لایهٔ زیرین HTTPS قرار گرفته‌است.

جستارهای وابسته

معادل‌های انگلیسی
  1. Man in the Middle
  2. Client
  3. Server
  4. URI: Uniform Resource Identifier
  5. SSL/TLS
  6. URL: Uniform Resource Locator
  7. TCP/IP
  8. Alert Box
  9. Extended Validation Certificate
  10. Extended Validation Certificate
  11. EFF: Electronic Frontier Foundation
  12. Eavesdropping
  13. Server Administrator
  14. Public Key Certificate
  15. DHE: Diffie Hellman key exchange
  16. ECDHE: Elliptic curve Diffie-Hellman Key Exchange
  17. OCSP: Online Certificate Status Protocol
  18. Simple
  19. Mutual
  20. Chosen ciphertext attack
  21. SNI: Server Name Indication
  22. Host Name
  23. Stripping
  24. Side Channels
  25. Ekoparty Security Conference
  26. Juliano Rizzo
  27. Thai Duong
  28. HSTS: HTTP Strict Transport Security
  29. SPDY
  30. HTTP Compression
  31. DigiNotar

منابع
  1. HTTPS Everywhere FAQ, Electronic Frontier Foundation, retrieved September 21, 2013
  2. GlobalSign Reports SSL Growth Rates, The WHIR, September 18, 2008, retrieved September 24, 2013
  3. The Netcraft SSL Server Survey, Netcraft, January 2012, retrieved September 25, 2013
  4. Why SSL? The Purpose of using SSL Certificates, SSLShopper, retrieved September 25, 2013
  5. How to Deploy HTTPS Correctly, Electronic Frontier Foundation, retrieved September 11, 2013
  6. HTTP Over TLS: URI Format, IETF, May 2000, retrieved September 25, 2013
  7. What is a web site digital certificate and why is it important to check?, Australian Government, Communication Department, retrieved September 25, 2013
  8. HTTP Over TLS: Endpoint Identification, IETF, May 2000, retrieved September 25, 2013
  9. What is SSL and What are certificates?, TLDP Organization, retrieved September 25, 2013
  10. Overview of SSL/TLS Encryption, Microsoft Technet, July 31, 2003, retrieved October 1, 2013
  11. Mozilla Included CA Certificate List, Mozilla, retrieved September 25, 2013
  12. Root Certificate Policy - The Chromium Project, Chromium Organization, retrieved September 25, 2013
  13. Security Certificate Errors :: Certificate Is Not Trusted in Web Browser, DigiCert, retrieved September 25, 2013
  14. Understanding SSL Certificate Authentication, GeoCert, retrieved September 25, 2013
  15. Hotel Wifi JavaScript Injection, April 3, 2012, retrieved September 21, 2013
  16. Survey of the SSL Implementation of the Most Popular Web Sites, Trustworthy Internet Movement, September 2, 2013, retrieved September 14, 2013
  17. Ivan Ristic (April 29, 2008), Firefox 3 improves handling of invalid SSL certificates, retrieved September 25, 2013
  18. Has Firefox 3 certificate handling become too 'scary?', BetaNews, August 19, 2008, retrieved September 25, 2013
  19. How do I tell if my connection to a website is secure?, Mozilla Support, retrieved September 25, 2013
  20. What is that Green Padlock in your Browser Bar and why it is Important for You?, NetGenie, June 17, 2013, retrieved September 25, 2013
  21. Mixed Content, Mozilla Developers, retrieved September 25, 2013
  22. Eric Lawrence, Internet Explorer 9 Security Part 4: Protecting Consumers from Malicious Mixed Content, IEBLog, retrieved September 25, 2013
  23. Firefox 14.0.1 Changelog, Mozilla, July 24, 2012, retrieved September 15, 2013
  24. Firefox Rolling Out HTTPS Google search, Mozilla Blog, July 24, 2012, retrieved September 15, 2013
  25. HTTPS Everywhere, EFF, retrieved September 15, 2013
  26. HTTP Over TLS: Port Number، IETF
  27. Top 7 Myths about HTTPS, HttpWatch Blog, January 28, 2011, retrieved September 21, 2013
  28. SSL Certificate Installation Instructions & Tutorials, DigiCert, retrieved Ocotober 02, 2013 Check date values in: |تاریخ بازبینی= (help)
  29. Free SSL Certificates from a Free Certificate Authority, SSLShopper, retrieved September 21, 2013
  30. PositiveSSL Certificate, NameCheap, retrieved September 21, 2013
  31. Secure Site Pro SSL EV, Symantec Security, retrieved September 21, 2013
  32. Using a custom signed SSL key, PaperCut, retrieved Ocotober 02, 2013 Check date values in: |تاریخ بازبینی= (help)
  33. Joann Spera (March 02, 1998), SSL client authentication: It's a matter of trust, IBM: Developers Work, retrieved Ocotober 02, 2013 Check date values in: |تاریخ بازبینی=, |تاریخ= (help)
  34. Parker Higgins (August 28, 2013), Pushing for Perfect Forward Secrecy, an Important Web Privacy Protection, EFF, retrieved Ocotober 02, 2013 Check date values in: |تاریخ بازبینی= (help)
  35. The price to pay for perfect-forward secrecy, nmav's Blog, December 8, 2011, retrieved Ocotober 02, 2013 Check date values in: |تاریخ بازبینی= (help)
  36. Nikos Mavrogiannopoulos (September 2013), SSL: Intercepted today, decrypted tomorrow, Netcraft, retrieved September 21, 2013
  37. Langley, Adam (November 22, 2011), Protecting data for the long term with forward secrecy, Google Online Security Blog, retrieved September 21, 2013
  38. Michael Horowitz (June 21, 2013), Perfect Forward Secrecy can block the NSA from secure web pages, but no one uses it, Computerworld Blog, retrieved September 21, 2013
  39. RFC 2560, IETF, June 1999, retrieved September 21, 2013
  40. Elvin Cheng (February 08, 2012), An Introduction to Mutual SSL Authentication, retrieved Ocotober 02, 2013 Check date values in: |تاریخ بازبینی=, |تاریخ= (help)
  41. Remote Timing Attacks are Practical (PDF), Stanford University, retrieved October 7, 2013
  42. Secure servers compromised by SSL bug, TechWorld, October 05, 2013, retrieved October 07, 2013 Check date values in: |تاریخ بازبینی=, |تاریخ= (help)
  43. The Pirate Bay un-SSL, Stas'den, July 13, 2008, retrieved September 21, 2013
  44. Apache FAQ, Apache, retrieved September 21, 2013
  45. What is Server Name Indication (SNI)?, Networking4All, retrieved October 07, 2013 Check date values in: |تاریخ بازبینی= (help)
  46. SSL with Virtual Hosts Using SNI, Httpd Wiki, retrieved October 07, 2013 Check date values in: |تاریخ بازبینی= (help)
  47. sslstrip, May 15, 2011, retrieved September 21, 2013
  48. HTTPS stripping attack using SSLstrip, February 14, 2011, retrieved October 07, 2013 Check date values in: |تاریخ بازبینی= (help)
  49. Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow (PDF), Microsoft Research, retrieved September 21, 2013
  50. Schwartz, Mathew (September 10, 2011), HTTPS Vulnerable To Crypto Attack, InformationWeek Security, retrieved September 21, 2013
  51. Chloe Nottle (November 2011), Server Technologies - HTTPS BEAST Attack, Context Information Security, retrieved September 21, 2013
  52. Goodin, Dan (September 19, 2011), Hackers break SSL encryption used by millions of sites, The Register, retrieved September 21, 2013
  53. Details on the "Crime" Attack, iSecPartners, September 14, 2012, retrieved September 21, 2013
  54. SSL, GONE IN 30 SECONDS, retrieved September 21, 2013
  55. Schwartz, Mathew (August 5, 2013), HTTPS Hackable In 30 Seconds: DHS Alert, retrieved September 21, 2013
  56. BREACH Compression Attack Steals HTTPS Secrets in Under 30 Seconds, Threat Post, August 5, 2013, retrieved September 21, 2013
  57. «کاهش سرعت اینترنت». عصر ایران. ۲۱ بهمن ۱۳۹۰. بایگانی‌شده از روی نسخه اصلی در ۲۵ اکتبر ۲۰۱۳. دریافت‌شده در ۲۵ شهریور ۱۳۹۲.
  58. «اختلالات اینترنت تکراری شده‌است». عصر ایران. ۲ خرداد ۱۳۹۲. بایگانی‌شده از روی نسخه اصلی در ۲۲ سپتامبر ۲۰۱۳. دریافت‌شده در ۲۵ شهریور ۱۳۹۲.
  59. «دلیل افت سرعت اینترنت امنیتی بود». عصر ایران. ۶ تیر ۱۳۹۲. بایگانی‌شده از روی نسخه اصلی در ۱۵ سپتامبر ۲۰۱۳. دریافت‌شده در ۲۵ شهریور ۱۳۹۲.
  60. Fraudulent Google credential found in the wild, The Register, August 29, 2011, retrieved September 21, 2013
  61. «هکرها کاربران گوگل در ایران را هدف گرفتند». بی‌بی‌سی فارسی. ۱ سپتامبر ۲۰۱۱. بایگانی‌شده از روی نسخه اصلی در ۲۱ سپتامبر ۲۰۱۳. دریافت‌شده در ۱۶ سپتامبر ۲۰۱۳.
  62. DigiNotar dies from certificate hack caper, Computer World, September 21, 2011, retrieved September 21, 2013
  63. Colin Walls, Embedded Software: The Works - Chapter 8: Introduction, retrieved September 21, 2013
  64. History of SSL, iSeries Information Center, IBM, retrieved October 21, 2013
  65. SSL versus TLS – What’s the difference?, LuxSci, retrieved October 21, 2013
  66. SSL vs. TLS: The Future of Data Encryption, Tom's Guide, September 06, 2013, retrieved October 21, 2013 Check date values in: |تاریخ= (help)
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.