HTTP وHTTPS

لماذا يهم

كثير من الإخفاقات التي تبدو عيوباً في التطبيق هي في الحقيقة سلوك HTTP أو HTTPS: مستخدمون يُسجَّل خروجهم عشوائياً لأن طلبهم التالي وصل إلى خادم آخر، وتطبيق جوال لا يستطيع الاتصال بينما ينجح المتصفح، وصفحة دفع تتوقف يوم تنتهي صلاحية شهادة، ونموذج يرسل بيانات البطاقة عبر HTTP غير مشفّر. والمختبِر الذي يفهم هذا النموذج يستطيع تسمية السبب والفريق المسؤول عنه.

وبالنسبة للمستخدمين، يحمي HTTPS كلمات المرور وملفات تعريف الارتباط الخاصة بالجلسة والبيانات الشخصية من أي طرف على مسار الشبكة، مثل مشغّل شبكة Wi-Fi عامة. وبالنسبة للمختبِرين، فإن HTTP هو الطبقة التي يقوم عليها كل اختبار للويب ولواجهات API.

العميل والخادم: تبادل الطلب والاستجابة

في HTTP يبدأ العميل الكلام دائماً. فهو يرسل طلباً يتكوّن من طريقة (method) مثل GET أو POST، وهدف مثل /orders/1042، وحقول ترويسة (headers)، ومحتوى (body) أحياناً. والخادم ينتظر الطلبات ويجيب عن كل طلب باستجابة: رمز حالة، وحقول ترويسة، ومحتوى في أغلب الأحيان.

العميل والخادم دوران لا جهازان. فالمتصفح وتطبيق الجوال وcurl واختباراتك المؤتمتة كلها عملاء، وكذلك خدمة إتمام الشراء حين تستدعي واجهة API للدفع، مع أنها خادم بالنسبة لمستخدميها. وبين الطرفين يوجد غالباً وسطاء (intermediaries): الوكلاء (proxies) وموازنات الأحمال (load balancers) وبوابات API وشبكات توصيل المحتوى (CDN)، وهي تمرّر الطلب أو تجيب عنه من ذاكرة مؤقتة. ويسمّي RFC 9110 الخادم الذي يملك المورد الخادمَ الأصلي (origin server)، والاستجابة التي تراها ليست دائماً من إنتاجه.

GET /orders/1042 HTTP/1.1
Host: shop.example.com
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 1042, "status": "shipped", "items": 3}

جرّبها: محلّل عناوين URL جرّبها: فاحص طلبات HTTP

عديم الحالة: كل طلب قائم بذاته

يعرّف RFC 9110 بروتوكول HTTP بأنه عديم الحالة (stateless): يمكن فهم كل طلب بمعزل عن غيره، ولا شيء في البروتوكول يربط طلبك الثالث بطلبك الأول. وهذا ما يسمح للموقع بتوزيع الطلبات على خوادم كثيرة خلف موازن أحمال.

والتطبيقات التي تحتاج إلى استمرارية، كمستخدم مسجَّل الدخول أو سلة مشتريات أو نموذج من عدة خطوات، تبنيها فوق HTTP: يرسل العميل معرّفاً مع كل طلب، غالباً في ملف تعريف ارتباط (cookie) أو في ترويسة Authorization، ويبحث الخادم عن الحالة المطابقة في مخزنه الخاص. وهذا يعطي المختبِر أفكار اختبار ملموسة:

• التحديث والرابط المشارَك وعلامة التبويب الثانية، كلٌّ منها يرسل طلباً جديداً لا يربطه بالخطوات السابقة إلا ما يحمله، كملف تعريف الارتباط. افتح الخطوة الثالثة من إتمام الشراء مباشرةً في نافذة خاصة: يجب أن يوجّهك التطبيق إلى تسجيل الدخول أو يعيد بناء الخطوة، لا أن ينهار أو يعرض بيانات مستخدم آخر.
• إذا احتفظت نسخة من الخادم ببيانات الجلسة في ذاكرتها الخاصة، فقد يصل الطلب التالي إلى نسخة لم تتعامل معك من قبل، فيفقد المستخدمون جلستهم أو سلتهم عشوائياً. كرّر السيناريو مرات كثيرة، واسأل كيف تُخزَّن الجلسات.
• يجب أن يتحقق الخادم في كل طلب من هوية مُرسِله ومما يحق لهذا المستخدم فعله، ولا يجوز أن يعتمد على طلب سابق. في بيئة الاختبار، أعد إرسال طلب من حساب الاختبار الخاص بك دون ملف تعريف الارتباط أو الرمز المميز (token): يجب أن يرفضه الخادم.
• لا يستطيع الخادم التمييز بين نقرة مزدوجة وطلبيتين حقيقيتين. أرسل النموذج مرتين بسرعة واحسب عدد الطلبيات المنشأة؛ فمنع التكرار مسؤولية التطبيق لا مسؤولية HTTP.

