پروکسی HTTPS یعنی دو اتصال TLS، نه یکی
پرش پروکسی و وب‌سایت دو رابطه TLS جدا با اعتماد جدا هستند. بخوانید کدام نقطه پایانی شکست خورده است پیش از تغییر هر تنظیم گواهی.
برچسب پروکسی HTTPS تنها انتقال میان کلاینت شما و پروکسی را توصیف می‌کند و نه چیزی بیشتر. نمی‌گوید وب‌سایتی که پشت آن است با همان اتصال رمزگذاری شده است، و نمی‌گوید پروکسی می‌تواند صفحه را بخواند. وقتی دو اتصال را از هم جدا کنید، خطاهای گواهی از حالت مبهم خارج می‌شوند و مقایسه با VPN ملموس می‌شود.
دو جفت نقطه پایانی، دو بررسی
در حالت تونل معمولی دو رابطه TLS وجود دارد. اولی از کلاینت شما به پروکسی می‌رود و پروکسی را احراز هویت می‌کند. دومی از کلاینت شما به وب‌سایت درون تونل می‌رود و وب‌سایت را احراز هویت می‌کند. آن‌ها مستقل از هم شکست می‌خورند و مستقل از هم پیکربندی می‌شوند.
آن‌ها تصمیم‌های اعتماد جدا، زنجیره‌های گواهی جدا و پیام‌های خطای جدا دارند. پروکسی با CA سازمانی و وب‌سایت عمومی با زنجیره عمومی می‌توانند به‌طور مشروع به پیکربندی بررسی متفاوتی نیاز داشته باشند و این پیکربندی نادرست نیست.
با آن‌ها مانند دو اتصالی رفتار کنید که تصادفاً یک سوکت را شریک‌اند، چون واقعاً همین‌اند.
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 تونل‌سازی نیست. یک واسط بازرسی‌کننده رابطه اعتماد رو به وب‌سایت را پایان می‌دهد و گواهی خودش را به کلاینت ارائه می‌کند، پس کلاینت واسط را بررسی می‌کند نه سایت را. این می‌تواند زیر یک طراحی تأییدشده مشروع باشد، و ادعایی اساساً متفاوت از انتقال بایت‌به‌بایت است. فرض نکنید هر پروکسی بازرسی می‌کند، و فرض نکنید پرش پروکسی رمزگذاری‌شده آن را رد می‌کند.
CA سازمانی در انبار اعتماد شما نشانه‌ای از این است که در کدام ترتیب هستید، نه اثبات. طراحی را بپرسید به‌جای استنتاج آن از زنجیره گواهی.
این دو ترتیب پاسخ‌های متفاوتی به این پرسش می‌دهند که چه کسی می‌تواند صفحه را بخواند.
پروکسی و 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 به مسیریابی و سیاست برنامه‌های آن بستگی دارد که آن هم باید بررسی شود نه فرض. هیچ‌یک از دو گزینه تنها به این دلیل که نصب شده همه چیز را پوشش نمی‌دهد.
چهار خط را برای هر گزینه بنویسید و بحث معمولاً خودش حل می‌شود. مقایسه سودمند این نیست که کدام برچسب رمزگذاری‌شده‌تر به نظر می‌رسد. بلکه این است که کدام بخش‌ها محافظت می‌شوند، چه کسی در دو سر آن‌ها بررسی می‌شود، به کدام واسط‌ها اعتماد دارید و سیاست در واقع چه ترافیکی را شامل می‌شود.