Cache achter een VPN: wat HTTPS nog steeds verbergt

Een cache naast de VPN-server klinkt als gratis bandbreedte voor iedereen achter de tunnel. Dat is het niet, want de bytes die dat punt passeren blijven beschermd door een TLS-sessie waarvan de uiteinden de browser en de website zijn. De VPN-gateway verwijdert alleen zijn eigen buitenste versleuteling, niet die van de applicatie. Bepaal welk herhaald object u wilt hergebruiken voordat u hardware toevoegt.

De TLS-sessie is van de browser

Bij gewone HTTPS onderhandelt de browser sleutels met de site, en elk record na de handshake is versleuteld voor dat paar uiteinden. Een VPN-gateway ontsleutelt de tunnel die hij heeft gemaakt en stuurt daarna ondoorzichtige TLS-records door. Hij ziet bestemmingen, timing en volume, niet de verzoekregel of de responsbody. Dat is de grens waar elke cache mee moet leven.

Elk ontwerp dat die grens breekt, is een TLS-onderscheppingsontwerp, met eigen gevolgen voor certificaatvertrouwen en apparaatbeheer.

CONNECT is een tunnel, geen cache

Een expliciete forward-proxy ontvangt meestal een HTTP CONNECT-verzoek en stuurt daarna bytes in beide richtingen door. Doorsturen is het sleutelwoord: de proxy parseert het versleutelde gesprek niet.

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

De responsheaders komen uit de tunnelafhandeling van de proxy, niet uit een gecachte kopie van de pagina. Een geslaagde CONNECT betekent dat het pad werkt, niet dat er iets is opgeslagen voor hergebruik. Poort 443 naar een cache wijzen leert hem ook niet TLS spreken, want cachen vereist leesbare berichten. De clientconfiguratie moet de ondersteunde expliciete proxyinstelling gebruiken in plaats van een onverklaarde omleiding.

Cache wat u beheert, niet wat u browset

Waar de inhoud van u is, kan een reverse proxy TLS beëindigen en goedgekeurde antwoorden bewust opslaan. Waar die van een pakketrepository is, gebruikt u de spiegel die het project ondersteunt.

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

De eerste opdracht laat zien of er een cachezone is geconfigureerd en waar die geldt, de tweede toont de eigen cache-instructies van de oorsprong voor één object. Een gedeelde cache moet frisheid, cachebesturing en de verzoekattributen respecteren die representaties onderscheiden; private en no-store betekenen verschillende dingen en geen van beide mag worden verwijderd om de hitratio te verhogen. HTTP-cacheregels beperken ook het opslaan van antwoorden op geauthenticeerde verzoeken, en precies daar wordt een gepersonaliseerde pagina een datalek. Houd de proxy beperkt tot goedgekeurde clients in plaats van een open relay aan te bieden.

Meet de hit, niet de stopwatch

Een sneller tweede verzoek bewijst niet dat de nieuwe cache iets deed, want browsers en besturingssystemen cachen zelf agressief. Vraag de proxy om hit- en mistellers en volg het oorsprongsverkeer tijdens een gecontroleerde herhaling. Gebruik één herhaalde download van een bekend object, eerst met de cache aan en daarna omzeild, en vergelijk de bytes die de oorsprong leverde in plaats van de verstreken tijd. Controleer daarna de autorisatiegrens: een resource die inloggen vereist, mag niet aan een andere client worden geleverd.

Noteer de werklast, de cachesleutel en het beleid dat hergebruik toestond. Een cache is een beslissing over het delen van data in een optimalisatiekostuum.