طلب CONNECT وكيف يعمل بروكسي HTTPS
CONNECT طريقة في HTTP تطلب من البروكسي فتح نفق TCP إلى عنوان ومنفذ محددين. بعد أن يقبل البروكسي، يمرّر البايتات في الاتجاهين دون أن يقرأها، فيجري التشفير بين متصفحك والموقع مباشرة. أما «بروكسي HTTPS» فهو في الغالب بروكسي تتصل به عبر TLS، فيصبح الطريق إليه مشفّراً أيضاً.
اسم واحد لأمرين مختلفين
عبارة «بروكسي HTTPS» تُستعمل بمعنيين، والخلط بينهما يسبّب سوء فهم في مسألة التشفير:
- بروكسي HTTP يمرّر مواقع https. الاتصال بالبروكسي نفسه غير مشفّر، ومحتوى الموقع مشفّر داخل نفق CONNECT.
- بروكسي تتصل به عبر TLS. الاتصال بالبروكسي مشفّر من أوله، بما فيه طلب CONNECT وكلمة المرور.
في هذا الشرح نستعمل «بروكسي HTTPS» للمعنى الثاني فقط، كما تفعل curl وChromium.
خطوات طلب CONNECT
تعرّف RFC 9110، القسم 9.3.6 هذه الطريقة. وهذا ما يحدث حين تفتح موقع https عبر بروكسي HTTP:
- يفتح المتصفح اتصال TCP بالبروكسي.
- يرسل طلب CONNECT وفيه اسم الموقع والمنفذ فقط، دون مسار ولا محتوى. والمنفذ إلزامي، إذ لا منفذ افتراضياً لهذه الطريقة.
- إن كان البروكسي يطلب مصادقة ولم تصله، يرد بالرمز 407، فيعيد المتصفح الطلب مع ترويسة Proxy-Authorization.
- يتحقق البروكسي من بيانات الدخول ومن أن المنفذ مسموح، ثم يفتح اتصال TCP بالموقع.
- يرد بنجاح من فئة 2xx. بعد نهاية ترويسات هذا الرد مباشرة يتحوّل الاتصال إلى نفق.
- يرسل المتصفح رسالة ClientHello الخاصة بـ TLS عبر النفق، ويتفاوض مع الموقع على المفاتيح. البروكسي ينقل هذه الرسائل ولا يملك المفاتيح.
- يبقى النفق قائماً حتى يغلق أحد الطرفين اتصاله، فيغلق البروكسي الطرف الآخر.
وهكذا يبدو التبادل على السلك، في مثال مبني على مثال المعيار، وبيانات الدخول فيه hello:world:
CONNECT server.example.com:443 HTTP/1.1
Host: server.example.com:443
Proxy-Authorization: Basic aGVsbG86d29ybGQ=
HTTP/1.1 200 Connection establishedبعد السطر الفارغ الذي يلي الرد لا يرسل البروكسي شيئاً من عنده. ولا يجوز أن يحمل رد النجاح ترويسة Content-Length ولا Transfer-Encoding، لأن ما يليه بيانات النفق لا محتوى الرد.
لماذا تقيّد البروكسيات المنافذ
النفق ينقل أي بروتوكول، لا الويب وحده. لذلك ينبّه المعيار إلى أن فتح أنفاق إلى منافذ عشوائية خطر، ويضرب مثلاً بالمنفذ 25 الذي قد يحوّل البروكسي إلى مرحّل للبريد المزعج. وتوصي المواصفة بأن يقصر البروكسي CONNECT على مجموعة محدودة من المنافذ المعروفة.
إن رفض البروكسي طلبك إلى منفذ غير 443، فهذا غالباً سياسة مقصودة لا عطل.
بروكسي HTTPS: تشفير الطريق إلى البروكسي
في البروكسي العادي يمر طلب CONNECT وترويسة Proxy-Authorization نصاً واضحاً. وترميز Base64 في المثال أعلاه ليس تشفيراً، فأي أحد على الطريق يستطيع فكّه.
في بروكسي HTTPS يبدأ المتصفح بتفاوض TLS مع البروكسي نفسه، ويتحقق من شهادته كما يتحقق من شهادة أي موقع. ثم يرسل طلب CONNECT داخل هذا الاتصال المشفّر. وبعد قيام النفق يجري تفاوض TLS ثانٍ مع الموقع داخل الأول، فتصبح البيانات مشفّرة بطبقتين على الجزء الممتد بينك وبين البروكسي.
تدعم curl ذلك بالمخطط https:// في عنوان البروكسي. ويدعمه كروم عبر ملف PAC أو سياسة أو إضافة، لا عبر إعدادات البروكسي العامة في النظام عادةً، كما تذكر وثائق Chromium.
من يرى ماذا
الجدول لموقع يعمل بـ https في الحالتين:
| الطرف | بروكسي HTTP مع CONNECT | بروكسي HTTPS مع CONNECT |
|---|---|---|
| مزوّد الإنترنت أو شبكة المقهى | عنوان البروكسي، واسم الموقع ومنفذه في سطر CONNECT، وبيانات الدخول، واسم الموقع في SNI | عنوان البروكسي، وحجم البيانات وتوقيتها |
| البروكسي | عنوانك، واسم الموقع ومنفذه، وحجم البيانات وتوقيتها، لا المحتوى | |
| الموقع | عنوان البروكسي، وما يرسله متصفحك داخل الاتصال المشفّر | |
وSNI امتداد في رسالة ClientHello يحمل اسم الموقع. يحدده RFC 6066، القسم 3، ليعرف الخادم أي موقع تطلب حين تشترك مواقع عدة في عنوان واحد. ومع بروكسي HTTP عادي يمر هذا الامتداد ضمن الحركة التي يراها من على الطريق.
حين يقرأ البروكسي المحتوى
بعض بروكسيات الشركات والمدارس لا تكتفي بالنفق. تُنهي اتصال TLS عندها، وتقدّم للمتصفح شهادة صادرة عن جهة تصديق خاصة بها، ثم تفتح اتصالاً جديداً بالموقع. بهذا تقرأ كل شيء.
هذا لا ينجح إلا إذا ثُبّتت شهادة الجذر الخاصة بتلك الجهة على جهازك، وإلا يعرض المتصفح تحذيراً. للتحقق، افتح تفاصيل شهادة أي موقع في المتصفح، وانظر إلى الجهة المصدِرة. إن كانت اسم شركتك أو برنامج حماية بدل جهة تصديق عامة، فهناك اعتراض.
ماذا عن UDP وHTTP/3
نفق CONNECT التقليدي ينقل TCP فقط. وHTTP/3 يعمل فوق QUIC، أي فوق UDP، فلا يمر في هذا النفق، ويصل المتصفح إلى الموقع عبر TCP.
لنقل UDP عبر بروكسي HTTP عرّفت RFC 9298 آلية connect-udp. وهي تختلف عن CONNECT التقليدي، ولا يدعمها كل بروكسي ولا كل برنامج.
كيف تختبر بنفسك
الخيار -v في curl يعرض خطوات النفق. مع بروكسي HTTP:
curl -v -x http://USER:PASS@proxy.example.com:8080 https://example.com/ستجد سطراً يبدأ بـ > CONNECT example.com:443، ثم رد البروكسي، ثم تفاوض TLS مع الموقع. ومع بروكسي HTTPS:
curl -v -x https://USER:PASS@proxy.example.com:443 https://example.com/هنا يظهر تفاوض TLS مع البروكسي وشهادته قبل سطر CONNECT. إن ظهر خطأ في شهادة البروكسي، فلا تتجاوزه بخيار --proxy-insecure قبل أن تعرف سببه. وللتأكد من عنوان الخروج بعد الاتصال، افتح أداة عنوانك.
نصائح عامة
- على شبكة لا تثق بها، استعمل بروكسي HTTPS، أو اتصالاً مشفّراً بالكامل مثل VPN.
- لا تثبّت شهادة جذر لا تعرف مصدرها، فهي تسمح لمن يملكها بقراءة حركتك المشفّرة.
- افتح المواقع بـ https دائماً، فهذا ما يحمي المحتوى من البروكسي نفسه.
- إن كنت تدير بروكسي، فاقصر CONNECT على المنافذ التي تحتاجها، واطلب المصادقة.
إن كنت تستعمل بروكسي مع محفظة إلكترونية أو حساب مصرفي، فاقرأ أيضاً حماية محفظتك عند استخدام بروكسي.
في syriaproxy
بروكسي HTTPS عندنا مشفّر بين جهازك وخادمنا، ومعه SOCKS5 وHTTP غير مشفّرين لمن يحتاجهما. الخروج من شبكة سيريتل داخل سوريا، ولا نسجّل المواقع التي تزورها ولا محتواها. الإعداد في إعداد البروكسي.
أسئلة شائعة
هل يرى البروكسي كلمات المرور التي أكتبها في المواقع؟
لا، ما دام الموقع يعمل بـ https ولم تُثبَّت على جهازك شهادة جذر للبروكسي. يرى اسم الموقع وحجم البيانات فقط.
لماذا يرد البروكسي بـ 407 قبل أن يعمل؟
لأنه يطلب بيانات الدخول. المتصفح يرسل الطلب الأول دونها عادةً، ثم يعيده معها بعد الرد. الشرح في مصادقة البروكسي.
هل بروكسي HTTPS مثل VPN؟
يشبهها في تشفير الطريق إلى الخادم، لكنه يعمل لكل برنامج على حدة، ولا ينقل إلا ما يمر عبر CONNECT أو طلبات HTTP. الشبكة الافتراضية تنقل حركة الجهاز كله.
لماذا يفشل الاتصال بمنفذ غير معتاد عبر البروكسي؟
لأن البروكسي قد يقصر CONNECT على منافذ معروفة، كما توصي المواصفة. اسأل مزوّد البروكسي عن المنافذ المسموحة.
افحص البروكسي الخاص بك بأداة فحص البروكسي المجانية: هل يعمل، وزمن استجابته، وعنوان خروجه.