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

لقد كتبت https:// أمام عنوان URL، رأيت القفل، ومضيت قدمًا. ولكن عندما تنتهي صلاحية شهادة في الساعة 2 صباحًا، أو يكسر تحذير المحتوى المختلط صفحة الدفع الخاصة بك، أو يسأل عميل لماذا تفشل استدعاء API الخاص به بخطأ TLS، فإن "القفل يعني أنه آمن" لم يعد إجابة مفيدة. تشرح هذه المقالة ما يحدث فعليًا على الشبكة أثناء اتصال HTTPS وكيفية تكوينه دون تخمين.

ما الذي يضيفه HTTPS إلى HTTP

HTTPS هو HTTP عادي يتم نقله داخل جلسة TLS (أمان طبقة النقل). يوفر TLS ثلاث ضمانات ملموسة:

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

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

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

المصافحة هي التفاوض الذي يحدث قبل تدفق أي بايتات HTTP. في TLS 1.3 تستغرق رحلة ذهاب وإياب واحدة؛ TLS 1.2 يحتاج إلى اثنتين. إليك تدفق TLS 1.3 بعبارات بسيطة:

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

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

التشفير المتماثل مقابل غير المتماثل: لماذا يتم استخدام كليهما

التشفير غير المتماثل (RSA أو ECDSA) بطيء لكنه يحل مشكلة توزيع المفاتيح. التشفير المتماثل (AES-GCM، ChaCha20-Poly1305) سريع لكنه يتطلب مفتاحًا مشتركًا. يستخدم TLS التشفير غير المتماثل فقط أثناء المصافحة لإنشاء مفتاح جلسة متماثل، ثم يشفر البيانات الكبيرة بذلك المفتاح. هذا هو السبب في أن اتصال TLS 1.3 الحديث سريع: رحلة ذهاب وإياب واحدة، ثم AES أو ChaCha20 الرخيص لكل شيء آخر.

حزم التشفير وما يهم فعلاً

حزمة التشفير هي مجموعة مسماة من الخوارزميات. في TLS 1.3 القائمة قصيرة وجميع الخيارات تعتبر آمنة؛ في TLS 1.2 يجب الاختيار بعناية. مقارنة سريعة:

الخلاصة العملية: مكّن TLS 1.2 و1.3 فقط، وعطّل TLS 1.0/1.1، وفضل شهادات ECDSA لتكلفة مصافحة أقل. دع الخادم أو الوكيل العكسي يختار ترتيب الحزم؛ معظم الإعدادات الافتراضية معقولة في برامج عام 2024.

كيفية فحص اتصال حقيقي

لا تحتاج إلى الوثوق بالتوثيق — تحقق من نقاط النهاية الخاصة بك. يُظهر openssl s_client الإصدار المتفاوض عليه وحزمة التشفير وسلسلة الشهادات:

openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

انظر إلى أسطر Protocol وCipher، ثم تحقق من مخرجات سلسلة الشهادات بحثًا عن تاريخ الانتهاء وإدخالات SAN. إذا كانت السلسلة غير مكتملة، ستفشل بعض العملاء بينما تنجح المتصفحات، وهذا مصدر كلاسيكي لأخطاء "يعمل في Chrome ولكن ليس في curl".

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

• شهادة وسيطة مفقودة — يرسل الخادم شهادته الطرفية فقط. قد تجلب المتصفحات الشهادة الوسيطة، لكن عملاء API غالبًا لا يفعلون ذلك.
• محتوى مختلط — صفحة HTTPS تحمّل برنامجًا نصيًا أو صورة عبر HTTP؛ المتصفحات تحظرها أو تخفضها. افحص باستخدام وحدة تحكم المتصفح.
• لا يوجد HSTS — بدون Strict-Transport-Security، يمكن اعتراض أول طلب عبر HTTP قبل حدوث إعادة التوجيه.
• إصدارات بروتوكول ضعيفة أو قديمة — ترك TLS 1.0 ممكّنًا لعميل قديم يضعف كل اتصال بهدوء.
• انتهاء صلاحية الشهادة — أتمت التجديد؛ تذكير التقويم اليدوي ليس استراتيجية.

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

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

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

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

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

ملف fullchain.pem هو ما يمنع مشكلة الشهادة الوسيطة المفقودة. احتفظ بإعادة التوجيه من المنفذ 80 في كتلة خادم منفصلة بحيث يظل HTTP يعمل لتحديات ACME.

ما لا يحميه HTTPS

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

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

هل يقوم HTTPS بتشفير مسار URL وسلسلة الاستعلام؟

نعم. في HTTPS، يتم وضع طلب HTTP بأكمله، بما في ذلك المسار وسلسلة الاستعلام، داخل سجل TLS المشفر. ومع ذلك، يكون اسم المضيف (SNI) وعنوان IP الوجهة مرئيين أثناء المصافحة ما لم يتم استخدام Encrypted Client Hello.

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

عادةً، لأنه يوفر رحلة ذهاب وإياب ويدعم استئناف 0-RTT. على الاتصالات عالية الكمون يكون الفرق ملحوظًا؛ على شبكة محلية يكون طفيفًا. المكسب الأكبر هو أن TLS 1.3 يزيل خيارات التشفير القديمة تمامًا.

هل ما زلت بحاجة إلى HSTS إذا كنت أعيد توجيه HTTP إلى HTTPS؟

نعم. إعادة التوجيه تساعد فقط بعد أن يصل المتصفح إلى خادمك. يخبر HSTS المتصفح بتخطي HTTP تمامًا للطلبات المستقبلية، مما يغلق النافذة التي يمكن فيها اعتراض أول طلب.

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