ما الفرق بين HTTP وHTTPS؟

عندما تفتح أي موقع على الإنترنت ستلاحظ أن العنوان يبدأ غالبًا بـ https://، بينما قد تصادف أحيانًا عنوانًا يبدأ بـ http://. بالنسبة للمستخدم العادي قد يبدو الفرق مجرد حرف إضافي، لكن من الناحية التقنية والأمنية هناك فرق كبير جدًا بين البروتوكولين. كلاهما يُستخدم في نقل بيانات الويب بين المتصفح والخادم، لكن HTTPS يضيف طبقة حماية تعتمد على TLS بحيث يصبح الاتصال مشفرًا ومحمياً بدرجة أكبر من التجسس أو التعديل أثناء انتقال البيانات.

لفهم الفرق بصورة صحيحة، من المهم أولًا أن نفصل بين وظيفة HTTP ووظيفة TLS. HTTP أو Hypertext Transfer Protocol هو بروتوكول يحدد كيف يرسل العميل طلبًا إلى الخادم وكيف يعيد الخادم الاستجابة. أما HTTPS فهو HTTP يعمل داخل قناة محمية باستخدام TLS. لذلك HTTPS ليس بروتوكول ويب مختلفًا بالكامل عن HTTP، بل هو HTTP مع طبقة أمان إضافية تمنح الاتصال التشفير والتحقق من هوية الخادم وحماية سلامة البيانات أثناء النقل.

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

ما الفرق بين HTTP وHTTPS؟

HTTP هو لغة التواصل بين المتصفح وخادم الويب

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

قد يرسل المتصفح طلبًا مثل GET للحصول على صفحة، أو POST لإرسال بيانات، ثم يرد الخادم بـResponse تحتوي على Status Code وHeaders والمحتوى المطلوب.

هذه العملية هي امتداد لما شرحناه في مقال API؛ فالويب نفسه يعتمد بكثافة على نموذج Request وResponse.

HTTP يحدد قواعد هذا الحوار، لكنه في شكله التقليدي لا يوفر تشفيرًا لحركة البيانات أثناء النقل.

وهنا ظهرت الحاجة إلى HTTPS.

HTTPS يضيف TLS إلى عملية التواصل

عندما تستخدم عنوانًا يبدأ بـHTTPS، يتم إنشاء اتصال آمن باستخدام TLS أو Transport Layer Security قبل تبادل المحتوى الحساس عبر HTTP.

TLS يساعد على توفير ثلاث خصائص أساسية:

التشفير حتى لا تكون البيانات المقروءة سهلة الاعتراض.

سلامة البيانات حتى يمكن اكتشاف التلاعب بالمحتوى أثناء النقل.

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

هذه العناصر الثلاثة هي جوهر الفرق الأمني بين HTTP وHTTPS.

التشفير يمنع قراءة البيانات بسهولة أثناء انتقالها

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

أما مع HTTPS، فإن المحتوى بين المتصفح والخادم يكون مشفرًا ضمن جلسة TLS.

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

المشكلة في الاعتقاد أن HTTPS يخفي كل شيء

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

الحل هو فهم حدود الحماية

HTTPS يحمي محتوى الاتصال بين العميل والخادم من القراءة والتعديل أثناء النقل، لكنه ليس أداة لإخفاء وجود الاتصال بالكامل ولا بديلًا عن VPN أو أنظمة الخصوصية الأخرى.

سلامة البيانات تمنع التعديل الصامت أثناء النقل

الحماية لا تتعلق بالسرية فقط.

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

TLS يحتوي على آليات للتحقق من سلامة البيانات أثناء النقل، بحيث يصبح التلاعب غير المكتشف أصعب بكثير.

هذه الخاصية مهمة جدًا لأنها تمنع المهاجم من تعديل الاتصال بسهولة حتى لو لم تكن البيانات نفسها سرية.

الشهادة الرقمية تساعد المتصفح على التحقق من الخادم

