آشنایی با پروتکل https و نسخه های TLS؟

همانطور که در مقاله آشنایی با پروتکل HTTP، توضیحاتی در مورد این پروتکل ارائه شد، در یک سناریوی عادی و نمونه ابتدا کلاینت یک درخواست به سرور ارسال میکند و سپس متناسب درخواست ارسالی، پاسخی به کلاینت بازگردانده میشود. در این سناریو هیچ گونه رمزنگاری (Encryption) خاصی بر روی داده ها رخ نمیدهد و صرفا داده ها به شکل قابل انتقال در پروتکل HTTP کدگذاری میشود(Encoding) و سپس تبادل رخ میدهد. اما در این سناریو از امنیت اطلاعات خبری نیست!!! در صورتی که داده های انتقالی به هر طریقی در مسیر انتقال در اختیار افراد غیرمجاز قرار بگیرد، به راحتی میتوانند عملیات Decoding را انجام داده و به اطلاعات دسترسی کامل بیابند.

اما چگونه میتوان امنیت درخواست ها را افزایش داد؟

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

HTTPS چگونه کار میکند؟

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

نحوه HandShake در TLS نسخه 1.2 و نسخه های قبل تر

1. کلاینت ابتدا یک پیام (Hello) به سرور ارسال میکند و در پیام خود لیستی از گزینه های امنیتی که میتواند پشتیبانی کند را جهت انتخاب به سرور میفرستد.
2. سرور پس از دریافت پیام از جانب کلاینت، اطلاعات گواهی SSL خود را به همراه یک کلید عمومی Public Key)) به کلاینت میفرستد.
3. کلاینت اطلاعات گواهی SSL را بررسی نموده و در صورت تایید اصالت آن، یک کلید مشترک (Shared Key) را با استفاده از کلید عمومی که از سرور دریافت کرده به صورت رمزگذاری شده به سرور میفرستد.
4. سرور پیام کلاینت را دریافت میکند و این به معنی آمادگی کلاینت برای ارسال داده هاست. بنابراین با کلید خصوصی خود کلید مشترک را رمزگشایی میکند و در نهایت یک پیام موفقیت به کلاینت میفرستد.

همانطور که مشخص است با عملیات فوق هر دو طرف یک کلید مشترک دارند و با استفاده از یک روش رمزنگاری متقارن، عملیات رمزگذاری روی داده های درخواست و پاسخ درخواست را انجام میدهند و از این طریق حتی در صورت دسترسی غیر مجاز به داده های انتقالی، امکان رمزگشایی آنها وجود ندارد. البته کلید مشترک از اهمیت ویژه ای برخوردار است و نباید به هیچ وجه آشکار شود. برای این منظور خود کلید مشترک توسط الگوریتم دیگری و با استفاده از کلید عمومی، یک بار در مرحله دوم از مراحل فوق توسط کلاینت رمزگذاری شد. برای هر بار که ریکوئستی ارسال میشود، یک دور تمام این مراحل باید انجام شود!!! طبیعتا سربار قابل توجهی خواهد داشت و کندی ملموسی نسبت به نسخه بدون Https ایجاد میشود.

نحوه HandShake در TLS1.3

در این نسخه تفاوت چشم گیر و قابل توجهی نسبت به نسخه قبل تر وجود دارد. فرآیند HandShake که شامل 4 مرحله فوق بود در دو مرحله خلاصه تر میشود. همچنین الگوریتم های ناایمن رمزنگاری که در نسخه های قبل وجود داشت حذف شده و الگوریتم های قوی تر و به روزتری جایگزین شده اند. مراحل Handshake در این نسخه به صورت ذیل است:

1. کلاینت با آگاهی قبلی از این که سرور چه الگوریتمی را انتخاب خواهد کرد، یک پیام(Hello) همراه با تعدادی از گزینه های امنیتی و کلید مشترک به سرور میفرستد.
2. سرور اطلاعات را دریافت نموده و مطابق آگاهی قبلی کلاینت، یک گزینه را انتخاب میکند و اطلاعات SSL را به همراه پیام موفقیت به کلاینت میفرستد و HandShake با موفقیت به پایان میرسد.

شاید برای شما سوال باشد که چرا در TLS1.2 این اتفاق نیفتاد؟ یک نکته قابل توجه این است که در TLS1.3 از قبل کلاینت از انتخابی که سرور خواهد کرد اطلاع دارد. همچنین کلید مشترک در همان اولین گام ارسال میشود. همین دو موضوع باعث کم شدن گام ها خواهد شد.

نکته مبهم دیگر این است که چرا در نسخه 1.2 در همان گام اول کلید مشترک ارسال نمیشد؟

باید بگوییم از آنجا که TLS1.2 قدیمی تر است، روشی برای جلوگیری از لو رفتن کلید مشترک در آن بدون وجود کلید عمومی که سرور ان را مشخص میکند و رمزنگاری کلید مشترک با استفاده از کلید عمومی وجود ندارد. اما در TLS1.3 با پیشرفتی که در زمینه رمزنگاری رخ داده است، میتوان بدون نگرانی از لو رفتن کلید مشترک، در همان مرحله ابتدایی آن را ارسال نمود و با استفاده از الگوریتم های ریاضی و ویژه تری این امنیت را تضمین نمود.

چرا تمامی سازمانهای مرتبط با امنیت اطلاعات و در راس آنها گوکل، به سمت حذف HTTP پیش میروند؟

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

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

https://classicode.org/B-39

برای پیگیری آموزش ها و مقالات بیشتر، به صفحه لینکدین و وبسایت من سر بزنید.

www.classicode.org

www.linkedin.com/in/mrabiee1996