Kas agter 'n VPN: wat HTTPS steeds vir jou verberg

'n Kas langs die VPN-bediener klink na gratis bandwydte vir almal agter die tonnel. Dit is nie, want die grepe wat daardie punt passeer, bly beskerm deur 'n TLS-sessie waarvan die eindpunte die blaaier en die webwerf is. Die VPN-hek verwyder sy eie buitenste enkripsie, nie dié van die toepassing nie. Besluit watter herhaalde voorwerp jy wil hergebruik voordat jy hardeware byvoeg.

Die TLS-sessie behoort aan die blaaier

In gewone HTTPS onderhandel die blaaier sleutels met die werf, en elke rekord ná die handdruk word vir daardie paar eindpunte geënkripteer. 'n VPN-hek dekripteer die tonnel wat hy geskep het en stuur dan ondeursigtige TLS-rekords aan. Dit kan bestemmings, tydsberekening en volume sien, nie die versoekreël of die responsliggaam nie. Dit is die grens waarmee enige kas moet saamleef.

Enige ontwerp wat dit breek, is 'n TLS-onderskepontwerp, met sy eie sertifikaatvertroue en toestelbestuursgevolge.

CONNECT is 'n tonnel, nie 'n kas nie

'n Eksplisiete voorwaartse proxy ontvang gewoonlik 'n HTTP CONNECT-versoek en stuur dan grepe in beide rigtings deur. Deurstuur is die kernwoord: die proxy ontleed nie die geënkripteerde gesprek nie.

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

Die responsopskrifte kom uit die proxy se hantering van die tonnel, nie uit 'n gekaste kopie van die bladsy nie. 'n Suksesvolle CONNECT beteken die pad werk, nie dat iets vir hergebruik gestoor is nie. Om poort 443 na 'n kas te wys leer dit ook nie om TLS te praat nie, want kas vereis leesbare boodskappe. Kliëntkonfigurasie moet die ondersteunde eksplisiete proxy-instelling gebruik eerder as 'n onverklaarde herleiding.

Kas wat jy bedryf, nie wat jy blaai nie

Waar die inhoud joune is, kan 'n omgekeerde proxy TLS beëindig en goedgekeurde response doelbewus stoor. Waar dit aan 'n pakketbewaarplek behoort, gebruik die spieël wat die projek ondersteun.

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

Die eerste opdrag wys of 'n kas-sone gekonfigureer is en waar dit geld, terwyl die tweede die oorsprong se eie kas-riglyne vir een voorwerp wys. 'n Gedeelde kas moet varsheid, kas-beheer en die versoekkenmerke wat voorstellings onderskei respekteer; private en no-store beteken verskillende dinge en nie een moet gestroop word om 'n trefsyfer te verhoog nie. HTTP-kasreëls beperk ook die stoor van response op gemagtigde versoeke, en dit is presies waar 'n gepersonaliseerde bladsy 'n data-blootstelling word. Hou die proxy beperk tot goedgekeurde kliënte eerder as om 'n oop deurstuur bloot te stel.

Meet die treffer, nie die stophorlosie nie

'n Vinniger tweede versoek bewys nie dat die nuwe kas iets gedoen het nie, want blaaiers en bedryfstelsels kas self aggressief. Vra die proxy vir treffer- en mistellings en kyk na oorsprongverkeer tydens 'n beheerde herhaling. Gebruik een herhaalde aflaai van 'n bekende voorwerp, met die kas aan en dan omseil, en vergelyk die oorsprong se grepe wat gelewer is eerder as verstreke tyd. Kontroleer dan die magtigingsgrens: 'n hulpbron wat 'n aanmelding vereis, moet nie aan 'n ander kliënt gelewer word nie.

Teken die werklading, die kassleutel en die beleid wat hergebruik toegelaat het, aan. 'n Kas is 'n datadeling-besluit in 'n optimaliseringskostuum.