كيف يعمل HTTPS وTLS حقًا: شرح المصافحة

أضفت شهادة، وأظهر المتصفح قفلًا، ثم مضيت قدمًا. ثم في يوم ما يفشل عميل API بخطأ SSL_ERROR_RX_RECORD_TOO_LONG، أو يرفض تطبيق جوال سلسلة شهاداتك، أو تظهر حلقة إعادة توجيه بعد تمكين HSTS. فجأة يصبح HTTPS صندوقًا أسود.

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

ما هو HTTPS فعليًا

HTTPS ليس بروتوكولًا منفصلًا. إنه HTTP عادي يُرسل عبر اتصال مشفر بـ TLS. يتغير مخطط URL، وينتقل المنفذ الافتراضي من 80 إلى 443، وكل شيء آخر — الطرق، الترويسات، رموز الحالة، الكوكيز — يتصرف بنفس الطريقة.

يمنحك TLS ثلاث ضمانات فوق TCP:

• السرية — لا يمكن للوسطاء قراءة حركة المرور.
• السلامة — يتم اكتشاف أي تلاعب أثناء النقل.
• المصادقة — يمكن للعميل التحقق من أنه يتحدث إلى الخادم الذي يملك النطاق.

الضمان الثالث هو الذي يستهين به الناس. التشفير بدون مصادقة لا قيمة له: المهاجم الذي يمكنه اعتراض حركة المرور يمكنه ببساطة تقديم مفتاحه الخاص.

مصافحة TLS 1.3 خطوة بخطوة

بسّط TLS 1.3 المصافحة بشكل كبير مقارنة بـ TLS 1.2. إليك التدفق بين المتصفح والخادم:

1. ClientHello — يرسل العميل إصدارات TLS المدعومة، وحزم التشفير، وقيمة عشوائية، ومشاركة مفتاح لمجموعة Diffie-Hellman (مثل X25519).
2. ServerHello — يختار الخادم حزمة تشفير ويرسل مشاركة مفتاحه الخاصة. يمكن للطرفين الآن اشتقاق نفس السر المشترك.
3. الامتدادات المشفرة والشهادة — يرسل الخادم سلسلة شهاداته، مشفرة بالفعل بالمفاتيح المشتقة.
4. Finished — يرسل الطرفان MAC على نص المصافحة لإثبات عدم التلاعب بأي شيء.
5. بيانات التطبيق — تتدفق طلبات واستجابات HTTP عبر الجلسة المنشأة.

في TLS 1.3، تكلف المصافحة الكاملة ذهابًا وإيابًا واحدًا، ويمكن أن تصل الاستئنافات إلى صفر ذهاب وإياب. احتاج TLS 1.2 إلى ذهابين وإياب قبل أن تتدفق أي بيانات تطبيق.

لماذا تُرسل الشهادة بعد اشتقاق المفاتيح

في TLS 1.3 تكون الشهادة مشفرة. هذا يعني أن المراقب السلبي لا يمكنه حتى رؤية النطاق الذي يزوره العميل من الشهادة وحدها، مما يقلل تسرب المعلومات. كما يعني أن أدوات التصحيح التي تتوقع شهادة نصية في الحزم الأولى ستبدو مرتبكة.

التشفير المتماثل مقابل غير المتماثل

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

يتمتع تبادل مفاتيح Diffie-Hellman بخاصية قيمة تسمى السرية الأمامية: حتى إذا تسرب المفتاح الخاص للخادم لاحقًا، لا يمكن فك تشفير الجلسات السابقة المسجلة، لأن مفاتيح الجلسة لم تُشتق أبدًا من ذلك المفتاح طويل الأمد.

ما بداخل الشهادة

تربط شهادة X.509 مفتاحًا عامًا باسم نطاق. تحتوي على:

• الموضوع (النطاق) والأسماء البديلة للموضوع (SANs)، وهو ما تتحقق منه المتصفحات فعليًا.
• المفتاح العام وخوارزميته.
• فترة الصلاحية.
• المُصدر وتوقيع من ذلك المُصدر.

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

خطوات التصحيح العملية

عندما يسوء سلوك HTTPS، ابدأ من الخارج إلى الداخل.

