Cache bakom en VPN: vad HTTPS fortfarande döljer

En cache bredvid VPN-servern låter som gratis bandbredd för alla bakom tunneln. Det är det inte, eftersom byten som passerar punkten fortfarande skyddas av en TLS-session vars ändpunkter är webbläsaren och webbplatsen. VPN-gatewayen tar bort bara sin egen yttre kryptering, inte applikationens. Bestäm vilket upprepat objekt du vill återanvända innan du lägger till hårdvara.

TLS-sessionen tillhör webbläsaren

I vanlig HTTPS förhandlar webbläsaren nycklar med webbplatsen, och varje post efter handskakningen krypteras för det paret ändpunkter. En VPN-gateway dekrypterar tunneln den skapade och vidarebefordrar sedan ogenomskinliga TLS-poster. Den ser destinationer, timing och volym, inte begäranderaden eller svarskroppen. Det är gränsen varje cache måste leva med.

Varje design som bryter den är en TLS-avlyssningsdesign, med egna konsekvenser för certifikatförtroende och enhetshantering.

CONNECT är en tunnel, inte en cache

En explicit forward-proxy tar vanligtvis emot en HTTP CONNECT-begäran och vidarebefordrar sedan byten i båda riktningarna. Vidarebefordran är nyckelordet: proxyn tolkar inte det krypterade samtalet.

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

Svarshuvudena kommer från proxyns hantering av tunneln, inte från en cachad kopia av sidan. En lyckad CONNECT betyder att vägen fungerar, inte att något sparades för återanvändning. Att peka port 443 mot en cache lär den inte heller att tala TLS, eftersom cache kräver läsbara meddelanden. Klientkonfigurationen måste använda den stödda explicita proxyinställningen i stället för en oförklarad omdirigering.

Cacha det du driftar, inte det du surfar på

Där innehållet är ditt kan en omvänd proxy avsluta TLS och medvetet lagra godkända svar. Där det tillhör ett paketförråd, använd den spegel projektet stöder.

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

Det första kommandot visar om en cachezon är konfigurerad och var den gäller, medan det andra visar ursprungets egna cachningsdirektiv för ett objekt. En delad cache måste respektera färskhet, cachekontroller och de begäransattribut som skiljer representationer; private och no-store betyder olika saker och ingen av dem bör tas bort för att höja träfffrekvensen. HTTP-cacheregler begränsar också lagring av svar på autentiserade begäranden, och det är just där en personlig sida blir en dataexponering. Håll proxyn begränsad till godkända klienter i stället för att exponera en öppen relay.

Mät träffen, inte stoppuret

En snabbare andra begäran bevisar inte att den nya cachen gjorde något, eftersom webbläsare och operativsystem cachar aggressivt själva. Be proxyn om träff- och bomräknare och följ ursprungstrafiken under en kontrollerad upprepning. Använd en upprepad nedladdning av ett känt objekt, först med cachen på och sedan förbikopplad, och jämför byten ursprunget levererade i stället för förfluten tid. Kontrollera sedan auktoriseringsgränsen: en resurs som kräver inloggning ska inte levereras till en annan klient.

Anteckna arbetsbelastningen, cachenyckeln och policyn som tillät återanvändning. En cache är ett beslut om datadelning i optimeringskostym.