Cache y tu ôl i VPN: beth mae HTTPS yn ei guddio o hyd

Mae cache wrth ymyl gweinydd VPN yn swnio fel lled band am ddim i bawb y tu ôl i'r twnnel. Nid yw, oherwydd bod y beitiau sy'n mynd trwy'r pwynt hwnnw'n parhau i fod wedi'u hamddiffyn gan sesiwn TLS y mae ei phennau'n y porwr a'r wefan. Mae'r porth VPN yn tynnu ei amgryptiad allanol ei hun, nid un y rhaglen. Penderfynwch pa wrthrych ailadroddus rydych am ei ailddefnyddio cyn ychwanegu caledwedd.

Mae'r sesiwn TLS yn perthyn i'r porwr

Mewn HTTPS cyffredin mae'r porwr yn trafod allweddi gyda'r safle, ac mae pob cofnod ar ôl yr ysgwyd llaw wedi'i amgryptio ar gyfer y pâr hwnnw o bennau. Mae porth VPN yn dadgryptio'r twnnel a grëodd ac yna'n anfon cofnodion TLS afloyw ymlaen. Gall weld cyrchfannau, amseru a chyfaint, nid y llinell gais na chorff yr ymateb. Dyna'r ffin y mae'n rhaid i unrhyw cache fyw gyda hi.

Mae unrhyw ddyluniad sy'n ei thorri yn ddyluniad rhyng-gipio TLS, gyda'i ganlyniadau ei hun o ran ymddiriedaeth tystysgrifau a rheoli dyfeisiau.

Twnnel yw CONNECT, nid cache

Mae proxy blaen penodol fel arfer yn cael cais HTTP CONNECT ac yna'n ailgludo beitiau i'r ddau gyfeiriad. Ailgludo yw'r gair allweddol: nid yw'r proxy'n dosrannu'r sgwrs amgryptiedig.

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

Mae'r penawdau ymateb yn dod o driniaeth y proxy o'r twnnel, nid o gopi cadw o'r dudalen. Mae CONNECT llwyddiannus yn golygu bod y llwybr yn gweithio, nid bod rhywbeth wedi'i storio i'w ailddefnyddio. Pwyntio porth 443 at cache nid yw'n ei dysgu i siarad TLS chwaith, oherwydd mae caching yn gofyn am negeseuon darllenadwy. Rhaid i ffurfwedd y cleient ddefnyddio'r gosodiad proxy penodol a gefnogir yn hytrach nag ailgyfeiriad heb esboniad.

Cadwch yr hyn rydych yn ei weithredu, nid yr hyn rydych yn ei bori

Lle mae'r cynnwys yn eiddo i chi, gall proxy gwrthdro derfynu TLS a storio ymatebion cymeradwy yn fwriadol. Lle mae'n perthyn i storfa pecynnau, defnyddiwch y drych y mae'r prosiect yn ei gefnogi.

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

Mae'r gorchymyn cyntaf yn dangos a yw parth cache wedi'i ffurfweddu a ble mae'n berthnasol, tra mae'r ail yn dangos cyfarwyddebau caching y tarddiad ei hun ar gyfer un gwrthrych. Rhaid i cache a rennir barchu ffresni, rheolyddion cache a nodweddion y cais sy'n gwahaniaethu cynrychioliadau; private a no-store yn golygu pethau gwahanol ac ni ddylid tynnu'r naill na'r llall er mwyn codi cyfradd taro. Mae rheolau caching HTTP hefyd yn cyfyngu storio ymatebion i geisiadau dilys, a dyna'n union lle mae tudalen bersonol yn dod yn ddatguddiad data. Cadwch y proxy wedi'i gyfyngu i gleientiaid cymeradwy yn hytrach na datgelu relái agored.

Mesurwch y taro, nid yr amserydd

Nid yw ail gais cyflymach yn profi bod y cache newydd wedi gwneud unrhyw beth, oherwydd bod porwyr a systemau gweithredu'n cadw'n ymosodol eu hunain. Gofynnwch i'r proxy am gyfrifwyr taro a methiant a gwyliwch draffig y tarddiad yn ystod ailadroddiad rheoledig. Defnyddiwch un lawrlwythiad ailadroddus o wrthrych hysbys, gyda'r cache ymlaen ac yna'n cael ei osgoi, a chymharwch y beitiau a wasanaethwyd gan y tarddiad yn hytrach nag amser a aeth heibio. Yna gwiriwch y ffin awdurdodi: ni ddylid gwasanaethu adnodd sy'n gofyn am fewngofnodi i gleient arall.

Cofnodwch y llwyth, allwedd y cache a'r polisi a ganiataodd ailddefnydd. Penderfyniad rhannu data mewn gwisg optimeiddio yw cache.