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

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

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

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

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

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

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

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

در مرورگرها

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

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

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

تفاوت‌ها با HTTP

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

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

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

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

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

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

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

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

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

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

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

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

یکی دیگر از استفاده‌های سیستم 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 قرار گرفته‌است.

• پروتکل انتقال ابرمتن
• امنیت لایه انتقال
• رمزنگاری
• مرجع صدور گواهی دیجیتال
• گواهی دیجیتال