كيف يؤمّن TLS اتصال HTTPS فعلياً؟

يقول الناس "HTTPS يعني أنها مشفرة" ويتركونها عند هذا الحد، لكن الجزء المثير للاهتمام هو كيف يتفق شخصان غريبان على الإنترنت على سر مشترك دون أن يلتقيا، عبر شبكة مليئة بالأشخاص الذين قد يستمعون. هذا ما يفعله TLS، والآليات تستحق الفهم إذا كنت تتعامل مع الشبكات أو تطوير الويب أو الأمان على الإطلاق.

المصافحة، خطوة بخطوة

عندما يتصل متصفحك بـ https://example.com، إليك تقريباً ما يحدث (TLS 1.3، الذي تستخدمه معظم المواقع الآن):

1. ClientHello — يرسل المتصفح مجموعات التشفير المدعومة، و nonce عشوائي، وتخمين لمشاركة مفتاح (باستخدام شيء مثل X25519 أو secp256r1) لتبادل المفاتيح.
2. ServerHello — يختار الخادم مجموعة تشفير، يرسل مشاركة مفتاحه الخاصة، ويعيد شهادته بالإضافة إلى توقيع يثبت أنه يملك المفتاح الخاص الذي يطابق تلك الشهادة.
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.

يثق متصفحك بقائمة ثابتة من CAs الجذرية المدمجة في نظام التشغيل أو مستودع ثقة المتصفح. شهادة الخادم تسلسل عبر شهادات وسيطة إلى أحد هذه الجذور. إذا لم يتحقق السلسلة، أو اسم النطاق في الشهادة لا يطابق اسم النطاق الذي طلبته، تحصل على صفحة تحذير حمراء. نموذج chain-of-trust هذا هو الحدود الأمنية الفعلية — سرقة مفتاح توقيع CA ويمكنك إنشاء شهادات صالحة لأي نطاق، ولهذا تُعامل اختراقات CA كحوادث رئيسية.

ما تفعله التشفيرات المتماثلة مقابل غير المتماثلة هنا

التشفير غير المتماثل (RSA أو elliptic curve) بطيء ومكلف، لذا يستخدم TLS فقط أثناء المصافحة — للتحقق من الخادم وللمساعدة في إنشاء السر المشترك. بمجرد الانتهاء من ذلك، يتم تشفير كل البيانات الفعلية (HTML، JSON، أياً كان) باستخدام تشفيرات متماثلة سريعة. هذا النهج الهجين هو نفس الأنماط التي ستراها في SSH و PGP ومعظم أنظمة التشفير الحقيقية: غير متماثل للهوية وتبادل المفاتيح، متماثل للبيانات الضخمة.

Forward secrecy تفصيلة ذات صلة تستحق المعرفة: لأن السر المشترك يأتي من مشاركات مفاتيح Diffie-Hellman مؤقتة يتم إنشاؤها بشكل جديد لكل جلسة، حتى لو قام شخص ما بتسجيل حركتك الحالية وسرق لاحقاً المفتاح الخاص للخادم، لا يزالون غير قادرين على فك تشفير الجلسات القديمة. هذه الخاصية لم تكن موجودة في تبادل المفاتيح القديم بـ RSA فقط.

التحقق بنفسك

لا تحتاج إلى الوثوق بأيقونة القفل الأخضر بعمى. قم بتشغيل:

openssl s_client -connect example.com:443 -tls1_3

هذا يعرض لك مجموعة التشفير المتفاوض عليها، وسلسلة الشهادات، وما إذا كانت المصافحة قد اكتملت فعلاً. للحصول على نظرة سريعة على ما يراه المتصفح، curl -v https://example.com تطبع إصدار TLS وتفاصيل الشهادة قبل استجابة HTTP.

يمكنك أيضاً فك تشفير حركتك الخاصة في Wireshark إذا قمت بتصدير متغير بيئة SSLKEYLOGFILE قبل إطلاق Chrome أو Firefox — مفيد حقاً لتصحيح أخطاء TLS بدلاً من التخمين.

حيث ينكسر هذا فعلياً في الممارسة العملية

معظم فشل HTTPS في العالم الحقيقي ليس اختراقات تشفيرية، إنها مشاكل تشغيلية: شهادات منتهية الصلاحية، سلاسل وسيطة مُعدّة بشكل خاطئ، عملاء عالقون في إصدارات TLS قديمة، أو محتوى مختلط (صفحة HTTPS تحمل مورد HTTP). الهجمات على مستوى البروتوكول الفعلي ضد TLS 1.3 الحديث نادرة لأن الـ spec أغلقت معظم tricks حشو oracle والتدرج الذي أرهق SSL 3.0 و TLS المبكرة. نقاط الضعف الآن عادة تكون في نقاط النهاية — CA مخترقة، أو مفتاح خاص مسروق، أو مستخدم ينقر عبر تحذير شهادة لم يكن يجب أن يفعله.

إذا كنت تريد أن تذهب أبعد، تغطي أقسام الشبكات والتشفير في Korra Studio رياضيات Diffie-Hellman الأساسية وتحليل البروتوكول على مستوى الحزمة بمزيد من التفصيل.