عند إنشاء اتصال HTTPS يقدم الخادم عادة Digital Certificate تحتوي على معلومات مرتبطة بالنطاق ومفتاح عام وتوقيع من جهة إصدار شهادات موثوقة وفق سلسلة الثقة المستخدمة.

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

إذا نجحت عملية التحقق، يستطيع المتصفح متابعة إنشاء الاتصال الآمن.

المشكلة في اعتبار الشهادة دليلًا على أن الموقع نفسه صادق

هذه نقطة خطيرة جدًا.

وجود HTTPS لا يعني أن الموقع التجاري أو الخدمة جديرة بالثقة من الناحية الأخلاقية أو أنها ليست موقع تصيد. يمكن لموقع احتيالي الحصول على شهادة صحيحة لنطاقه هو.

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

الحل

تحقق من اسم النطاق نفسه وليس رمز القفل فقط. إذا كان النطاق مزيفًا لكنه يستخدم HTTPS، فالخطر ما زال موجودًا.

رحلة TLS تبدأ بعملية Handshake

قبل إرسال بيانات HTTP المشفرة، يحتاج العميل والخادم إلى الاتفاق على إعدادات الأمان وإنشاء مفاتيح الجلسة. هذه العملية تسمى TLS Handshake.

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

بعد انتهاء Handshake يمكن إرسال HTTP داخل الاتصال المشفر.

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

TLS 1.3 هو الإصدار الحديث الأساسي

الإصدارات الحديثة من المتصفحات والخوادم تعتمد بدرجة كبيرة على TLS 1.3، مع استمرار دعم TLS 1.2 في بعض البيئات. أما TLS 1.0 و1.1 فأصبحت قديمة ولا ينبغي الاعتماد عليها في الأنظمة الحديثة.

السبب أن بروتوكولات الأمان تتطور مع الوقت، وبعض الخوارزميات والإعدادات القديمة لم تعد مناسبة لمستوى الحماية الحالي.

لهذا لا يكفي أن تقول إن موقعك يستخدم HTTPS؛ يجب أن تكون إعدادات TLS نفسها حديثة وآمنة.

HTTP وHTTPS يستخدمان المنافذ بصورة مختلفة عادة

تاريخيًا يستخدم HTTP غالبًا Port 80 بينما يستخدم HTTPS غالبًا Port 443.

هذه القاعدة مفيدة في الفهم، لكنها ليست قانونًا يمنع تشغيل الخدمات على منافذ مختلفة. يمكن تشغيل HTTP أو HTTPS على منافذ أخرى إذا تم تصميم الخدمة لذلك.

المهم هو أن Port يساعد نظام التشغيل على تحديد الخدمة، بينما البروتوكول نفسه يحدد طريقة التواصل.

إعادة التوجيه من HTTP إلى HTTPS خطوة مهمة

حتى إذا كان الموقع يعمل بالكامل عبر HTTPS، قد يكتب المستخدم:

http://example.com

بدل:

https://example.com

لهذا تضبط مواقع كثيرة خادم HTTP ليعيد المستخدم تلقائيًا إلى النسخة المشفرة باستخدام Redirect دائم.

هذه خطوة مهمة، لكنها لا تحل كل المشكلات الأمنية وحدها.

المشكلة في أول اتصال غير مشفر

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

لهذا ظهر HSTS.

HSTS يجبر المتصفح على استخدام HTTPS

HTTP Strict Transport Security أو HSTS عبارة عن Header يرسلها الموقع ليخبر المتصفح بأن هذا النطاق يجب الوصول إليه عبر HTTPS فقط.

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

وهذا يقلل خطر هجمات تعرف باسم SSL Stripping أو محاولات إبقاء المستخدم على اتصال HTTP.

HSTS Preload يزيد الحماية من أول اتصال

توجد قوائم Preload تستخدمها متصفحات معروفة تضم نطاقات معروفة بأنها يجب أن تعمل عبر HTTPS دائمًا.

