arrow_backبازگشت به یادداشت‌های میدانی
CRYPTOGRAPHY منتشر شده 8 Aug 2026

چگونه TLS درواقع یک اتصال HTTPS را محفوظ می‌کند؟

شکست عملی از دست‌دهی TLS، اعتبارسنجی گواهی‌نامه، و تبادل کلید که HTTPS را واقعاً محفوظ می‌کند.

مردم می‌گویند «HTTPS یعنی رمزگذاری‌شده» و کار را تمام می‌کنند، اما بخش جالب این است که دو غریبه در اینترنت چگونه بدون هرگز دیدار کردن، بر روی شبکه‌ای پر از افرادی که ممکن است گوش دهند، در مورد یک راز مشترک توافق می‌کنند. این همان کاری است که TLS انجام می‌دهد، و مکانیزم آن شایسته درک است اگر با شبکه‌ای، web development یا امنیت سر و کار داشته باشید.

دست‌دهی، مرحله به مرحله

وقتی مرورگر شما به https://example.com متصل می‌شود، تقریباً این اتفاق می‌افتد (TLS 1.3، که اکثر سایت‌ها اکنون از آن استفاده می‌کنند):

  1. ClientHello — مرورگر cipher suites پشتیبانی‌شده، یک nonce تصادفی، و حدسی برای اشتراک کلید (با استفاده از چیزی مانند X25519 یا secp256r1) برای تبادل کلید ارسال می‌کند.
  2. ServerHello — سرور یک cipher suite انتخاب می‌کند، اشتراک کلید خود را ارسال می‌کند، و گواهی‌نامه‌اش را بر می‌گرداند و همچنین امضایی ثابت می‌کند که کلید خصوصی مطابق با آن گواهی‌نامه را در دست دارد.
  3. استخراج کلید — هر دو طرف اکنون به‌طور مستقل راز مشترک یکسانی را با استفاده از ریاضیات Diffie-Hellman روی اشتراک کلیدهایشان محاسبه می‌کنند. هیچ یک هرگز خود راز را منتقل نمی‌کند؛ آن استخراج می‌شود، نه ارسال می‌شود.
  4. پیام‌های Finished — هر دو طرف تأیید می‌کنند که دست‌دهی دستکاری نشده‌است با ارسال یک MAC روی کل رونوشت دست‌دهی.

پس از آن، همه چیز با کلیدهای متقارن استخراج‌شده از راز مشترک رمزگذاری می‌شود، معمولاً AES-128-GCM یا ChaCha20-Poly1305. TLS 1.3 این را از دست‌دهی دو دور سفری TLS 1.2 به طور مؤثری به یک دور سفری کاهش داد، که این یک کسب تأخیری واقعی در مقیاس است.

چرا گواهی‌نامه بیش‌تر از رمزگذاری اهمیت دارد

رمزگذاری بدون تأیید هویت بی‌معنا است — هر کسی می‌تواند یک کانال رمزگذاری‌شده راه‌اندازی کند، از جمله مهاجمی که man-in-the-middle را اجرا می‌کند. گواهی‌نامه آن است که یک کلید عمومی را به یک نام دامنه گره می‌زند، و توسط یک Certificate Authority (CA) مانند Let's Encrypt یا DigiCine امضا شده‌است.

مرورگر شما یک لیست ثابت از CA های ریشه‌ای را که در trust store سیستم‌عامل یا مرورگر تعبیه شده‌است اعتماد می‌کند. گواهی‌نامه سرور از طریق گواهی‌نامه‌های میانی تا یکی از آن ریشه‌ها زنجیره می‌شود. اگر زنجیره اعتبارسنجی نشود یا دامنه‌ای در گواهی‌نامه با آنی که درخواست کردید منطبق نباشد، صفحه‌ای هشدار قرمز می‌گیرید. این مدل زنجیره‌ی اعتماد مرز امنیت واقعی است — کلید امضا کردن CA را بدزدید و می‌توانید گواهی‌نامه‌های معتبری برای هر دامنه‌ای ضرب کنید، به همین دلیل است که سازش‌های CA به عنوان حوادث اصلی در نظر گرفته می‌شوند.

