Cache bag en VPN: hvad HTTPS stadig skjuler for dig

En cache ved siden af VPN-serveren lyder som gratis båndbredde for alle bag tunnelen. Det er det ikke, fordi de bytes, der passerer punktet, stadig er beskyttet af en TLS-session, hvis ender er browseren og webstedet. VPN-gatewayen fjerner kun sin egen ydre kryptering, ikke applikationens. Beslut, hvilket gentaget objekt du vil genbruge, før du tilføjer hardware.

TLS-sessionen tilhører browseren

I almindelig HTTPS forhandler browseren nøgler med webstedet, og hver post efter håndtrykket er krypteret for det par af ender. En VPN-gateway dekrypterer den tunnel, den har oprettet, og videresender derefter uigennemsigtige TLS-poster. Den kan se destinationer, timing og volumen, ikke anmodningslinjen eller svarlegemet. Det er den grænse, enhver cache må leve med.

Ethvert design, der bryder den, er et TLS-aflytningsdesign med egne konsekvenser for certifikattillid og enhedsstyring.

CONNECT er en tunnel, ikke en cache

En eksplicit forward proxy modtager normalt en HTTP CONNECT-anmodning og videresender derefter bytes i begge retninger. Videresendelse er nøgleordet: proxyen parser ikke den krypterede samtale.

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

Svarheadere kommer fra proxyens håndtering af tunnelen, ikke fra en cachet kopi af siden. Et vellykket CONNECT betyder, at stien virker, ikke at noget er gemt til genbrug. At pege port 443 mod en cache lærer den heller ikke at tale TLS, fordi caching kræver læsbare meddelelser. Klientkonfigurationen skal bruge den understøttede eksplicitte proxyindstilling i stedet for en uforklaret omdirigering.

Cache det, du driver, ikke det, du browser

Hvor indholdet er dit, kan en reverse proxy afslutte TLS og bevidst gemme godkendte svar. Hvor det tilhører et pakkelager, brug det spejl, projektet understøtter.

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

Den første kommando viser, om en cachezone er konfigureret, og hvor den gælder, mens den anden viser originens egne cachingdirektiver for et objekt. En delt cache skal respektere friskhed, cachekontroller og de anmodningsattributter, der skelner repræsentationer; private og no-store betyder forskellige ting, og ingen af dem bør fjernes for at hæve hitraten. HTTP-cachingregler begrænser også lagring af svar på autentificerede anmodninger, og det er netop der, en personlig side bliver en dataeksponering. Hold proxyen begrænset til godkendte klienter i stedet for at eksponere et åbent relay.

Mål hit, ikke stopur

En hurtigere anden anmodning beviser ikke, at den nye cache gjorde noget, fordi browsere og styresystemer cacher aggressivt af sig selv. Bed proxyen om hit- og miss-tællere, og overvåg originens trafik under en kontrolleret gentagelse. Brug én gentaget download af et kendt objekt, først med cachen slået til og derefter omgået, og sammenlign de bytes, originen leverede, i stedet for forløbet tid. Kontroller derefter autorisationsgrænsen: en ressource, der kræver login, må ikke leveres til en anden klient.

Notér arbejdsbyrden, cache-nøglen og den politik, der tillod genbrug. En cache er en beslutning om datadeling i optimeringskostume.