عندما يكون النطاق في القائمة، يستطيع المتصفح معرفة ذلك حتى قبل زيارة الموقع للمرة الأولى، مما يقلل نافذة الخطر المتعلقة بأول اتصال.

لكن إضافة نطاق إلى Preload تحتاج إلى فهم والتزام؛ لأنك تعلن عمليًا أن كل أجزاء النطاق المتضمنة يجب أن تكون جاهزة لـHTTPS وفق السياسة المستخدمة.

Mixed Content يضعف أمان صفحة HTTPS

قد تعمل الصفحة الرئيسية عبر HTTPS، لكنها تطلب صورة أو JavaScript أو CSS عبر HTTP. هنا تظهر مشكلة تسمى Mixed Content.

الصفحة تبدو آمنة من الخارج، لكن جزءًا من محتواها يسافر عبر قناة غير مشفرة.

هذه مشكلة خطيرة خصوصًا مع JavaScript، لأن تعديل ملف Script قد يسمح بتغيير سلوك الصفحة بالكامل.

لهذا تمنع المتصفحات الحديثة أنواعًا من Mixed Content أو تحاول ترقيتها إلى HTTPS عندما يكون ذلك ممكنًا.

المشكلة بعد نقل موقع قديم إلى HTTPS

قد يفعّل صاحب الموقع الشهادة ويغير العنوان الرئيسي، ثم يلاحظ أن التصميم مكسور أو بعض الصور لا تظهر.

السبب قد يكون أن الموقع ما زال يحتوي على روابط داخلية تبدأ بـHTTP.

الحل

راجع جميع الموارد: JavaScript وCSS والصور والخطوط وiframes والتنزيلات. استخدم HTTPS في كل الموارد أو روابط مناسبة لا تجبر المتصفح على اتصال غير آمن.

يمكن أيضًا استخدام سياسات مثل upgrade-insecure-requests في CSP ضمن عمليات الانتقال المناسبة، لكن الأفضل إصلاح الروابط الأصلية قدر الإمكان.

المشكلة الأشهر: شهادة SSL منتهية الصلاحية

رغم أن الاسم الشائع ما زال "SSL Certificate"، فإن التقنية الحديثة المستخدمة هي TLS. وإذا انتهت صلاحية شهادة الموقع، سيعرض المتصفح تحذيرًا لأن الخادم لم يعد يقدم شهادة صالحة ضمن المدة الزمنية المحددة.

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

الحل لا يجب أن يعتمد على التذكر اليدوي فقط

استخدم تجديدًا تلقائيًا للشهادات عندما تسمح البنية بذلك، مع Monitoring ينبهك قبل انتهاء الصلاحية.

كما يجب اختبار عملية التجديد نفسها، لأن وجود Automation لا يعني أنها تعمل للأبد. قد يتغير DNS أو تنتهي صلاحية حساب أو يحدث خطأ في الإعدادات يمنع التجديد.

عدم تطابق اسم النطاق مع الشهادة يسبب تحذيرًا

قد تكون الشهادة صالحة من حيث التاريخ، لكنها صادرة لـexample.com بينما المستخدم يزور other.example.com غير الموجود ضمن أسماء الشهادة.

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

الحل

تأكد أن الشهادة تغطي جميع أسماء النطاقات المطلوبة، سواء باستخدام أسماء متعددة داخل الشهادة أو Wildcard وفق احتياجك وتصميمك.

لا تحاول تعليم المستخدمين تجاهل التحذير؛ أصلح سبب عدم التطابق.

الشهادة ذاتية التوقيع ليست مناسبة للموقع العام عادة

في بيئة اختبار أو شبكة داخلية قد تستخدم Self-Signed Certificate لأغراض معينة، لكنها لن تكون موثوقة تلقائيًا لدى المتصفح العام لأن سلسلة الثقة لا تنتهي إلى CA معروفة لديه.

في بيئات الشركات يمكن إدارة CAs داخلية وتوزيع الثقة على الأجهزة بطريقة منظمة.

