Cache za VPN: co před vámi HTTPS stále skrývá

Cache vedle serveru VPN zní jako bezplatná šířka pásma pro všechny za tunelem. Není, protože bajty procházející tímto bodem zůstávají chráněné relací TLS, jejímiž koncovými body jsou prohlížeč a web. Brána VPN odstraňuje pouze své vlastní vnější šifrování, ne šifrování aplikace. Než přidáte hardware, rozhodněte, který opakovaný objekt chcete znovu použít.

Relace TLS patří prohlížeči

V běžném HTTPS prohlížeč vyjednává klíče s webem a každý záznam po handshake je šifrován pro tuto dvojici koncových bodů. Brána VPN dešifruje tunel, který vytvořila, a poté předává neprůhledné záznamy TLS. Vidí cíle, časování a objem, ale ne řádek požadavku ani tělo odpovědi. To je hranice, se kterou musí každá cache žít.

Každý návrh, který ji narušuje, je návrhem zachytávání TLS s vlastními důsledky pro důvěru v certifikáty a správu zařízení.

CONNECT je tunel, ne cache

Explicitní dopředný proxy obvykle obdrží požadavek HTTP CONNECT a poté přenáší bajty oběma směry. Přenos je klíčové slovo: proxy šifrovanou konverzaci neanalyzuje.

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

Záhlaví odpovědi pocházejí ze zpracování tunelu proxy, nikoli z kešované kopie stránky. Úspěšný CONNECT znamená, že cesta funguje, ne že bylo něco uloženo pro opakované použití. Nasměrovat port 443 na cache ho také nenaučí mluvit TLS, protože kešování vyžaduje čitelná hlášení. Konfigurace klienta musí použít podporované nastavení explicitního proxy, ne nevysvětlené přesměrování.

Kešujte to, co provozujete, ne to, co prohlížíte

Kde je obsah váš, reverzní proxy může ukončit TLS a záměrně ukládat schválené odpovědi. Kde patří úložišti balíčků, použijte zrcadlo, které projekt podporuje.

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

První příkaz ukazuje, zda je zóna cache nakonfigurována a kde platí, druhý ukazuje vlastní kešovací direktivy původu pro jeden objekt. Sdílená cache musí respektovat čerstvost, kešovací řízení a atributy požadavku, které rozlišují reprezentace; private a no-store znamenají různé věci a ani jedno se nesmí odstranit kvůli zvýšení míry zásahů. Pravidla kešování HTTP také omezují ukládání odpovědí na ověřené požadavky, a právě tam se personalizovaná stránka stává únikem dat. Držte proxy omezený na schválené klienty, místo abyste vystavovali otevřený relay.

Měřte zásah, ne stopky

Rychlejší druhý požadavek nedokazuje, že nová cache něco udělala, protože prohlížeče a operační systémy kešují agresivně samy. Požádejte proxy o počítadla zásahů a minutí a sledujte provoz původu při řízeném opakování. Použijte jedno opakované stažení známého objektu, nejprve s cache a poté s jejím obejitím, a porovnejte bajty vydané původem, ne uplynulý čas. Pak zkontrolujte hranici autorizace: zdroj vyžadující přihlášení nesmí být obsloužen jinému klientovi.

Zaznamenejte zátěž, klíč cache a zásadu, která opakované použití povolila. Cache je rozhodnutí o sdílení dat v kostýmu optimalizace.