كيفية جعل HTTPS هو الطلب الأول عبر VPN

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

الخطوة 1: تأكد من ماهية الطلب الأول فعليًا

قبل تغيير أي شيء، انظر إلى ما يرسله المتصفح. افتح لوحة الشبكة مع إعادة تحميل الصفحة من ذاكرة التخزين المؤقت الباردة واقرأ الصف الأول: إذا كان المخطط http والحالة 301 أو 308، فكل شيء بعد هذا الصف هو طلب ثانٍ. curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com يعيد إنتاج نفس التسلسل خارج المتصفح ويطبع عنوان URL الذي انتهى بك الأمر إليه.

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

الخطوة 2: قم بتشغيل وضع HTTPS فقط بالمتصفح

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

في Firefox، توجد عناصر التحكم خلف about:config وفي صفحة إعدادات الخصوصية، مع dom.security.https_only_mode كمحول ويتم إدارة الاستثناءات لكل موقع من قائمة القفل. في Chrome وEdge، توجد الفكرة نفسها ضمن الإعدادات، والخصوصية والأمان، والأمان، والمسمى استخدام الاتصالات الآمنة دائمًا. مهما كانت التسمية، تحقق من السلوك تجاه المضيف الذي يجيب فقط على المنفذ 80، لأن الوضع الذي يقوم بالترقية ثم يتراجع بصمت ليس هو الحماية التي تعتقد أنك قمت بتمكينها. توضح وثائق Firefox HTTPS فقط سلوك الترقية والتحذير والاستثناء لهذا المتصفح.

الخطوة 3: أصلح الموارد، وليس شريط العناوين فقط

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

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

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

الخطوة 4: ما يضيفه HSTS وما لا يضيفه

إن HSTS عبارة عن سياسة موقع وليست تفضيلات للمتصفح، وهي الآلية الوحيدة هنا التي تبقى بعد http:// المكتوب في ملف تعريف جديد. بمجرد أن يرى المتصفح رأس Strict-Transport-Security للمضيف، فإنه يعيد كتابة الطلبات اللاحقة إلى https قبل إرسالها، وهي الخاصية التي تريدها بالضبط. ولا يفعل شيئًا لمضيف لم يقم المتصفح بزيارته من قبل، ولا يفعل شيئًا لاسم مضيف مختلف يخدم نفس التطبيق.

تحقق مما يرسله الأصل باستخدام curl -sSI https://example.com | grep -i strict-transport-security. الرأس المفقود هو تغيير في الخادم وليس شيئًا يمكن للعميل تثبيته. إذا كان موجودًا، فاقرأ max-age وما إذا كان قد تم تعيين includeSubDomains، لأن الحد الأقصى القصير للعمر ينتهي بين الزيارات، كما أن نطاقات includeSubDomains المفقودة تترك كل نطاق فرعي غير محمي. يحدد RFC 6797 كيفية تطبيق وكيل المستخدم للسياسة وما قد يتجاهله. يعد التحميل المسبق التزامًا منفصلاً، لذا تحقق من الحالة من خلال واجهة برمجة تطبيقات hstspreload.org قبل وعد أي شخص بوجود النطاق في القائمة.

التحقق والتراجع

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

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

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