أما الموقع العام فيحتاج عادة إلى شهادة صادرة من جهة موثوقة لدى المتصفحات.

المشكلة في تدريب الموظفين على الضغط على Advanced ثم Continue

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

الحل

أصلح بنية الثقة حتى تعمل المواقع الداخلية الصحيحة دون تحذيرات غير ضرورية، وتعامل مع أي تحذير غير متوقع كحدث يحتاج إلى تحقق.

HTTPS لا يحمي خادمًا ضعيفًا من الاختراق

قد يستخدم الموقع أفضل شهادة وTLS حديثة، لكنه يحتوي على ثغرة SQL Injection أو كلمات مرور ضعيفة أو لوحة إدارة مكشوفة.

HTTPS لا يصلح هذه المشكلات.

هو يحمي الاتصال في الأساس، وليس منطق التطبيق بالكامل.

يمكن تشبيه الأمر بسيارة مصفحة تنقل رسالة إلى منزل غير مؤمّن. الرسالة تصل بأمان، لكن إذا كان باب المنزل مفتوحًا فالمشكلة لم تختفِ.

HTTPS لا يمنع البرمجيات الخبيثة على جهاز المستخدم

إذا كان جهازك نفسه مصابًا ببرنامج خبيث يستطيع قراءة ما تكتبه قبل تشفيره، فلن يمنع HTTPS ذلك بالضرورة.

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

ولهذا الأمن دائمًا متعدد الطبقات.

HTTPS لا يجعل الموقع المزيف موقعًا حقيقيًا

قد يبني المهاجم موقعًا مثل:

bank-security-example.com

ويحصل على شهادة صحيحة لهذا النطاق.

سيظهر HTTPS لأن الاتصال بالفعل مشفر بينك وبين الموقع المزيف.

لكن المشكلة أن الوجهة نفسها خاطئة.

الحل

ركز على النطاق. لا تسأل فقط: هل هناك HTTPS؟ بل اسأل: هل هذا هو النطاق الرسمي الذي كنت أريد الوصول إليه؟

وهذا يربط مباشرة بموضوع التصيد الإلكتروني الذي تناولناه سابقًا.

الفرق بين التشفير المتماثل وغير المتماثل يظهر داخل TLS

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

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

لا يحتاج المبتدئ إلى حفظ الخوارزميات الرياضية الآن، لكن من المفيد أن يعرف أن "HTTPS مشفر" لا يعني وجود مفتاح واحد ثابت يستخدمه كل زائر للموقع.

المفتاح الخاص يجب أن يبقى سريًا

الشهادة تحتوي على معلومات عامة، ومنها Public Key أو معلومات مرتبطة به، لكن الخادم يمتلك Private Key يجب حمايته بدرجة عالية.

إذا سُرق المفتاح الخاص، قد تصبح هناك مخاطر كبيرة تعتمد على السيناريو والتقنيات المستخدمة.

الحل

احمِ المفاتيح من الوصول غير الضروري، ولا ترفعها إلى GitHub، واستخدم نظم إدارة أسرار وصلاحيات مناسبة، وقم بتدوير أو استبدال المفتاح عند الاشتباه في تسريبه.

هذه نقطة عملية جدًا تربط بين HTTPS ومقال GitHub السابق: لا تضع ملف المفتاح الخاص داخل Repository.

Certificate Authority جزء من سلسلة الثقة

المتصفح يحتوي على مجموعة من جهات إصدار شهادات يثق بها وفق نظامه. عندما يرى شهادة موقع، يستطيع تتبع سلسلة التوقيع للوصول إلى جهة موثوقة.

هذا يسمى Chain of Trust.

قد توجد شهادة للموقع وشهادة Intermediate ثم Root CA.

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

مشكلة Incomplete Certificate Chain تظهر أحيانًا على أجهزة دون أخرى

قد يعمل الموقع في متصفح معين لأن الجهاز يمتلك Intermediate Certificate مخزنة، بينما يفشل على جهاز آخر.

