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

از ویکی‌پدیا، دانشنامهٔ آزاد
پرش به: ناوبری، جستجو
مقاله خوب
برای مشاهده ویکی‌پدیای فارسی بر روی پروتکل امن انتقال ابرمتن به نشانی https://fa.wikipedia.org مراجعه نمایید.
برای پروتکل کم کاربرد S-HTTP (انتقال ابرمتنِ امن)، پروتکل انتقال ابرمتن امن را ببینید.
HTTP
روش‌های درخواست
زمینه‌های سرآیند
کدهای وضعیت

پروتکل امن انتقال ابرمتن یا HTTPS (به انگلیسی: Hypertext Transfer Protocol Secure) یک پروتکل امن برای انتقال اطلاعات در شبکه‌های کامپیوتری می‌باشد که به صورت خاص برای استفاده در اینترنت توسعه یافته است. این استاندارد در واقع به خودی خود یک پروتکل نیست، بلکه با قرار گرفتن HTTP[پانویس ۱] بر روی پروتکل امنیت لایه انتقال[پانویس ۲] به‌وجود آمده‌است. به‌این‌ترتیب امنیت موجود در پروتکل امنیت لایهٔ انتقال به ارتباطات HTTP افزوده شده‌است.

HTTPS برای اطمینان از هویت سیستم‌های درون شبکه، از گواهی‌های X.۵۰۹ استفاده می‌کند.[۱][۲] بنابراین وجود مرجع صدور گواهی دیجیتال برای ایجاد گواهی، تشخیص اعتبار، امضا و مدیریت گواهی‌ها ضروری است.[۳] البته تحقیقات انجام شده در سال ۲۰۱۳ نشان داد که مسئلهٔ وجود مراجع صدور گواهی، خود به عنوان تهدید امنیتی مطرح می‌شود. سوءاستفادهٔ دولت‌ها از گواهی‌های غیر مجاز و انجام حملات مرد میانی[پانویس ۳] از جمله این تهدیدها است.[۴][۵]

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

در ابتدا از این پروتکل فقط برای انجام تراکنش‌های بانکی، ارسال ای‌میل‌های مهم و کارهای حساس دیگر بر روی وب جهانی استفاده می‌شد اما با گذشت زمان، استفاده از آن بیشتر و بیشتر می‌شود.[۷][۸] امن کردن ارتباطات کاربران، شناسایی وبگاه‌های معتبر و مخفی کردن هویت کاربران از جمله استفاده‌های نوین این پروتکل است.[۹] البته باید توجه داشت که امنیت کامل کاربران تنها در صورتی تامین می‌شود که تمامی محتویات وبگاه از طریق همین پروتکل منتقل شود. منابعی مانند فایل‌های اسکریپت، کوکی‌ها و غیره نمونه‌هایی هستند که انتقال غیرامن آن‌ها تهدید امنیتی محسوب می‌شود.[۱۰]

این پروتکل نباید با پروتکل انتقال ابرمتن امن (S-HTTP)، که تقریباً منسوخ شده است، اشتباه گرفته شود.

دید کلی[ویرایش]

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

آدرس‌های موجود در پروتکل امن انتقال ابرمتن از تمامی قوانین URI[پانویس ۶] پیروی می‌کند. وجود کلمهٔ HTTPS در ابتدای آدرس، به مرورگر نشان می‌دهد که برای اتصال به وب‌گاه باید از امنیت لایه انتقال[پانویس ۲] استفاده کند.[۱۱][۱۲] از آنجا که در این پروتکل حتی اگر یکی از طرفین هم گواهی ثبت شده داشته باشد، امنیت برقرار خواهد شد، استفادهٔ آن در وب بسیار مناسب است. در اینترنت معمولاً وب‌گاه‌ها گواهی ثبت شده تهیه می‌کنند. کاربران با بررسی صحت گواهی وب‌گاه، می‌توانند از هویت وب‌گاه مطمئن شده و ارتباطی امن و غیر قابل شنود داشته‌باشند.[۱۳][۱۴]

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

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

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

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

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

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

پروتکل نوظهور اسپیدی[پانویس ۱۰] می‌تواند به پروتکل HTTPS کمک کند تا زمان بارگذاری صفحات را کاهش دهد.[۲۲][۲۳] این پروتکل هم‌اکنون بر روی مرورگرهای فایرفاکس[۲۴]، کرومیوم[۲۵] و اینترنت اکسپلورر نسخهٔ ۱۱[۲۶] پیاده‌سازی شده و قابل استفاده است.

براساس قوانین تعریف شده در RFC 6797 توسط نیروی ضربت مهندسی اینترنت[پانویس ۱۱]، استفاده از سیاست‌های امنیت انتقال سخت‌گیرانهٔ HTTP[پانویس ۱۲] برای جلوگیری از حملهٔ مرد میانی[پانویس ۳] به همهٔ وبگاه‌ها توصیه می‌شود. با استفاده از این سیاست، وب‌گاه می‌تواند به عامل کاربر[پانویس ۱۳] اعلام نماید که تنها در حالت امن قابل دسترسی است.[۱۰] این ویژگی توسط مرورگرهای فایرفاکس نسخهٔ ۴ به بالا، گوگل کروم نسخهٔ ۴ به بالا و اپرا نسخهٔ ۱۲ به بالا پشتیبانی می‌شود.[۲۷]

