ما هو HTTP وHTTPS

ما الذي يُتبادَل فعلا حين تفتح عنوانا؟

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

لكل منهما سطر أول، ثم مجموعة رؤوس، ثم بدن. والرؤوس هي موضع كل شيء تقريبا: لغة المتصفح، وهل المحتوى مضغوط، وكم يُسمح بتخزين الرد مؤقتا، وبماذا يعرّف الخادم نفسه. وحين يتصرف صفحة تصرفا غريبا، لا يكون الجواب في البدن عادة بل في الرؤوس.

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

والنسخ الأحدث تحمل الاتفاق نفسه على السلك بترتيب أفضل وضغط أكثر، ولا تغيّر معنى الطلب والرد. وصفحات هذا الموقع تجيب على HTTP/2، وشبكة توصيل المحتوى الجالسة أمامه تعلن في رأس منفصل أن HTTP/3 جاهز أيضا. وهذا الفارق غير مرئي للقارئ، وينبغي أن يكون كذلك.

كيف تقرأ رمز الحالة؟

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

ولننهِ هنا قراءة خاطئة شائعة: 404 تعني أن الصفحة لم تُوجد، لا أن الموقع معطّل. فالخادم كان سليما تماما واستطاع أن يقول بثقة إنه لا يملك مثل هذا الشيء. وبدنه ليس فارغا بالضرورة؛ فصفحة عدم الوجود في هذا الموقع صفحة كاملة بقائمة وبحث، وHTML الخاص بها يزيد على مئة كيلوبايت. فالرمز وشكل الصفحة أمران مستقلان.

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

ما الذي يؤمّنه HTTPS بالضبط؟

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

ويتم هذا عبر شهادة وقّعتها جهة إصدار خارجية، إضافة إلى مصافحة قصيرة في بداية الاتصال تبني مفتاح تشفير تلك الجلسة. وشهادة هذا الموقع يمكن النظر إليها الآن: مُصدرها Google Trust Services، وهي صالحة لـ rgb.ir ولأي نطاق فرعي منه، وعمرها تسعون يوما. وقِصر العمر مقصود؛ فالشهادة قصيرة العمر تتجدد تلقائيا، وإن تسرّب مفتاح يوما بقيت نافذة إساءة الاستعمال صغيرة.

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

وحدّ هذه الحماية: HTTPS يؤمّن الطريق فقط. فما إن تصل البيانات إلى الخادم حتى تكون قد خرجت من حماية هذه الطبقة. ونموذج مشفّر تماما يمكن أن يخزّن كلمة مرورك في ملف نصي على خادم لا يراقبه أحد. والقفل لا يقول شيئا عن ذلك ولا يدّعيه.

ما الذي لا يضمنه القفل بجانب العنوان؟

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

وهذا ليس رأينا. فإحدى أكبر جهات إصدار الشهادات المجانية في العالم كتبت وهي تشرح سياستها أن شهادة التحقق من النطاق تؤكد فقط أن مفتاحا عاما يخص نطاقا و«لا تقول شيئا آخر عن محتوى الموقع أو عمّن يديره»، وأضافت أن هذه الشهادات لا تحمل أي معلومة عن سمعة موقع أو هويته الواقعية أو أمانه. أي أن المُصدر نفسه يصرّح بأن القفل ليس ختم موافقة على المحتوى.

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

والذي ينبغي أن تنظر إليه فعلا هو اسم النطاق، حرفا حرفا: في أي عنوان، الجزء المهم هو الواقع مباشرة قبل أول شرطة مائلة. وأي شيء يمكن أن يوضع قبله. وموقفنا: لا تنظر إلى القفل، انظر إلى النطاق، وإن وصل الرابط برسالة نصية أو عبر تطبيق مراسلة فلا تنقره أصلا واكتب العنوان بنفسك.

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

كيف تنقل موقعا إلى HTTPS نقلا صحيحا؟

الحصول على الشهادة أسهل جزء، وغالبا تنجزه الاستضافة نفسها. والذي يفسد العمل هو الثلاثة التالية.

أولا، كل طلب HTTP يجب أن يذهب إلى النسخة الآمنة من العنوان نفسه برمز 301، لا إلى الصفحة الأولى. فإرسال كل شيء إلى الصفحة الأولى أبسط الطرق وأسوأها، لأنه يقتل كل رابط قديم. وثانيا المحتوى المختلط: إن كانت الصفحة آمنة لكنها تستدعي صورة أو نصا برمجيا من عنوان غير آمن، فإما أن يحجبه المتصفح أو يحذّر منه. وثالثا رأس HSTS، الذي يقول للمتصفح ألا يجرّب HTTP لهذا النطاق مرة أخرى؛ وقيمته على هذا الموقع سنة واحدة.

وثمة كلفة لا يتحدث عنها أحد: كل قفزة زائدة ذهاب وإياب. فعلى هذا الموقع، من يكتب العنوان القديم rgb.ir/seo/ بلا https يأخذ قفزتين، أولاهما من HTTP إلى HTTPS والأخرى من العنوان القديم إلى الجديد، وبعدها فقط يصل أول بايت من الصفحة. وهذا لا يهم زائرا واحدا؛ لكنه يهم رابطا يتكرر في الإعلانات والقوائم وتواقيع البريد. والقاعدة بسيطة: حيثما تملك أنت التحكم، اربط العنوان النهائي لا القديم.

وحدّ ذلك: HSTS التزام لا إعداد قابل للتراجع. فالمتصفح الذي رأى الرأس يرفض الاتصال بنطاقك عبر HTTP حتى انتهاء المدة، ولو انتهت صلاحية شهادتك. فإن لم تكن واثقا أن HTTPS دائم، فابدأ هذا الرأس بمدة قصيرة.

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