کش پشت VPN: HTTPS هنوز چه چیزی را از شما پنهان می‌کند

کش کنار سرور VPN مثل پهنای باند رایگان برای همه پشت تونل به نظر می‌رسد. اما نیست، چون بایت‌هایی که از آن نقطه می‌گذرند با نشست TLS محافظت می‌شوند که دو سر آن مرورگر و وب‌سایت است. دروازه VPN فقط رمزنگاری بیرونی خودش را برمی‌دارد، نه رمزنگاری برنامه را. پیش از افزودن سخت‌افزار تصمیم بگیرید کدام شیء تکراری را می‌خواهید دوباره استفاده کنید.

نشست TLS متعلق به مرورگر است

در HTTPS معمولی مرورگر کلیدها را با سایت توافق می‌کند و هر رکورد پس از دست‌دادن برای همان دو سر رمز می‌شود. دروازه VPN تونلی را که ساخته رمزگشایی می‌کند و سپس رکوردهای مات TLS را جلو می‌فرستد. می‌تواند مقصدها، زمان و حجم را ببیند، نه خط درخواست یا بدنه پاسخ را. این همان مرزی است که هر کش باید با آن زندگی کند.

هر طراحی که آن را بشکند، طراحی رهگیری TLS است با پیامدهای خودش برای اعتماد به گواهی‌ها و مدیریت دستگاه‌ها.

CONNECT یک تونل است، نه کش

پروکسی پیشرو صریح معمولاً درخواست HTTP CONNECT می‌گیرد و سپس بایت‌ها را در هر دو جهت بازپخش می‌کند. بازپخش واژه کلیدی است: پروکسی گفت‌وگوی رمزشده را تجزیه نمی‌کند.

curl -sSI -x http://proxy.example:3128 https://example.com/

سرآیندهای پاسخ از نحوه برخورد پروکسی با تونل می‌آیند، نه از نسخه کش‌شده صفحه. CONNECT موفق یعنی مسیر کار می‌کند، نه اینکه چیزی برای استفاده دوباره ذخیره شده است. هدایت پورت 443 به یک کش هم به آن یاد نمی‌دهد TLS صحبت کند، چون کش‌کردن پیام‌های خوانا می‌خواهد. پیکربندی کلاینت باید از تنظیم پروکسی صریح پشتیبانی‌شده استفاده کند، نه تغییرمسیر بی‌توضیح.

آنچه را اداره می‌کنید کش کنید، نه آنچه را مرور می‌کنید

جایی که محتوا مال شماست، پروکسی معکوس می‌تواند TLS را پایان دهد و پاسخ‌های تأییدشده را آگاهانه ذخیره کند. جایی که به مخزن بسته تعلق دارد، از آینه‌ای که پروژه پشتیبانی می‌کند استفاده کنید.

nginx -T | grep -n "proxy_cache"
curl -sSI https://mirror.example/pkg/index.json | grep -i -E "cache-control|age"

دستور اول نشان می‌دهد آیا ناحیه کش پیکربندی شده و کجا اعمال می‌شود، و دومی دستورهای کش خود مبدأ را برای یک شیء نشان می‌دهد. کش مشترک باید تازگی، کنترل‌های کش و ویژگی‌های درخواست را که بازنمایی‌ها را متمایز می‌کند رعایت کند؛ private و no-store معانی متفاوتی دارند و هیچ‌کدام نباید برای بالا بردن نرخ برخورد حذف شود. قواعد کش HTTP ذخیره پاسخ برای درخواست‌های احرازشده را هم محدود می‌کند و دقیقاً همان‌جاست که صفحه شخصی‌سازی‌شده به افشای داده تبدیل می‌شود. پروکسی را به کلاینت‌های تأییدشده محدود نگه دارید، نه به‌صورت رله باز.

برخورد را بسنجید، نه کرونومتر را

درخواست دوم سریع‌تر ثابت نمی‌کند کش جدید کاری کرده، چون مرورگرها و سیستم‌عامل‌ها خودشان به‌شدت کش می‌کنند. شمارنده‌های برخورد و عدم‌برخورد را از پروکسی بخواهید و در یک تکرار کنترل‌شده ترافیک مبدأ را ببینید. یک بارگیری تکراری از شیء شناخته‌شده انجام دهید، یک بار با کش فعال و بعد با دور زدن آن، و بایت‌های تحویل‌شده مبدأ را مقایسه کنید نه زمان گذشته را. سپس مرز مجوز را بررسی کنید: منبعی که ورود می‌خواهد نباید به کلاینت دیگری داده شود.

بار، کلید کش و سیاستی را که استفاده دوباره را مجاز کرد ثبت کنید. کش تصمیمی درباره اشتراک داده با لباس بهینه‌سازی است.