هذا يجعل المشكلة مربكة.

الحل

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

اختبر الموقع من عدة بيئات وأدوات فحص TLS لتكتشف المشكلة قبل المستخدمين.

HTTPS يحتاج إلى إعداد قوي وليس شهادة فقط

تركيب الشهادة هو البداية وليس النهاية.

يجب مراجعة إصدارات TLS المسموحة، وCipher Suites، والشهادات، وHSTS، وطريقة إعادة التوجيه، والموارد الداخلية.

ترك بروتوكولات قديمة أو إعدادات ضعيفة قد يقلل قيمة الحماية.

الحل

اعتمد إعدادات حديثة موصى بها من الجهات التقنية الموثوقة بدل نسخ Configuration قديمة من مقال قبل عشر سنوات.

التشفير مجال يتغير مع تطور الهجمات والمعايير.

TLS 1.0 و1.1 لم يعودا خيارات مناسبة للمواقع الحديثة

الأنظمة الحديثة يجب أن تعتمد على TLS 1.2 وTLS 1.3 وفق توافقها واحتياجاتها، مع تفضيل الإعدادات الحديثة.

إبقاء الإصدارات القديمة لمجرد دعم أجهزة شديدة القدم قد يضيف مخاطر.

الحل

افهم جمهورك ومتطلبات التوافق، ثم أوقف البروتوكولات القديمة عندما لا تكون ضرورية.

إذا كان لديك جهاز قديم جدًا لا يدعم إلا بروتوكولًا غير آمن، فقد يكون الحل الحقيقي تحديث الجهاز أو عزله بدل إضعاف أمن الموقع كله.

HTTPS يمكن أن يحسن الثقة والتوافق مع ميزات المتصفح الحديثة

المتصفحات الحديثة تعتبر صفحات HTTPS Secure Contexts، وبعض واجهات الويب القوية لا تكون متاحة بشكل كامل إلا في سياق آمن.

وهذا يعني أن HTTPS لم يعد فقط ميزة إضافية للمواقع التي تحتوي على دفع أو تسجيل دخول؛ أصبح جزءًا أساسيًا من منصة الويب الحديثة.

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

المشكلة القديمة: تشفير تسجيل الدخول فقط وترك بقية الموقع HTTP

في الماضي كانت بعض المواقع تستخدم HTTPS في صفحة كلمة المرور ثم تعود إلى HTTP بعد تسجيل الدخول.

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

الحل

استخدم HTTPS للموقع بالكامل، من أول صفحة إلى آخر مورد.

هذا هو النهج الطبيعي للويب الحديث.

Cookies تحتاج إلى إعدادات أمنية مناسبة أيضًا

حتى عند استخدام HTTPS، يجب إدارة Session Cookies بعناية.

يمكن تحديد Secure حتى لا يرسل المتصفح Cookie عبر HTTP، ويمكن استخدام خصائص أخرى مثل HttpOnly وSameSite وفق احتياج التطبيق الأمني.

HTTPS يوفر القناة، بينما إعدادات التطبيق تحدد كيف تستخدم البيانات داخل هذه القناة.

التحويل من HTTP إلى HTTPS يحتاج إلى خطة

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

يمكن أن يؤدي النقل غير المدروس إلى Mixed Content أو Redirect Loops أو كسر API قديمة.

طريقة الانتقال الأفضل

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

لا تفعّل سياسة صارمة جدًا قبل التأكد أن كل Subdomain مطلوب يدعم HTTPS، خصوصًا عند استخدام includeSubDomains.

Redirect Loop من المشكلات الشائعة خلف Proxy أو Load Balancer

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

الحل

اضبط Reverse Proxy والتطبيق بطريقة صحيحة حتى يعرفا Scheme الأصلي باستخدام رؤوس موثوقة وإعدادات صحيحة، ولا تثق في Headers يرسلها المستخدم مباشرة دون قيود.

هذه المشكلة شائعة جدًا في البيئات السحابية الحديثة.

