وكلاء HTTP وHTTPS

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

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

ماذا يفعل وكيل HTTP بطلب الويب

لنفترض أن برنامج مراقبة يطلب http://example.com/catalog. فبدل فتح اتصال بالموقع، يتصل بالوكيل المضبوط في الإعدادات. ومع HTTP/1.1، يرسل URL الوجهة كاملًا في طلبه ليعرف الوكيل الخادم والصفحة اللذين يجب الاتصال بهما. ويرسل الوكيل الطلب إلى الوجهة ويعيد استجابة الموقع إلى البرنامج.

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

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

كيف يفتح وكيل HTTP موقع HTTPS

يستخدم موقع HTTPS بروتوكول TLS لحماية التبادل بين التطبيق والموقع. ولحمل ذلك التبادل، ينشئ وكيل HTTP نفقًا أولًا. وعند طلب https://example.com/catalog، يكون التسلسل كما يلي:

1. يتصل التطبيق بالوكيل ويطلب منه فتح نفق إلى example.com:443 باستخدام طريقة CONNECT. ويحدد الطلب مضيف الوجهة ومنفذها من دون مسار الصفحة.
2. يتحقق الوكيل من السماح بالوصول والوجهة المطلوبة، بما في ذلك أي مصادقة لازمة لدى الوكيل. ويفتح اتصالًا بالوجهة ويؤكد جاهزية النفق.
3. يجري التطبيق مصافحة TLS مع الموقع عبر النفق ويتحقق من شهادة الموقع.
4. يرسل التطبيق طلب الويب داخل اتصال TLS هذا. ويمرّر الوكيل البايتات المشفّرة في الاتجاهين.

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

لذلك يستطيع وكيل HTTP فتح موقع HTTPS حتى حين يبدأ عنوان الوكيل بـ http://. فحماية HTTPS الخاصة بالموقع تعمل داخل النفق، ولا تعتمد على وجود TLS بين التطبيق والوكيل.

ما الذي يضيفه وكيل HTTPS

مع وكيل HTTPS، ينشئ التطبيق TLS مع الوكيل أولًا ويتحقق من شهادته. ثم يرسل طلبات HTTP أو طلب CONNECT لفتح نفق داخل ذلك الاتصال المحمي. ولا يستطيع مراقب للشبكة بين التطبيق والوكيل قراءة هذه الطلبات.

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

تصف المقارنة تمريرًا عاديًا عبر وكيل مع تفعيل فحوص الشهادات، من دون فحص HTTPS أو VPN منفصل. ولا يحوّل تشفير الاتصال بالوكيل موقع HTTP إلى HTTPS.

ما الذي يستطيع الوكيل والموقع رؤيته

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

تُرسل بيانات اعتماد الوكيل منفصلة عن تسجيل الدخول إلى الموقع. وتمثل مصادقة Basic لدى الوكيل اسم المستخدم وكلمة المرور باستخدام Base64، الذي يمكن فك ترميزه من دون مفتاح سري. ولا يحميهما ذلك من مراقب للشبكة عند الاتصال بالوكيل عبر HTTP غير مشفّر. ويبدأ اتصال HTTPS الخاص بالموقع داخل النفق، ولا يشمل تسجيل الدخول السابق لدى الوكيل. ويحمي TLS إلى الوكيل بيانات ذلك الدخول أثناء النقل.

في الطرف الآخر، يتلقى الموقع البيانات من IP الخروج ويقرأ الطلبات الموجهة إليه. ويمكنه التعرّف إلى حساب أو ملف تعريف ارتباط لجلسة أو معلومات أخرى يرسلها التطبيق. ولا يزيل اختيار وكيل HTTPS تلك المعرّفات ولا يحسّن قبول الموقع لعنوان IP للخروج تلقائيًا.

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

كيف تقرأ إعدادات الاتصال

يحتاج إعداد الوكيل إلى عنوان ومنفذ وبروتوكول اتصال وأي مصادقة مطلوبة. وينطبق البروتوكول في URL الوكيل على الوكيل. أما البروتوكول في URL الوجهة فينطبق على الموقع.

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