رمزنگاری متقارن در مقابل نامتقارن در اینجا چه کار می‌کند

رمزنگاری نامتقارن (RSA یا elliptic curve) کند و گران است، بنابراین TLS فقط در طول دست‌دهی از آن استفاده می‌کند — برای احراز هویت سرور و برای کمک به ایجاد راز مشترک. پس از آن، تمام داده‌های واقعی (HTML، JSON، هر چه) با رمزگذاری‌های متقارن سریع رمزگذاری می‌شود. این رویکرد ترکیبی همان الگویی است که می‌بینید در SSH، PGP، و اکثر سیستم‌های رمزنگاری جهان واقعی: نامتقارن برای هویت و تبادل کلید، متقارن برای داده‌های فله‌ای.

رازداری رو به جلو جزئیات مرتبطی است که شایسته دانستن است: زیرا راز مشترک از اشتراک کلیدهای Diffie-Hellman سفید حاضر می‌آید که به‌طور تازه برای هر جلسه تولید می‌شوند، حتی اگر کسی ترافیک شما را ضبط کند و بعداً کلید خصوصی سرور را بدزدید، همچنان نمی‌توانند جلسات قدیمی را رمزگشایی کنند. این ویژگی در تبادل کلیدهای فقط RSA قدیمی‌تر وجود نداشت.

بررسی آن خود

شما نیازی ندارید که نماد‌ padlock سبز را کوری اعتماد کنید. اجرا کنید:

openssl s_client -connect example.com:443 -tls1_3

این cipher suite توافق شده، زنجیره گواهی‌نامه، و اینکه آیا دست‌دهی واقعاً تکمیل شده‌است را نشان می‌دهد. برای نگاهی سریع‌تر به آنچه مرورگر می‌بیند، curl -v https://example.com نسخه TLS و جزئیات گواهی‌نامه را قبل از پاسخ HTTP چاپ می‌کند.

شما همچنین می‌توانید ترافیک خود را در Wireshark رمزگشایی کنید اگر متغیر محیط SSLKEYLOGFILE را قبل از راه‌اندازی Chrome یا Firefox صادر کنید — واقعاً برای debugging مسائل TLS به جای حدس زدن مفید است.

جایی که این واقعاً در عمل شکسته می‌شود

بیش‌تر خرابی‌های HTTPS جهان واقعی نقطه‌های رمزنگاری نیستند، آنها عملیاتی هستند: گواهی‌نامه‌های منقضی شده، زنجیره‌های میانی پیکربندی نشده، کلاینت‌های گیر افتاده در نسخه‌های قدیمی TLS، یا محتوای مختلط (صفحه HTTPS که منبع HTTP را بارگذاری می‌کند). حملات سطح پروتکل واقعی بر علیه TLS 1.3 مدرن نادر هستند زیرا مشخصات اکثر ترفندهای padding oracle و downgrade را که SSL 3.0 و TLS اولیه را دچار مشکل کرده‌اند بستند. نقاط ضعف اکنون معمولاً نقاط انتهایی هستند — یک CA سازش یافته، یک کلید خصوصی دزدیده شده، یا کاربری که از طریق هشداری در مورد گواهی‌نامه‌ای که نباید کلیک می‌کند رد می‌شود.

اگر می‌خواهید بیش‌تر پیش برید، بخش‌های networking و رمزنگاری Korra Studio ریاضیات Diffie-Hellman زیربنایی و تجزیه پروتکل سطح بسته را با جزئیات بیش‌تری پوشش می‌دهد.

با کمک هوش مصنوعی نوشته‌شده، بازبینی و منتشر‌شده توسط Michal Pilch (CISSP)، Korra Studio.

آماده برای پیش‌رفت بیشتر؟

این یکی از یادداشت‌های پایگاه دانش Korra Studio است — پلتفرم هر موضوع را با مربی یک‌به‌یک جفت می‌کند.

شروع رایگانarrow_forward