HTTPS في بيئات CDN يحتاج إلى حماية الطرفين

عندما تستخدم CDN قد يكون هناك اتصال من المستخدم إلى CDN واتصال آخر من CDN إلى Origin Server.

تشغيل HTTPS أمام المستخدم مع ترك الاتصال من CDN إلى Origin غير مشفر في سيناريو حساس قد يترك جزءًا من الرحلة دون حماية.

الحل

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

لا تجعل "المستخدم يرى القفل" هو المعيار الوحيد.

التشفير له تكلفة لكنها لم تعد عذرًا منطقيًا لتجنب HTTPS

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

TLS 1.3 كذلك حسنت جوانب من إنشاء الاتصال.

لذلك لم يعد هناك مبرر عملي لموقع حديث عام يعتمد على HTTP غير المشفر لحركة الويب العادية.

HTTP/2 وHTTP/3 لا يعنيان أن HTTPS اختفى

قد تسمع عن HTTP/2 وHTTP/3 وتتساءل عن علاقتها بـHTTPS.

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

HTTP/3 يستخدم QUIC الذي يعمل فوق UDP ويحتوي على TLS 1.3 كجزء أساسي من بنيته الأمنية.

لذلك تطور HTTP لا يلغي HTTPS، بل جعل التشفير أكثر اندماجًا في الويب الحديث.

المشكلة في استخدام كلمة SSL لكل شيء

ستسمع عبارات مثل "شراء SSL" أو "SSL Certificate". المصطلح ما زال شائعًا تجاريًا، لكن SSL بروتوكول قديم وتم استبداله بـTLS منذ سنوات طويلة.

عندما تستخدم موقعًا حديثًا عبر HTTPS، فأنت تستخدم TLS وليس SSL القديم.

استخدام كلمة SSL في الحديث اليومي ليس مشكلة كبيرة، لكن من المهم تقنيًا أن تعرف الفرق حتى لا تعتقد أن SSL 3.0 مثلًا شيء يجب تشغيله.

الشهادات المجانية جعلت HTTPS أسهل بكثير

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

هذا جعل تشغيل HTTPS على المواقع الحديثة أسهل بكثير.

لكن "مجانية الشهادة" لا يعني أن إدارة الأمن أصبحت بلا مسؤولية؛ ما زلت تحتاج إلى حماية المفاتيح وتحديث الخادم ومراجعة التطبيق.

تجديد الشهادات تلقائيًا يحتاج إلى مراقبة

حتى إذا كانت الشهادة تتجدد تلقائيًا، يمكن أن تفشل العملية بسبب تغيير DNS أو Firewall أو انتهاء Credential أو خطأ في خدمة الأتمتة.

الحل

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

وجود طبقة Monitoring مستقلة أفضل من الاعتماد فقط على رسالة من خدمة التجديد.

خطأ وقت الجهاز يمكن أن يجعل شهادة صحيحة تبدو غير صالحة

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

هذه مشكلة تظهر أحيانًا على أجهزة قديمة أو أنظمة فقدت مزامنة الوقت.

الحل

تأكد من إعداد الوقت والمنطقة الزمنية ومزامنة الساعة قبل افتراض أن كل مواقع HTTPS تواجه مشكلة في شهاداتها.

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

برامج الحماية والشبكات المؤسسية قد تفحص HTTPS بطريقة خاصة

بعض المؤسسات تستخدم أنظمة TLS Inspection أو Proxy تقوم بفك وفحص الحركة ثم إعادة تشفيرها باستخدام شهادة تثق بها أجهزة المؤسسة.

هذه التقنية تحتاج إلى إدارة شديدة الدقة لأنها تغير نموذج الثقة الطبيعي للاتصال.

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

كما يجب مراعاة الجوانب الأمنية والخصوصية والقانونية عند تصميم مثل هذه الأنظمة.

HTTPS يحمي البيانات أثناء النقل لا بعد وصولها إلى الخادم

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

