آغاز کار با CDN ابر آروان
HTTP مکانیزم دقیقی برای امنیت ندارد ولی می‌توان با استفاده از پروتکل‌های لایه‌های پایین‌تر، این پروتکل را امن کرد. راهکار امنیت HTTP، پروتکل HTTPS است. پیش از آشنایی با این پروتکل، لازم است تا با SSL/TLS آشنا شد.
آشنایی با پروتکل‌های SSL و TLS
استفاده از پروتکل SSL پس از معرفی TLS، تقریبن متوقف شد اما هنوز هم این دو پروتکل در کنار یک‌دیگر نام برده می‌شوند. اساس کار این پروتکل‌ها، استفاده از رمزنگاری بر مبنای یک جفت کلید یعنی کلید خصوصی (private key) و کلید عمومی (public key) است. در حالت کلی از یک جفت کلید به دو شکل می‌توان استفاده کرد.
حالت اول زمانی است که هدف ارسال اطلاعات بدون تغییر یا دسترسی شخص سوم، به سمت گیرنده است. در این حالت، متن پیام با استفاده از کلید عمومی گیرنده، رمزنگاری می‌شود. به این ترتیب تنها گیرنده میتواند پیام را با استفاده از کلید خصوصی مربوط به این کلید عمومی، پیام را رمزنگاری و به متن اصلی آن دسترسی پیدا کند.
حالت دوم زمانی است که یکی از دو طرف، سندی را با کلید خصوصی خود امضا می‌کند و آن را همراه کلید عمومی برای سمت دیگر ارتباط ارسال می‌کند. به این فرآیند در اصطلاح امضا یا signing می‌گویند. در آن سمت، نیاز است تا گیرنده از درستی امضا اطمینان حاصل کند. در این‌جا، به شخص سوم قابل اعتمادی نیاز است تا تایید کند کلید عمومی دریافت شده واقعن متعلق به ارسال کننده است.
پروتکل TLS از هردوی این کاربرد‌ها استفاده می‌کند و شیوه‌ای که برای رمزنگاری انتخاب می‌کند، رمزنگاری متقارن است، به این معنی که هم کاربر و هم سرور بعد از ایجاد connection، از کلید‌های یکسانی برای رمزنگاری پیام‌های خود استفاده می‌کنند . پروتکل HTTPS، برای شروع یک connection امن، اطمینان از تغییر نکردن محتوای پیام و هم‌چنین اطمینان از این‌که متن پیام را فقط گیرنده می‌خواند، از پروتکل TLS استفاده می‌کند.
شیوه‌ی کار HTTPS چگونه است؟
بعد از برقراری ارتباط بین client و server، شیوه‌ی کار HTTPS مشابه با HTTP است و پیام‌های ارسالی و دریافتی میان مبدا و مقصد یکسان هستند. با این تفاوت که محتوای پیام‌ها و حتا headerهای پیام‌ها به کمک کلید توافق شده در زمان شروع TLS connection به‌شکل رمز شده ارسال می‌شوند.
پروتکل TLS برای برقراری ارتباط بین کاربر و سرور، از TLS handshake استفاده می‌کند. شیوه‌ی کار به این شکل است که، نخست کاربر پیامی را برای سرور ارسال می‌کند که شامل اطلاعاتی درباره‌ی نسخه‌ی TLS و الگوریتم‌های مورد استفاده‌ی خود است. سرور نیز براساس اطلاعات دریافت شده درباره‌ي کاربر، تصمیم می‌گیرد که با چه الگوریتم‌هایی و با چه نسخه‌ای از TLS با کاربر مکالمه کند. سپس این تصمیم‌ها را در قالب یک پاسخ برای کاربر ارسال می‌کند.
پس از این مرحله، سرور باید هویت خود را به کاربر ثابت کند. برای این منظور، سرور یک گواهی‌نامه‌ی SSL برای کاربر ارسال می‌کند که شامل اطلاعاتی مانند صاحب گواهی‌نامه، کلید عمومی، امضای دیجیتال و اطلاعاتی درباره‌ی تاریخ اعتبار این گواهی‌نامه است. حال لازم است تا کاربر و سرور، به یک کلید توافقی دست پیدا کنند تا بتوانند همه‌ی پیام‌های ارسالی را با آن رمزنگاری و پیام‌های دریافتی را نیز با همان کلید، رمزگشایی کنند. برای این منظور، کاربر یک عدد تصادفی تولید می‌کند و پس از رمزنگاری آن با کلید عمومی سرور، آن را برای سرور ارسال می‌کند. اکنون هر دوی کاربر و سرور، عدد مشابهی در اختیار دارند و چون از قبل درباره‌ی الگوریتم‌های مورد استفاده به توافق رسیده بودند، می‌توانند از روی این عدد به کلید مشابهی دست پیدا کنند و پیام‌های رد و بدل شده را به‌شکل امن ارسال و دریافت کنند.
نکته آن است که مهاجم زمانی میتواند به محتوای پیام‌های تبادلی میان کاربر و سرور دسترسی داشته باشد که کلید مشترک را در اختیار داشته باشد و از آن‌جایی که عدد تصادفی کاربر، با کلید عمومی سرور رمز شده است، فقط با کلید خصوصی سرور نیز باز خواهد شد و این یعنی کسی جز کاربر و سرور، این کلید را نخواهد داشت.
اگرچه استفاده از SSL/TLS، به میزان خوبی سبب شده است تا ارسال و دریافت پیام با HTTP امن‌تر از قبل شود، اما پروتکل TLS نیز در شرایطی و به تنهایی سبب امن شدن ارتباط میان کاربر و سرور نمی‌شود.
