دیروز یکی از دوست‌هام ازم پرسید:

«پروتوکل HTTPS از رمزگذاری نامتقارن استفاده می‌کنه، درسته؟»

و جوابش هم آره بود، هم نه.

آره، چون در ابتدای ارتباط از رمزگذاری نامتقارن (Public/Private Key) برای تبادل امن کلید استفاده می‌شه.
نه، چون بعد از اون، خودِ داده‌ها با رمزگذاری متقارن منتقل می‌شن — سریع‌تر و سبک‌تر.

حالا بریم سراغ پشت‌صحنه‌ی اتفاقات

وقتی مرورگر و سرور تصمیم می‌گیرن “امن” حرف بزنن، چیزی به نام TLS Handshake انجام می‌شه — همون مغز اصلی HTTPS:

1- مرورگر (Client) می‌گه:
«سلام! من می‌خوام ارتباط امن برقرار کنم، اینم لیست الگوریتم‌های رمزنگاری‌ای که بلدم.»

2- سرور جواب می‌ده:
«باشه، این یکی رو انتخاب می‌کنم.» و پارامترهای امنیتی خودش رو هم مشخص می‌کنه.

3- حالا نوبت اعتمادسازی‌ست:
سرور گواهی دیجیتال (Certificate) خودش رو می‌فرسته. این گواهی شامل کلید عمومی سرور (Public Key) و اطلاعات هویتی دامنه است.
مرورگر این گواهی رو با استفاده از زنجیره‌ی اعتماد به Certificate Authority (CA) بررسی می‌کنه.
اگر معتبر بود، مرورگر حالا کلید عمومی سرور رو در اختیار داره و مطمئنه که طرف مقابل واقعی‌ست.

4- اگر الگوریتم انتخاب‌شده نیاز به تبادل پارامترهای اضافی برای تولید کلید داشته باشه (مثلاً در روش Diffie-Hellman)، سرور این اطلاعات رو در مرحله‌ی Server Key Exchange می‌فرسته.
در بعضی روش‌ها این مرحله وجود نداره، چون همون گواهی کافی‌ست.

5- سرور می‌گه: «من دیگه آماده‌ام.» (Server Hello Done)

6- مرورگر یک pre-master secret تولید می‌کنه، اون رو با کلید عمومی سرور رمز می‌کنه و می‌فرسته. فقط سرور می‌تونه با کلید خصوصی خودش اون رو باز کنه.

7- مرورگر اعلام می‌کنه از اینجا به بعد همه‌چیز رمزنگاری می‌شه (Change Cipher Spec).

8- مرورگر یک پیام تست رمزگذاری‌شده می‌فرسته (Finished) تا مطمئن بشن از کلید یکسان استفاده می‌کنن.

9- سرور هم به حالت رمزنگاری سوئیچ می‌کنه.

سرور پیام تست خودش رو می‌فرسته. حالا دیگه ارتباط کاملاً امنه — همه‌چیز با رمزگذاری متقارن ادامه پیدا می‌کنه.


@ITSecurityComputer