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

تقوم بإضافة شهادة SSL، وتوجه نطاقك إلى خادم، ويظهر القفل. معظم المطورين يتوقفون عند هذا الحد. ثم في يوم ما يفشل عميل API مع UNABLE_TO_VERIFY_LEAF_SIGNATURE، أو يرفض تطبيق جوال شهادتك على أندرويد الأقدم، أو يقوم موازن التحميل بإنهاء TLS ويرى تطبيقك كل شيء كـ HTTP عادي. فجأة تحتاج إلى معرفة ما يحدث فعلاً بين اتصال TCP وأول طلب HTTP.

تشرح هذه المقالة كيف يعمل HTTPS و TLS حقًا: ماذا تفعل المصافحة، وكيف يتم التحقق من الشهادات، وما الذي تغير في TLS 1.3، وكيفية تشخيص الأخطاء التي ستواجهها فعلاً.

ما الذي يضيفه HTTPS فعليًا

HTTPS هو HTTP يُرسل عبر اتصال TLS. يوفر TLS ثلاثة ضمانات:

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

لاحظ ما ليس في تلك القائمة: لا يتم مصادقة العميل افتراضيًا. TLS يصادق على الخادم؛ تطبيقك يصادق على المستخدم.

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

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

1. ClientHello — يرسل العميل إصدارات TLS المدعومة، وقيمة عشوائية، وقائمة بحزم التشفير، و(إن أمكن) اسم مضيف SNI.
2. ServerHello — يختار الخادم إصدارًا وحزمة تشفير، ويعيد قيمته العشوائية الخاصة، ويرسل سلسلة شهادته.
3. تبادل المفاتيح — مع ECDHE، يرسل الخادم مفتاحًا عامًا مؤقتًا؛ ويرسل العميل مفتاحه الخاص. يستنتج كلاهما نفس السر المشترك. يوقع الخادم على محضر المصافحة باستخدام المفتاح الخاص لشهادته.
4. Finished — يرسل الطرفان MAC على محضر المصافحة، مما يؤكد عدم التلاعب بأي شيء.
5. بيانات التطبيق — تتدفق طلبات واستجابات HTTP مشفرة.

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

كيف غير TLS 1.3 قواعد اللعبة

يبسط TLS 1.3 المصافحة إلى رحلة ذهاب وعودة واحدة ويزيل الخوارزميات القديمة تمامًا.

في TLS 1.3 يخمن العميل مجموعة تبادل المفاتيح ويرسل حصته في الرسالة الأولى، حتى يتمكن الخادم من إكمال اتفاقية المفاتيح على الفور. لا تزال الشهادات تُرسل، لكنها الآن مشفرة، مما يعني أن المراقبين السلبيين لم يعودوا قادرين على رؤية اسم المضيف الذي يتم تقديمه — فقط SNI في ClientHello يكشفه ما لم يتم استخدام Encrypted Client Hello.

يتيح استئناف 0-RTT للعميل العائد إرسال بيانات التطبيق مع أول رحلة. إنه سريع، لكن بيانات 0-RTT قابلة لإعادة التشغيل، لذا لا تستخدمه أبدًا للطلبات غير المتكافئة مثل المدفوعات.

الشهادات والتحقق من السلسلة

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

• يرسل الخادم شهادته الطرفية بالإضافة إلى الشهادات الوسيطة.
• يبحث العميل عن جذر موثوق في مخزنه، ثم يتحقق من كل توقيع صعودًا في السلسلة.
• يتحقق من اسم المضيف مقابل حقل Subject Alternative Name (SAN) — يتم تجاهل Common Name بواسطة العملاء الحديثين.
• يتحقق من تواريخ الصلاحية وحالة الإلغاء (CRL أو OCSP، غالبًا مثبتة).

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

تصحيح الأخطاء العملي باستخدام OpenSSL

عندما ينكسر شيء ما، افحص ما يرسله الخادم فعليًا قبل إلقاء اللوم على العميل.

# Show the certificate chain the server presents
openssl s_client -connect example.com:443 -servername example.com -showcerts

# Negotiate only TLS 1.3 and list the chosen cipher
openssl s_client -connect example.com:443 -tls1_3

# Check certificate expiry in one line
echo | openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates -subject -ext subjectAltName

إذا أبلغ s_client عن verify error:num=21:unable to verify the first certificate، فإن السلسلة غير مكتملة. إذا أبلغ عن عدم تطابق اسم المضيف، فتحقق من قائمة SAN — تغطي شهادات النطاقات الفرعية تسمية واحدة فقط، لذا *.example.com يطابق api.example.com ولكن ليس a.b.example.com.

الأخطاء الشائعة في التكوين

• محتوى مختلط — صفحة HTTPS تحمّل نصوصًا أو صورًا من http://. تحظر المتصفحات المحتوى النشط المختلط وقد ترقي المحتوى السلبي تلقائيًا.
• إنهاء TLS عند موازن التحميل — يرى الخادم الخلفي HTTP عادي. قم بتمرير X-Forwarded-Proto ووثق به فقط من وكلاء معروفين، وإلا قد ينشئ تطبيقك عناوين إعادة توجيه خاطئة.
• تمكين إصدارات بروتوكول ضعيفة — يجب تعطيل TLS 1.0 و 1.1. استهدف TLS 1.2 و 1.3 فقط.
• عدم وجود HSTS — بدون رأس Strict-Transport-Security، لا يزال من الممكن تخفيض أول طلب. ابدأ بـ max-age قصير، ثم ارفعه بعد التأكد.
• شهادات موقعة ذاتيًا في الإنتاج — جيدة للاختبار الداخلي، لكنها تدرب المستخدمين والعملاء على تجاهل التحذيرات.

تكوين خادم معقول

بالنسبة لـ Nginx، يبدو الخط الأساسي الحديث كما يلي:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;

دع الخادم يختار حزم التشفير في TLS 1.3 — تفضيل العميل هناك جيد لأن جميع الحزم قوية. أبقِ تذاكر الجلسة معطلة ما لم تقم بتدوير مفاتيح التذاكر، لأن مفتاح تذكرة مسربًا يمكن أن يضر بالاستئناف.

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

هل يقوم HTTPS بتشفير اسم المضيف؟

ليس افتراضيًا. يتم إرسال امتداد SNI في ClientHello بنص عادي حتى يعرف الخادم أي شهادة يقدم. يخفيه Encrypted Client Hello (ECH)، لكن التبني لا يزال محدودًا. المسار وسلسلة الاستعلام مشفران دائمًا.

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

دائمًا تقريبًا شهادة وسيطة مفقودة. غالبًا ما تجلب المتصفحات أو تخزن الشهادات الوسيطة مؤقتًا بنفسها، بينما يتطلب العملاء الأكثر صرامة أن يرسل الخادم السلسلة الكاملة. تحقق باستخدام openssl s_client -showcerts.

هل TLS 1.3 دائمًا أسرع من TLS 1.2؟

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

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