1. تحقق من السلسلة باستخدام openssl s_client -connect example.com:443 -servername example.com -showcerts. تأكد من أن الخادم يرسل السلسلة الكاملة، وليس الشهادة الطرفية فقط.
2. تحقق من تاريخ الانتهاء — الشهادات المنتهية تسبب أعطالًا صارمة بدون حل بديل.
3. تحقق من اسم المضيف — يجب أن تحتوي قائمة SAN على اسم المضيف الدقيق الذي يطلبه العميل، بما في ذلك أي بادئة www.
4. تحقق من إصدار البروتوكول — إذا كان عميل قديم يدعم TLS 1.0 فقط وخادمك يتطلب TLS 1.2+، تفشل المصافحة قبل HTTP.
5. تحقق من إعادة التوجيه — إعادة التوجيه من HTTPS إلى HTTP والعودة تخلق حلقة؛ أصلحها في إعدادات الخادم، وليس في كود التطبيق.

# Inspect the certificate chain and negotiated protocol
openssl s_client -connect example.com:443 \
  -servername example.com -showcerts < /dev/null 2>&1 | \
  openssl x509 -noout -subject -issuer -dates

# Test a specific TLS version
openssl s_client -connect example.com:443 -tls1_2 < /dev/null

في Nginx، يجب أن تشير توجيهات ssl_certificate إلى ملف يحتوي على الشهادة الطرفية متبوعة بالوسيطة، بهذا الترتيب. دمجها بترتيب خاطئ ينتج أخطاء سلسلة يسهل تفويتها.

HSTS وتكلفة الخطأ فيه

يخبر HTTP Strict Transport Security المتصفحات باستخدام HTTPS لنطاق لفترة معينة. إنه قوي وغير متسامح: بمجرد أن يرى المتصفح max-age طويلًا، سيرفض HTTP العادي حتى لو قمت لاحقًا بتعطيل HTTPS على الخادم.

ابدأ بفترة max-age قصيرة، وتحقق من أن كل شيء يعمل، ثم قم بزيادتها. أضف includeSubDomains فقط بعد أن يقدم كل نطاق فرعي HTTPS صالحًا. التحميل المسبق (Preloading) دائم فعليًا — اطلبه فقط عندما تكون متأكدًا.

الأخطاء الشائعة في الإعدادات

• المحتوى المختلط — صفحة HTTPS تحمّل نصوصًا أو صورًا عبر HTTP. تحظر المتصفحات المحتوى النشط المختلط وتحذر من المحتوى السلبي.
• حزم تشفير ضعيفة — ترك حزم وضع CBC وإصدارات بروتوكول قديمة مفعلة من أجل توافق لم تعد بحاجة إليه.
• غياب معالجة OCSP أو CRL — فحص الإبطال غير موثوق عمليًا؛ الشهادات قصيرة العمر هي الإجابة الأكثر متانة.
• ثغرات في أتمتة الشهادات — التجديد يعمل، لكن خطوة إعادة التحميل التي تجعل الخادم يلتقط الشهادة الجديدة مفقودة.

تعامل مع تجديد الشهادة كخط أنابيب نشر، وليس كتذكير تقويم. إذا كان التجديد يتطلب تدخلًا بشريًا، فسيفشل في النهاية في أسوأ وقت.

الأسئلة الشائعة

هل يشفر HTTPS اسم النطاق الذي أزوره؟

يظهر النطاق في امتداد TLS SNI وعادة ما يكون مرئيًا على الشبكة. المسار وسلسلة الاستعلام مشفران، لكن المراقب على الشبكة يمكنه عادة رؤية المضيف الذي اتصلت به.

لماذا يعمل موقعي في المتصفح لكنه يفشل في curl أو تطبيق جوال؟

دائمًا تقريبًا بسبب شهادة وسيطة مفقودة. غالبًا ما تخزن المتصفحات الوسائط مؤقتًا من زيارات سابقة، بينما يتطلب curl والعديد من حزم HTTP للجوال أن يرسل الخادم السلسلة الكاملة.

هل TLS 1.3 دائمًا أفضل من TLS 1.2؟

للعملاء الحديثين، نعم — ذهاب وإياب أقل، مجموعة حزم تشفير أصغر، وسرية أمامية افتراضيًا. أبقِ TLS 1.2 ممكّنًا فقط إذا كنت لا تزال تخدم عملاء لا يمكنهم التفاوض على 1.3.

عندما تحتاج إلى فحص السجلات من الخوادم التي تنهي TLS، فإن مرورًا سريعًا عبر محلل سجلات Nginx يساعدك على اكتشاف أعطال المصافحة وحلقات إعادة التوجيه وسلوك العملاء غير العادي قبل أن تتحول إلى انقطاعات.