Cache bak en VPN: hva HTTPS fortsatt skjuler

En cache ved siden av VPN-serveren høres ut som gratis båndbredde for alle bak tunnelen. Det er det ikke, fordi bytene som passerer punktet, fortsatt er beskyttet av en TLS-økt der endepunktene er nettleseren og nettstedet. VPN-gatewayen fjerner bare sin egen ytre kryptering, ikke applikasjonens. Bestem hvilket gjentatt objekt du vil gjenbruke før du legger til maskinvare.

TLS-økten tilhører nettleseren

I vanlig HTTPS forhandler nettleseren nøkler med nettstedet, og hver post etter håndtrykket er kryptert for det paret av endepunkter. En VPN-gateway dekrypterer tunnelen den opprettet, og videresender deretter ugjennomsiktige TLS-poster. Den ser destinasjoner, timing og volum, ikke forespørselslinjen eller svarteksten. Det er grensen enhver cache må leve med.

Enhver design som bryter den, er en TLS-avlyttingsdesign, med egne konsekvenser for sertifikattillit og enhetsadministrasjon.

CONNECT er en tunnel, ikke en cache

En eksplisitt forward-proxy mottar vanligvis en HTTP CONNECT-forespørsel og videresender deretter bytes i begge retninger. Videresending er nøkkelordet: proxyen parser ikke den krypterte samtalen.

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

Svarhodene kommer fra proxyens håndtering av tunnelen, ikke fra en cachet kopi av siden. En vellykket CONNECT betyr at stien virker, ikke at noe ble lagret for gjenbruk. Å peke port 443 mot en cache lærer den heller ikke å snakke TLS, fordi caching krever lesbare meldinger. Klientkonfigurasjonen må bruke den støttede eksplisitte proxyinnstillingen i stedet for en uforklart omdirigering.

Cache det du drifter, ikke det du surfer på

Der innholdet er ditt, kan en reversproxy avslutte TLS og lagre godkjente svar bevisst. Der det tilhører et pakkearkiv, bruk speilet prosjektet støtter.

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

Den første kommandoen viser om en cachessone er konfigurert og hvor den gjelder, mens den andre viser opphavets egne cachingdirektiver for ett objekt. En delt cache må respektere ferskhet, cachekontroller og de forespørselsattributtene som skiller representasjoner; private og no-store betyr forskjellige ting, og ingen av dem bør fjernes for å øke treffraten. HTTP-cacheregler begrenser også lagring av svar på autentiserte forespørsler, og det er nettopp der en personlig side blir en dataeksponering. Hold proxyen begrenset til godkjente klienter i stedet for å eksponere et åpent relay.

Mål treffet, ikke stoppeklokken

En raskere andre forespørsel beviser ikke at den nye cachen gjorde noe, fordi nettlesere og operativsystemer cacher aggressivt selv. Be proxyen om treff- og bomtellere og overvåk opphavets trafikk under en kontrollert gjentakelse. Bruk én gjentatt nedlasting av et kjent objekt, først med cachen slått på og deretter omgått, og sammenlign bytene opphavet leverte i stedet for medgått tid. Kontroller deretter autorisasjonsgrensen: en ressurs som krever innlogging, skal ikke leveres til en annen klient.

Noter arbeidsmengden, cachenøkkelen og policyen som tillot gjenbruk. En cache er en beslutning om datadeling i optimaliseringskostyme.