إذا كان الخادم يخزن كلمة المرور كنص واضح، فهذه مشكلة خطيرة لا يحلها HTTPS.

الحل

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

HTTPS جزء من هذه المنظومة فقط.

كلمات المرور تحتاج إلى Hashing وليس مجرد HTTPS

يجب إرسال كلمة المرور عبر قناة آمنة مثل HTTPS، لكن الخادم لا ينبغي عادة أن يخزنها كقيمة قابلة للاسترجاع بسهولة.

تستخدم الأنظمة الصحيحة خوارزميات مخصصة لتجزئة كلمات المرور مع Salts وإعدادات مناسبة.

هذا يوضح الفرق بين Encryption in Transit وحماية البيانات At Rest.

كل واحدة تحل مشكلة مختلفة.

HTTP قد يبقى داخل بعض البيئات لكنه يحتاج إلى قرار واعٍ

في الشبكات الداخلية أو بيئات التطوير قد ترى HTTP ما زال مستخدمًا، خصوصًا على localhost أو بين خدمات داخل بيئة مسيطَر عليها.

لكن مجرد كون الخدمة داخلية لا يعني أن التشفير غير مطلوب دائمًا.

في بيئات Zero Trust الحديثة، تفترض المؤسسات أن الشبكة الداخلية نفسها ليست ضمانًا كافيًا للثقة، ولذلك تشفر الاتصالات الداخلية الحساسة أيضًا.

القرار يجب أن يعتمد على المخاطر والبنية، لا على عبارة "هذا داخلي فلا يحتاج أمانًا".

المتصفح لم يعد يعرض القفل بالطريقة نفسها دائمًا

واجهات المتصفحات تتغير مع الوقت، وبعضها لم يعد يبرز HTTPS كميزة استثنائية بالطريقة القديمة، لأن الاتصال الآمن أصبح الوضع المتوقع الطبيعي.

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

لذلك لا تعتمد على حفظ شكل أيقونة معينة؛ راقب العنوان وتحذيرات المتصفح وتحقق من النطاق.

الفرق في الأداء أصبح أكثر تعقيدًا من القول إن HTTP أسرع

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

لهذا لا ينبغي اتخاذ قرار أمني خطير لإزالة HTTPS بهدف الحصول على فرق أداء صغير أو غير موجود عمليًا.

مشكلات HTTPS تحتاج إلى تشخيص مرتب

عندما يظهر خطأ في HTTPS، لا تغير الشهادة والخادم وDNS مرة واحدة. حدد أولًا طبيعة الخطأ.

قد تكون المشكلة في انتهاء الشهادة، أو عدم تطابق الاسم، أو Chain ناقصة، أو وقت الجهاز، أو بروتوكول TLS غير متوافق، أو Mixed Content، أو Proxy، أو DNS يشير إلى خادم قديم يحمل شهادة مختلفة.

يمكن تنظيم التشخيص بهذه الخطوات:

• تحقق من اسم النطاق الذي يراه المستخدم.

• افحص الشهادة وتاريخ صلاحيتها والأسماء التي تغطيها.

• تحقق من سلسلة الثقة.

• اختبر إصدارات TLS التي يقبلها الخادم.

• افحص DNS لمعرفة الخادم الذي تصل إليه.

• راجع Reverse Proxy أو CDN إذا كان موجودًا.

• افحص Developer Console لمشكلات Mixed Content.

هذا الترتيب يمنع إضاعة الوقت في تعديل أجزاء غير مرتبطة بالمشكلة.

HTTP Status Codes لا تتغير لأنها HTTPS

عندما تستخدم HTTPS ستستمر في رؤية 200 و404 و500 وغيرها، لأن HTTP ما زال يعمل داخل القناة المشفرة.

HTTPS لا يغير منطق Request وResponse نفسه بصورة أساسية.

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

هذا يؤكد مجددًا أن TLS يحمي قناة HTTP، ولا يستبدل البروتوكول.

الشهادة الصحيحة لا تمنع خطأ 500