در مرورگرها[ویرایش]

تقریباً تمامی مرورگرهای وب در صورت دریافت یک گواهی نامعتبر به اشکال مختلف به کاربر هشدار می‌دهند.[۱۸] برخی از مرورگرهای قدیمی‌تر، با نمایش یک جعبه هشدار[پانویس ۱۴] وضعیت را به کاربر گزارش داده و برای ادامهٔ کار از او اجازه می‌گرفتند. اما مرورگرهای جدیدتر معمولاً با هشدارهای واضح که تمامی صفحه را پر می‌کنند، سعی در مطلع ساختن کاربر از خطرهای احتمالی را دارند.(مانند تصاویر)[۲۸][۲۹] همچنین علامت‌هایی مانند کلید و یا سبز یا قرمز شدن نوار آدرس در مرورگرهای مختلف نشانهٔ مورد تایید یا جعلی بودن گواهی ارائه شده توسط وب‌گاه است.[۳۰][۳۱] امروزه بسیاری از مرورگرها در صورتی که محتویات صفحه مخلوطی از پروتکل امن و غیر امن HTTP باشد، به کاربر هشدار خواهند داد.[۳۲][۳۳]

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

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

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

دید فنی[ویرایش]

تفاوت‌ها با HTTP[ویرایش]

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

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

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

لایه‌های شبکه[ویرایش]

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

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

نصب بر روی سرور[ویرایش]

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

تهیهٔ گواهی معتبر[ویرایش]

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

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

استفاده برای مدیریت دسترسی کاربران[ویرایش]

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

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

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

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

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

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

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

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

پروتکل HTTPS دو حالت مختلف را پشتیبانی می‌کند: حالت ساده[پانویس ۲۳] و حالت متقابل یا دوطرفه[پانویس ۲۴].[۵۱]

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

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

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

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

حملات صورت گرفته[ویرایش]

برهنه‌سازی[ویرایش]

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

حملهٔ کانال‌های جانبی[ویرایش]

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

حملهٔ BEAST[ویرایش]

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

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

حملهٔ CRIME[ویرایش]

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

این حمله نیز توسط جولیانو ریزو[پانویس ۳۱] و ثای دونگ[پانویس ۳۲] گزارش شد.[۶۴]

حملهٔ BREACH[ویرایش]

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

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

در ایران[ویرایش]

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

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

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

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

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

تاریخچه[ویرایش]

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

جستارهای وابسته[ویرایش]

نشان درگاه درگاه اینترنت

معادل‌های انگلیسی[ویرایش]

  1. ↑ Hypertext Transfer Protocol
  2. ↑ ۲٫۰ ۲٫۱ ۲٫۲ SSL/TLS
  3. ↑ ۳٫۰ ۳٫۱ ۳٫۲ ۳٫۳ ۳٫۴ Man in the Middle
  4. ↑ Client
  5. ↑ Server
  6. ↑ URI: Uniform Resource Identifier
  7. ↑ ۷٫۰ ۷٫۱ ۷٫۲ URL: Uniform Resource Locator
  8. ↑ ۸٫۰ ۸٫۱ TCP/IP
  9. ↑ ISP: Internet Service Provider
  10. ↑ ۱۰٫۰ ۱۰٫۱ SPDY
  11. ↑ IETF: Internet Engineering Task Force
  12. ↑ ۱۲٫۰ ۱۲٫۱ HSTS: HTTP Strict Transport Security
  13. ↑ User Agent
  14. ↑ Alert Box
  15. ↑ Extended Validation Certificate
  16. ↑ EFF: Electronic Frontier Foundation
  17. ↑ Eavesdropping
  18. ↑ Server Administrator
  19. ↑ Public Key Certificate
  20. ↑ DHE: Diffie Hellman key exchange
  21. ↑ ECDHE: Elliptic curve Diffie-Hellman Key Exchange
  22. ↑ OCSP: Online Certificate Status Protocol
  23. ↑ Simple
  24. ↑ Mutual
  25. ↑ Chosen ciphertext attack
  26. ↑ SNI: Server Name Indication
  27. ↑ Host Name
  28. ↑ Stripping
  29. ↑ Side Channels
  30. ↑ ۳۰٫۰ ۳۰٫۱ Ekoparty Security Conference
  31. ↑ ۳۱٫۰ ۳۱٫۱ Juliano Rizzo
  32. ↑ ۳۲٫۰ ۳۲٫۱ Thai Duong
  33. ↑ HTTP Compression
  34. ↑ DigiNotar

منابع[ویرایش]

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