Keš iza VPN-a: šta HTTPS još krije od vas

Keš pored VPN servera zvuči kao besplatna propusnost za sve iza tunela. Nije, jer bajtovi koji prolaze tom tačkom ostaju zaštićeni TLS sesijom čiji su krajevi preglednik i web-stranica. VPN pristupnik uklanja samo vlastito vanjsko šifriranje, ne ono aplikacije. Odlučite koji ponovljeni objekt želite ponovno koristiti prije nego dodate hardver.

TLS sesija pripada pregledniku

U običnom HTTPS-u preglednik dogovara ključeve sa stranicom, a svaki zapis nakon rukovanja šifriran je za taj par krajeva. VPN pristupnik dešifrira tunel koji je stvorio i zatim prosljeđuje neprozirne TLS zapise. Vidi odredišta, vrijeme i obim, ali ne redak zahtjeva ni tijelo odgovora. To je granica s kojom svaki keš mora živjeti.

Svaki dizajn koji je narušava jest dizajn presretanja TLS-a, s vlastitim posljedicama za povjerenje u certifikate i upravljanje uređajima.

CONNECT je tunel, a ne keš

Eksplicitni prednji proxy obično primi HTTP CONNECT zahtjev i zatim prenosi bajtove u oba smjera. Prijenos je ključna riječ: proxy ne raščlanjuje šifrirani razgovor.

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

Zaglavlja odgovora dolaze iz proxyjeve obrade tunela, a ne iz keširane kopije stranice. Uspješan CONNECT znači da put radi, a ne da je nešto spremljeno za ponovnu upotrebu. Usmjeravanje porta 443 na keš također ga ne uči govoriti TLS, jer keširanje zahtijeva čitljive poruke. Konfiguracija klijenta mora koristiti podržanu postavku eksplicitnog proxyja, a ne neobjašnjeno preusmjeravanje.

Keširajte ono što vodite, a ne ono što pregledavate

Gdje je sadržaj vaš, obrnuti proxy može prekinuti TLS i namjerno pohraniti odobrene odgovore. Gdje pripada repozitoriju paketa, upotrijebite zrcalo koje projekt podržava.

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

Prva naredba pokazuje je li keš zona konfigurirana i gdje se primjenjuje, a druga pokazuje izvorne keš direktive za jedan objekt. Zajednički keš mora poštovati svježinu, keš kontrole i atribute zahtjeva koji razlikuju prikaze; private i no-store znače različite stvari i nijedno se ne smije ukloniti radi povećanja stope pogodaka. HTTP pravila keširanja također ograničavaju pohranu odgovora na autentificirane zahtjeve, i upravo tu personalizirana stranica postaje izlaganje podataka. Držite proxy ograničen na odobrene klijente umjesto da izlažete otvoreni relej.

Mjerite pogodak, a ne štopericu

Brži drugi zahtjev ne dokazuje da je novi keš nešto učinio, jer preglednici i operacijski sustavi agresivno keširaju sami. Zatražite od proxyja brojače pogodaka i promašaja i promatrajte promet izvora tijekom kontroliranog ponavljanja. Upotrijebite jedno ponovljeno preuzimanje poznatog objekta, s uključenim pa zaobiđenim kešom, i usporedite bajtove koje je izvor poslužio, a ne proteklo vrijeme. Zatim provjerite granicu autorizacije: resurs koji zahtijeva prijavu ne smije se poslužiti drugom klijentu.

Zabilježite posao, keš ključ i pravilo koje je dopustilo ponovnu upotrebu. Keš je odluka o dijeljenju podataka u kostimu optimizacije.