قد يكون TLS ممتازًا والشهادة سليمة، لكن التطبيق نفسه يعاني من Bug يؤدي إلى 500 Internal Server Error.

أحيانًا يرى المبتدئ HTTPS في العنوان فيستبعد الخادم من المشكلة.

الحل هو فصل طبقة النقل الآمنة عن منطق التطبيق. إذا اكتملت TLS Handshake وبدأت تحصل على HTTP Responses، فإن مشكلة التطبيق قد تكون في طبقة أعلى.

فهم HTTP وHTTPS يساعد المبرمج على تشخيص APIs

عند التعامل مع APIs، قد يفشل الاتصال لأن الشهادة غير موثوقة، أو لأن Endpoint تستخدم HTTP بينما التطبيق يعمل في سياق HTTPS، أو لأن Redirect يغير Method بصورة غير متوقعة وفق السيناريو.

المبرمج الذي يفهم البروتوكولات يستطيع التفريق بين خطأ TLS وخطأ HTTP وخطأ داخل JSON أو التطبيق.

وهذا يقلل الاعتماد على التجربة العشوائية.

فهم HTTPS مهم جدًا لمتخصص الأمن السيبراني

محلل SOC قد يرى اتصالات مشفرة ولا يستطيع قراءة المحتوى مباشرة من سجلات الشبكة العادية، لكنه يستطيع تحليل Metadata وسلوك الاتصال والشهادات والوجهات ضمن الصلاحيات والأدوات المتاحة.

كما تظهر مشاكل الشهادات والتشفير في تقييمات الأمن واختبارات التطبيقات.

ولهذا يعد TLS موضوعًا أساسيًا لمن يريد فهم أمن الويب بعمق.

HTTP وHTTPS في صورة ذهنية واحدة

تخيل أنك تريد إرسال مستند إلى شركة.

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

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

التشبيه مبسط، لكنه يوضح لماذا الحرف S في HTTPS يعني أكثر بكثير من مجرد تغيير شكل العنوان.

أبرز الأخطاء في فهم الفرق بين HTTP وHTTPS

من أكثر الأخطاء شيوعًا الاعتقاد أن HTTPS يعني أن الموقع غير احتيالي، أو أن القفل يمنع كل أنواع الاختراق، أو أن التشفير يخفي عنوان الوجهة بالكامل، أو أن الشهادة تحمي قاعدة البيانات من الاختراق.

كما يعتقد بعض أصحاب المواقع أن تركيب الشهادة وحده يكفي، ثم يتركون Mixed Content أو HTTP Endpoints أو TLS قديمًا أو مفاتيح خاصة مكشوفة.

الحل هو التعامل مع HTTPS كجزء من منظومة أمان كاملة: شهادة صحيحة، TLS حديث، HTTPS على كل الموارد، HSTS عند ملاءمته، حماية المفاتيح، تطبيق آمن، صلاحيات صحيحة، وتحديثات مستمرة.

الخلاصة: الفرق الحقيقي بين HTTP وHTTPS هو الثقة في قناة الاتصال

HTTP هو البروتوكول الذي يسمح للمتصفح والخادم بتبادل Requests وResponses وموارد الويب. أما HTTPS فهو HTTP يعمل داخل قناة محمية بواسطة TLS.

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

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

بالنسبة لصاحب الموقع، تشغيل HTTPS بطريقة صحيحة يعني أكثر من شراء شهادة. يجب استخدام TLS حديث، وتجديد الشهادات ومراقبتها، وإزالة Mixed Content، وإعادة توجيه HTTP إلى HTTPS، ودراسة استخدام HSTS، وحماية Private Keys.

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

وعندها يصبح الفرق بين HTTP وHTTPS واضحًا جدًا: الأول يحدد كيف يتحدث المتصفح والخادم، بينما الثاني يجعل هذا الحديث يحدث داخل قناة مشفرة ومحمية من القراءة والتعديل أثناء النقل بدرجة كبيرة.

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