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

Keš pored VPN servera zvuči kao besplatan protok za sve iza tunela. Nije, jer bajtovi koji prolaze tom tačkom ostaju zaštićeni TLS sesijom čiji su krajevi pregledač i veb-stranica. VPN prolaz uklanja samo sopstveno spoljno šifrovanje, ne ono aplikacije. Odlučite koji ponovljeni objekat želite ponovo da koristite pre nego što dodate hardver.

TLS sesija pripada pregledaču

U običnom HTTPS-u pregledač dogovara ključeve sa stranicom, a svaki zapis posle rukovanja šifrovan je za taj par krajeva. VPN prolaz dešifruje tunel koji je stvorio i zatim prosleđuje neprozirne TLS zapise. Vidi odredišta, vreme i obim, ali ne red zahteva ni telo odgovora. To je granica sa kojom svaki keš mora da živi.

Svaki dizajn koji je narušava jeste dizajn presretanja TLS-a, sa sopstvenim posledicama po poverenje u sertifikate i upravljanje uređajima.

CONNECT je tunel, a ne keš

Eksplicitni prednji proxy obično primi HTTP CONNECT zahtev i zatim prenosi bajtove u oba smera. Prenos je ključna reč: proxy ne raščlanjuje šifrovani 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. Uspešan CONNECT znači da put radi, a ne da je nešto sačuvano za ponovnu upotrebu. Usmeravanje porta 443 na keš takođe ga ne uči da govori TLS, jer keširanje zahteva čitljive poruke. Konfiguracija klijenta mora da koristi podržanu postavku eksplicitnog proxyja, a ne neobjašnjeno preusmeravanje.

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

Gde je sadržaj vaš, obrnuti proxy može da prekine TLS i namerno sačuva odobrene odgovore. Gde pripada repozitorijumu paketa, upotrebite ogledalo koje projekat 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 da li je keš zona konfigurisana i gde se primenjuje, a druga pokazuje izvorne keš direktive za jedan objekat. Zajednički keš mora da poštuje svežinu, keš kontrole i atribute zahteva koji razlikuju prikaze; private i no-store znače različite stvari i nijedno ne treba ukloniti da bi se povećala stopa pogodaka. HTTP pravila keširanja takođe ograničavaju čuvanje odgovora na autentifikovane zahteve, i upravo tu personalizovana stranica postaje izlaganje podataka. Držite proxy ograničen na odobrene klijente umesto da izlažete otvoreni relej.

Merite pogodak, a ne štopericu

Brži drugi zahtev ne dokazuje da je novi keš nešto uradio, jer pregledači i operativni sistemi agresivno keširaju sami. Zatražite od proxyja brojače pogodaka i promašaja i posmatrajte saobraćaj izvora tokom kontrolisanog ponavljanja. Upotrebite jedno ponovljeno preuzimanje poznatog objekta, prvo sa uključenim kešom, pa zaobiđenim, i uporedite bajtove koje je izvor poslužio, a ne proteklo vreme. Zatim proverite granicu autorizacije: resurs koji zahteva prijavu ne sme da se posluži drugom klijentu.

Zabeležite posao, keš ključ i pravilo koje je dozvolilo ponovnu upotrebu. Keš je odluka o deljenju podataka u kostimu optimizacije.