Cache bak ein VPN: kva HTTPS framleis skjuler
Ein proxy ved VPN-utgangen kan framleis ikkje lese ende-til-ende HTTPS. Vel ei cachebar arbeidsmengd og ei medviten TLS-grense før du legg til ein server til.
Ein cache ved sida av VPN-tenaren høyrest ut som gratis bandbreidde for alle bak tunnelen. Det er det ikkje, fordi byta som passerer punktet, framleis er verna av ein TLS-økt der endepunkta er nettlesaren og nettstaden. VPN-gatewayen fjernar berre si eiga ytre kryptering, ikkje den til applikasjonen. Avgjer kva gjenteke objekt du vil bruke på nytt før du legg til maskinvare.
TLS-økta høyrer til nettlesaren
I vanleg HTTPS forhandlar nettlesaren nøklar med nettstaden, og kvar post etter handtrykket er kryptert for det paret av endepunkt. Ein VPN-gateway dekrypterer tunnelen han oppretta, og sender deretter ugjennomsiktige TLS-postar vidare. Han ser destinasjonar, timing og volum, ikkje førespurnadslinja eller svarteksten. Det er grensa kvar cache må leve med.
Kvart design som bryt henne, er eit TLS-avlyttingsdesign, med eigne følgjer for sertifikattillit og einingadministrasjon.
CONNECT er ein tunnel, ikkje ein cache
Ein eksplisitt forward-proxy får vanlegvis ein HTTP CONNECT-førespurnad og sender deretter byte i begge retningar. Videresending er nøkkelordet: proxyen parsar ikkje den krypterte samtalen.
curl -sSI -x http://proxy.example:3128 https://example.com/Svarhovuda kjem frå proxyen si handtering av tunnelen, ikkje frå ein cachet kopi av sida. Ein vellukka CONNECT betyr at stien verkar, ikkje at noko vart lagra for gjenbruk. Å peike port 443 mot ein cache lærer han heller ikkje å snakke TLS, fordi caching krev lesbare meldingar. Klientkonfigurasjonen må bruke den støtta eksplisitte proxyinnstillinga i staden for ei uforklart omdirigering.
Cache det du driv, ikkje det du surfar på
Der innhaldet er ditt, kan ein reversproxy avslutte TLS og lagre godkjende svar medvite. Der det høyrer til eit pakkearkiv, bruk spegelen prosjektet støttar.
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 ei cachesone er konfigurert og kvar ho gjeld, medan den andre viser opphavet sine eigne cachingdirektiv for eitt objekt. Ein delt cache må respektere ferskleik, cachekontrollar og dei førespurnadsattributta som skil representasjonar; private og no-store tyder ulike ting, og ingen av dei bør fjernast for å auke treffraten. HTTP-cachereglar avgrensar òg lagring av svar på autentiserte førespurnader, og det er nettopp der ei personleg side blir ei dataeksponering. Hald proxyen avgrensa til godkjende klientar i staden for å eksponere eit ope relay.
Mål treffet, ikkje stoppeklokka
Ein raskare andre førespurnad provar ikkje at den nye cachen gjorde noko, fordi nettlesarar og operativsystem cachar aggressivt sjølve. Be proxyen om treff- og bomteljarar og overvak trafikken til opphavet under ei kontrollert gjentaking. Bruk éin gjenteken nedlasting av eit kjent objekt, først med cachen slått på og deretter omgått, og samanlikn byta opphavet leverte i staden for medgått tid. Kontroller deretter autorisasjonsgrensa: ein ressurs som krev innlogging, skal ikkje leverast til ein annan klient.
Noter arbeidsmengda, cachenøkkelen og policyen som tillét gjenbruk. Ein cache er ei avgjerd om datadeling i optimaliseringskostyme.