وكيل HTTPS يعني اتصالين TLS، لا اتصالاً واحداً
قفزة الوكيل والموقع علاقتان منفصلتان من التي لايه ولكل منهما ثقة منفصلة. اقرأ أي نقطة طرفية فشلت قبل تغيير أي إعداد شهادة.
لا يصف تصنيف وكيل HTTPS سوى النقل بين عميلك والوكيل، ولا شيء أكثر. فهو لا يقول إن الموقع الواقع خلفه مشفّر بهذا الاتصال نفسه، ولا يقول إن الوكيل يستطيع قراءة الصفحة. وبمجرد أن تفصل الاتصالين، تتوقف أخطاء الشهادات عن أن تكون غامضة ويصبح مقارنتها بـ VPN ملموسة.
زوجان من نقاط الطرف، وتحققان
في وضع النفق العادي توجد علاقتان منفصلتان بـ TLS. الأولى تمتد من عميلك إلى الوكيل وتوثّق الوكيل. والثانية تمتد من عميلك إلى الموقع داخل النفق، وتوثّق الموقع. وهما تفشلان بشكل مستقل وتُضبطان بشكل مستقل.
لكل منهما قرارات ثقة منفصلة وسلاسل شهادات منفصلة ورسائل فشل منفصلة. وكيل يستخدم سلطة شهادات مؤسسية وموقع عام يستخدم سلسلة عامة قد يحتاجان بحق إلى إعداد تحقق مختلف، وهذا ليس سوء ضبط.
تعامل معهما كاتصالين يتصادف أنهما يتشاركان مقبساً واحداً، لأنهما كذلك بالفعل.
ما الذي ينفّذه CONNECT فعلياً كنفق
يرسل العميل طلب CONNECT يحدد فيه المضيف والمنفذ، ويفتح الوكيل اتصال TCP بذلك الهدف. وبعد أن يجيب الوكيل، تُمرّر البايتات التالية دون تفسير، ولهذا يعبر مصافحة TLS الخاصة بالموقع عبر الوكيل دون مساس. ولذلك يتعرّف الوكيل على اسم الوجهة وبيانات الاتصال الوصفية، ولا يتلقى صفحات مفكوكة التشفير من هذا الترتيب.
هذا التمييز هو حجة الأمان كلها لوضع النفق، وهو أيضاً حدوده.
الوكيل HTTP الذي لا يستخدم TLS على قفزة الوكيل يظل يحمل موقع HTTPS عبر CONNECT. فتبادل العميل مع الوكيل يجري في العراء بينما اتصال الموقع ليس كذلك، وتسمية الأمر كله وكيل HTTPS تخفي هذا الفرق.
أي شهادة هي التي فشلت
عندما يفشل التحقق، اقرأ نقطة الطرف المذكورة في الخطأ قبل تغيير أي إعداد ثقة. والفشلان يبدوان متشابهين في الطرفية ويشيران إلى إصلاحين مختلفين تماماً، ولهذا يكون السؤال الأول دائماً: أي اتصال رفض؟
curl يفصل الخيارات لهذا السبب تحديداً. فملف CA الخاص بالوكيل يضبط التحقق من الوكيل، بينما ملف CA يضبط التحقق من الخادم، كما أن سلوك مخزن الثقة المطبق يعتمد أيضاً على طريقة بناء curl.
curl -v --proxy https://proxy.example.net:443 \
--proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/كتم الفحص ليس إصلاحاً. فهو لا يثبت شيئاً عن أي من الطرفين.
الفحص ترتيب مختلف
فحص TLS ليس تنفيقاً. فالوسيط الفاحص ينهي علاقة الثقة المتجهة إلى الموقع ويعرض شهادته الخاصة على العميل، فيتحقق العميل من الوسيط بدلاً من الموقع. وقد يكون ذلك مشروعاً في تصميم معتمد، لكنه ادعاء مختلف جوهرياً عن التمرير بايتاً ببايت. لا تفترض أن كل وكيل يفحص، ولا تفترض أن قفزة وكيل مشفّرة تستبعده.
وجود سلطة شهادات مؤسسية في مخزن ثقتك تلميح إلى الترتيب الذي أنت فيه، وليس دليلاً. اطلب التصميم بدلاً من استنتاجه من سلسلة شهادات.
هذان الترتيبان ينتجان جوابين مختلفين عن سؤال من يستطيع قراءة الصفحة.
قارن الوكيل و VPN على الأسطر الأربعة نفسها
لا تصبح المقارنة مفيدة إلا عندما يوصف النشران بالطريقة نفسها.
| Line | What to state |
|---|---|
| Protected segments | Which hops are encrypted, and between which endpoints |
| Verified identities | What each end proves, and against which trust anchor |
| Trusted intermediaries | Who can read or alter traffic by design |
| Traffic included | Which processes and destinations the policy actually covers |
الوكيل المضبوط لطلب واحد يغطي ذلك الطلب. وهو لا يمرر كل عملية على الجهاز عبره، والأمر في المثال بهذا الضيق تحديداً. وتغطية VPN تعتمد على توجيهه وسياسة تطبيقاته، وهي أيضاً تحتاج إلى فحص لا إلى افتراض. ولا يغطي أي من الخيارين كل شيء لمجرد أنه ثُبّت.
اكتب الأسطر الأربعة لكل خيار وعادةً تحل الحجة نفسها. المقارنة المفيدة ليست أي تسمية تبدو أكثر تشفيراً. بل هي أي المقاطع محمية، ومن يُتحقق منه عند طرفيها، وأي الوسطاء تثق بهم، وأي حركة مرور تشملها السياسة فعلاً.