Cache efter in VPN: wat HTTPS noch foar jo ferberget

In cache njonken de VPN-tsjinner klinkt as fergees bânbreedte foar elkenien efter de tunnel. Dat is it net, want de bytes dy't dat punt passearje bliuwe beskerme troch in TLS-sesje wêrfan't de einen de browser en de website binne. De VPN-gateway hellet allinnich syn eigen bûtenste fersifering weil, net dy fan 'e applikaasje. Beslis hokker weromkommend objekt jo werbrûke wolle foardat jo hardware tafoegje.

De TLS-sesje heart by de browser

Yn gewoane HTTPS ûnderhannelt de browser kaaien mei de site, en elk record nei de hânskieding wurdt fersifere foar dat pear einen. In VPN-gateway ûntsiferet de tunnel dy't er makke hat en stjoert dan ûntrochsichtige TLS-records troch. Hy kin bestimmingen, timing en folume sjen, net de oanfreechrige of de antwurdkern. Dat is de grins dêr't elke cache mei libje moat.

Elk ûntwerp dat dy brekt is in TLS-ôflústering-ûntwerp, mei syn eigen gefolgen foar sertifikaatfertrouwen en apparaatbehear.

CONNECT is in tunnel, gjin cache

In eksplisite foarút-proxy krijt meastentiids in HTTP CONNECT-fersyk en stjoert dan bytes yn beide rjochtingen troch. Trochstjoere is it kaairewurd: de proxy ûntsiferet it fersifere petear net.

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

De antwurdkoppen komme fan 'e tunnelôfhanneling fan 'e proxy, net fan in cachede kopy fan 'e side. In slagge CONNECT betsjut dat it paad wurket, net dat der wat bewarre is foar werbrûk. Poarte 443 nei in cache wize leart it ek net om TLS te praten, want cachen freget lêsbere berjochten. De kliïntkonfiguraasje moat de stipe eksplisite proxy-ynstelling brûke ynstee fan in ûnferklearre trochferwizing.

Cache wat jo beheare, net wat jo browse

Dêr't de ynhâld fan jo is, kin in omkearde proxy TLS beëinigje en goedkarde antwurden mei opsetsin bewarje. Dêr't er by in pakketopslach heart, brûk de spegel dy't it projekt stipet.

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

It earste kommando lit sjen oft in cache-sône konfigurearre is en wêr't dy jildt, wylst it twadde de eigen cache-ynstruksjes fan 'e oarsprong foar ien objekt lit sjen. In dielde cache moat frisheid, cachekontrôles en de fersykeatributen dy't foarstellings ûnderskiede respektearje; private en no-store betsjutte ferskillende dingen en gjin fan beide moat striekt wurde om in trefsifer te ferheegjen. HTTP-cacheregels beheine ek it bewarjen fan antwurden op ferifisearre fersiken, en krekt dêr wurdt in personalisearre side in datalek. Hâld de proxy beheind ta goedkarde kliïnten ynstee fan in iepen relay bleat te stellen.

Mjit de treffer, net de stopwatch

In flugger twadde fersyk bewiist net dat de nije cache wat dien hat, want browsers en bestjoeringssystemen cache har eigen agressyf. Freegje de proxy om treffer- en misstellers en besjoch it oarsprongsferkear by in kontrolearre werhelling. Brûk ien werhelle download fan in bekend objekt, earst mei de cache oan en dan omseild, en fergelykje de bytes dy't de oarsprong tsjinne ynstee fan ferstrutsen tiid. Kontrolearje dan de autorisaasjegrins: in boarne dy't oanmelding freget mei net oan in oare kliïnt tsjinne wurde.

Skriuw de wurklêst, de cacheskaai en it belied dat werbrûk tastie op. In cache is in datadielingsbeslút yn in optimizeringskostúm.