HTTPS: بروتوكول HTTP نفسه داخل TLS

العنوان الذي يبدأ بـ https:// يعني أن رسائل HTTP تنتقل داخل اتصال TLS (أمن طبقة النقل، Transport Layer Security)، على المنفذ 443 افتراضياً بدلاً من 80. والرسائل نفسها لا تتغيّر؛ لكن TLS يضيف ثلاث ضمانات: السرية (لا يستطيع أحد على المسار قراءتها)، والسلامة (تُكتشف أي بايتات معدَّلة ويفشل الاتصال)، ومصادقة الخادم (هو فعلاً المضيف الوارد في العنوان). ويمكن للعميل أيضاً إثبات هويته بشهادة خاصة به، وهو ما تشترطه بعض واجهات API بين الخدمات؛ ويسمّى ذلك TLS المتبادل (mutual TLS).

قبل أول بايت من HTTP يجري الطرفان مصافحة TLS (TLS handshake). وتعتمد المصافحة على زوج مفاتيح: مفتاح عام (public key) يمكن لأي أحد أن يراه، ومفتاح خاص (private key) لا يحتفظ به إلا الخادم. والبيانات الموقّعة بالمفتاح الخاص يمكن التحقق منها بالمفتاح العام، فالتوقيع الصحيح يثبت أن صاحبه يملك المفتاح الخاص. وفي ⁦TLS 1.3⁩ تستغرق المصافحة رحلة ذهاب وإياب واحدة: يقترح العميل المفاتيح ويسمّي المضيف الذي يريده؛ فيرد الخادم باختياراته وشهادته وتوقيع يثبت امتلاكه المفتاح الخاص للشهادة؛ ثم يشتق الطرفان مفاتيح الجلسة نفسها، وعندها فقط يُرسَل الطلب مشفّراً.

الشهادة تربط مفتاحاً عاماً بأسماء مضيفين مدرجة في حقل الاسم البديل للموضوع (Subject Alternative Name)، وتوقّعها جهة إصدار شهادات (CA). ويرسل الخادم شهادته ومعها الشهادات الوسيطة التي تصلها بشهادة جذرية يثق بها العميل مسبقاً، لأنها مخزّنة في نظام التشغيل أو المتصفح. ويتحقق العميل مما يلي:

• الاسم: يجب أن يكون المضيف مدرجاً. فحرف البدل (wildcard) *.example.com يغطي shop.example.com، لكنه لا يغطي example.com ولا api.shop.example.com.
• التواريخ: يجب أن تكون الشهادة ضمن مدة صلاحيتها. والشهادة المنتهية توقف جميع العملاء دفعة واحدة.
• السلسلة: يجب أن تكون كل حلقة حتى الشهادة الجذرية الموثوقة موجودة. وغياب الشهادة الوسيطة عيب شائع: قد يسدّ متصفح سطح المكتب الفجوة بنفسه، بينما تفشل التطبيقات والسكربتات.
• ما يبقى مكشوفاً: يرى المراقب على المسار عنوان IP وتوقيت الرسائل وأحجامها، واسم المضيف في الغالب، لكنه لا يرى المسار ولا الاستعلام ولا الترويسات ولا ملفات تعريف الارتباط ولا المحتوى.
• ما لا يغطيه HTTPS: فهو يحمي البيانات أثناء انتقالها فقط. والخادم يرى كل شيء، وثغرات التحكم في الوصول أو الحقن تعمل عبر الاتصال المشفّر بالسهولة نفسها.

إصدارات HTTP باختصار

تشترك جميع إصدارات HTTP الحالية في الدلالات المعرَّفة في RFC 9110: فالطرق ورموز الحالة وحقول الترويسة لها المعنى نفسه في كل مكان، والرمز 404 هو 404 في كل إصدار. أما ما يتغيّر فهو طريقة نقل الرسائل:

• ⁦HTTP/1.1⁩: رسائل نصية صريحة. يُعاد استخدام الاتصال لطلبات كثيرة، لكنه عملياً يحمل طلباً واحداً في كل مرة، لذلك تفتح المتصفحات عدة اتصالات لكل مضيف. أما ⁦HTTP/1.0⁩، الذي كان يفتح اتصالاً جديداً لكل طلب افتراضياً، فنادراً ما يُرى اليوم.
• ⁦HTTP/2⁩: الرسائل نفسها في إطارات ثنائية (binary frames)، مع طلبات كثيرة تتشارك اتصالاً واحداً في الوقت نفسه (multiplexing) وترويسات مضغوطة. وأسماء الترويسات فيه بأحرف صغيرة دائماً، والمتصفحات لا تستخدم ⁦HTTP/2⁩ إلا عبر HTTPS.
• ⁦HTTP/3⁩: النموذج نفسه فوق QUIC، وهو بروتوكول نقل يعمل فوق UDP ويتضمّن ⁦TLS 1.3⁩، فلا يؤخّر فقدانُ حزمة إلا الطلبَ الذي تنتمي إليه. وكثيراً ما تعرف المتصفحات أن الخادم يدعمه من ترويسة الاستجابة Alt-Svc، وتعود إلى ⁦HTTP/2⁩ عندما تحجب الشبكة UDP.
• في الاختبار: أضف عمود Protocol إلى تبويب Network في أدوات المطوّرين؛ ويعرض Chrome القيمة http/1.1 أو h2 أو h3 لكل طلب. ويجب ألا يعتمد السلوك على الإصدار؛ فإن اعتمد عليه فاشتبه في وكيل أو في إعداد لشبكة CDN أو في شيفرة تقارن أسماء الترويسات مع مراعاة حالة الأحرف.

مثال تطبيقي: فحص HTTPS قبل الإصدار

متجر على وشك إصدار صفحة تسجيل دخول جديدة وواجهة API لتطبيقه على الجوال. في بيئة Staging يفحص المختبِر https://staging.shop.example.com وhttps://api-staging.shop.example.com ويسجّل كل نتيجة:

• العنوان http://staging.shop.example.com/login يجيب بالرمز 301 مع Location: https://staging.shop.example.com/login. ناجح: HTTP غير المشفّر لا يفعل سوى إعادة التوجيه.
• استجابات HTTPS تحمل Strict-Transport-Security: max-age=31536000. وترويسة HSTS هذه (RFC 6797) تطلب من المتصفح ألا يستخدم مع هذا المضيف إلا HTTPS لمدة سنة، والمتصفحات تتجاهلها إذا وصلت عبر HTTP غير مشفّر. ناجح.
• الشهادة تغطي *.shop.example.com، وتتصل سلسلتها بجذر موثوق، وتنتهي صلاحيتها بعد 41 يوماً. هذا ليس عيباً، لكن المختبِر يسأل: من يجدّدها، وكيف يُنبَّه الفريق؟
• تُظهر وحدة التحكم (Console) محتوى مختلطاً (mixed content) محجوباً: الصفحة تحمّل سكربت أداة الدردشة من عنوان http://، والمتصفحات تحجب السكربتات غير الآمنة في صفحات HTTPS، فيختفي زر الدردشة. عيب.
• التطبيق لا يصل إلى واجهة API، مع أن العنوان نفسه يُفتح دون تحذير في متصفح سطح المكتب. يفشل curl، ويُظهر الأمر openssl s_client -connect api-staging.shop.example.com:443 -showcerts شهادة الخادم وحدها: الشهادة الوسيطة غائبة. عيب، ويُبلَّغ عنه مع هذه الأدلة:

Title:    واجهة api-staging ترسل سلسلة TLS ناقصة؛ التطبيق وcurl يرفضانها
URL:      https://api-staging.shop.example.com/v1/health
Clients:  تطبيق Android 3.8.0 (نسخة staging)؛ curl على Ubuntu
curl:     curl: (60) SSL certificate problem: unable to get local issuer certificate
Android:  SSLHandshakeException: Trust anchor for certification path not found
Browser:  العنوان نفسه يُفتح دون تحذير في Chrome على سطح المكتب
Chain:    openssl s_client -showcerts يعرض شهادة واحدة (شهادة الخادم)
Expected: يرسل الخادم شهادته والشهادة الوسيطة؛ ويتصل العملاء والتحقق
          من الشهادات مفعّل
Note:     لا يُتجاوز العيب بـ curl -k أو بإعداد في التطبيق يثق بكل الشهادات

جرّبها: فاحص إعادة التوجيه جرّبها: محلّل ترويسات الأمان جرّبها: مختبِر نقاط نهاية API

أسئلة شائعة

المراجع

• RFC 9110: HTTP SemanticsIETF · 2022معاني أساليب HTTP وحقول الترويسات ورموز الحالة والتفاوض على المحتوى، بغضّ النظر عن إصدار البروتوكول.
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3IETF · 2018مصافحة TLS 1.3 وبروتوكول السجلات اللذان يحميان حركة HTTPS.
• RFC 6797: HTTP Strict Transport Security (HSTS)IETF · 2012ترويسة Strict-Transport-Security التي تُلزم المتصفح باستخدام HTTPS فقط مع المضيف.
• Overview of HTTP — MDNMDN Web Docs (Mozilla)كيف يعمل HTTP: بروتوكول عميل–خادم عديم الحالة، يرسل فيه العميل طلباً ويردّ الخادم برسالة استجابة.