curl --proxy http://proxy.example:8080 https://example.com/
curl --proxy https://proxy.example:8443 https://example.com/

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

لن يحوّل مجرد تغيير http:// إلى https:// منفذًا يدعم HTTP فقط إلى نقطة اتصال TLS. وإذا قدمت الخدمة اسم مضيف لوصول HTTPS، فاستخدمه: فقد يؤدي استبداله بعنوان IP إلى عدم تطابق اسم الشهادة.

تحتاج التسميات في التطبيقات إلى القراءة المتأنية نفسها. فقد يختار حقل يُسمى «HTTPS proxy» الوكيل لمواقع HTTPS مع الاستمرار في الاتصال به عبر HTTP غير مشفّر. وفي curl، يختار المتغير HTTPS_PROXY أيضًا وكيلًا لوجهات HTTPS؛ وقد تبدأ قيمته بـ http:// على نحو صحيح. تخبرك التسمية بالطلبات التي تستخدم الإعداد، بينما يوضح مخطط عنوان الوكيل كيفية إنشاء الاتصال.

DNS وحركة البيانات التي تمر عبر الوكيل

عندما يقدم عميل HTTP اسم مضيف الوجهة، يبحث الوكيل عادة عن IP الخاص به ويتصل به. ويجري العميل بحثًا منفصلًا إذا احتاج إلى اسم مضيف الوكيل نفسه للوصول إليه. وقد يصدر المتصفح أيضًا استعلامات DNS للتنبؤ أو ميزات أخرى. وهذه عمليات بحث منفصلة؛ ولا يوجّه ضبط وكيل ويب كل طلب DNS عبره.

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

HTTP/2 إلى الموقع وHTTP/2 إلى الوكيل

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

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

يجب أن يدعم الطرفان الوضع المختار. ولا يحدد HTTPS وحده استخدام HTTP/2: فقد يستخدم وكيل HTTPS بروتوكول HTTP/1.1. كما يعتمد الأداء على العميل ومسار الشبكة وحمل الخادم وإعادة استخدام الاتصالات. ولا تضمن تسمية HTTP/2 زيادة السرعة لكل مهمة.

يمكن لنفق CONNECT عادي نقل بروتوكولات أخرى قائمة على TCP إذا أتاحها التطبيق والوكيل، رغم احتمال تقييد منافذ الوجهة. لكنه لا يمرّر UDP. ويستخدم HTTP/3 بروتوكول QUIC عبر UDP، فلا ينتقل في نفق TCP هذا بالطريقة نفسها. وتستخدم آليات تمرير UDP القائمة على HTTP وسائل إضافية مثل CONNECT-UDP، وتتطلب تطبيقات متوافقة لها. ولا يثبت دعم HTTPS أو HTTP/2 وحده توفر ذلك الدعم.

أين يفيد الوصول عبر وكيل HTTP أو HTTPS

للتصفح واختبارات المواقع، يوفر وكيل HTTP مع CONNECT طريقة اتصال واحدة لوجهات HTTP وHTTPS معًا. ويمكن لفريق استخدامه لمشاهدة موقع من شبكة الوكيل، مع إبقاء عرض الصفحات وملفات تعريف الارتباط وتسجيل دخول المواقع مسؤولية المتصفح.

للزواحف وعملاء API وبرامج المراقبة المجدولة، يستطيع عميل HTTP إرسال الطلبات عبر IP خروج مختار مع إبقاء عناوين URL للوجهة كما هي. ويظل التطبيق يعد الطلبات ويعالج الاستجابات. وداخل نفق HTTPS، ينقل الوكيل ذلك التبادل من دون حاجة إلى تحليل كل صفحة أو استدعاء API.

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

فهم أخطاء الاتصال

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

يثبت اكتمال النفق ومصافحة TLS أن مسار الاتصال يعمل. ولا يضمنان قبول الموقع حسابًا أو IP خروج أو طلبًا بعينه. لذلك قد تستدعي مطالبة بتسجيل الدخول أو CAPTCHA أو حد طلبات اهتمامًا على مستوى الموقع أو التطبيق حتى عندما يعمل الوكيل.