Kešatmiņa aiz VPN: ko HTTPS joprojām slēpj

Kešatmiņa blakus VPN serverim izklausās kā bezmaksas joslas platums visiem aiz tuneļa. Tā nav, jo baiti, kas iet caur šo punktu, joprojām ir aizsargāti ar TLS sesiju, kuras gali ir pārlūkprogramma un vietne. VPN vārteja noņem tikai savu ārējo šifrēšanu, nevis lietojumprogrammas. Pirms aparatūras pievienošanas izlemiet, kuru atkārtoto objektu vēlaties izmantot atkārtoti.

TLS sesija pieder pārlūkprogrammai

Parastā HTTPS pārlūkprogramma vienojas par atslēgām ar vietni, un katrs ieraksts pēc rokasspiediena tiek šifrēts šim galu pārim. VPN vārteja atšifrē tās izveidoto tuneli un pēc tam pārsūta necaurspīdīgus TLS ierakstus. Tā redz galamērķus, laiku un apjomu, nevis pieprasījuma rindu vai atbildes pamattekstu. Tā ir robeža, ar kuru jāsadzīvo katrai kešatmiņai.

Jebkurš dizains, kas to pārkāpj, ir TLS pārtveršanas dizains ar savām sekām sertifikātu uzticēšanās un ierīču pārvaldības jomā.

CONNECT ir tunelis, nevis kešatmiņa

Skaidrs tiešais starpniekserveris parasti saņem HTTP CONNECT pieprasījumu un pēc tam pārsūta baitus abos virzienos. Pārsūtīšana ir atslēgas vārds: starpniekserveris neanalizē šifrēto sarunu.

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

Atbildes galvenes nāk no starpniekservera tuneļa apstrādes, nevis no lapas kešotās kopijas. Veiksmīgs CONNECT nozīmē, ka ceļš darbojas, nevis ka kaut kas tika saglabāts atkārtotai izmantošanai. 443. porta novirzīšana uz kešatmiņu arī nemāca tam runāt TLS, jo kešošanai vajadzīgi lasāmi ziņojumi. Klienta konfigurācijai jāizmanto atbalstītais skaidrās starpniekservera iestatījums, nevis neizskaidrots novirzījums.

Kešojiet to, ko pārvaldāt, nevis to, ko pārlūkojat

Ja saturs ir jūsu, apgrieztais starpniekserveris var pabeigt TLS un apzināti saglabāt apstiprinātas atbildes. Ja tas pieder pakotņu krātuvei, izmantojiet spoguli, ko atbalsta projekts.

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

Pirmā komanda parāda, vai kešatmiņas zona ir konfigurēta un kur tā attiecas, bet otrā parāda avota pašas kešošanas direktīvas vienam objektam. Koplietotai kešatmiņai jārespektē svaigums, kešatmiņas kontroles un pieprasījuma atribūti, kas atšķir attēlojumus; private un no-store nozīmē dažādas lietas, un nevienu nevajadzētu noņemt, lai paaugstinātu trāpījumu īpatsvaru. HTTP kešošanas noteikumi arī ierobežo atbilžu glabāšanu autentificētiem pieprasījumiem, un tieši tur personalizēta lapa kļūst par datu noplūdi. Turiet starpniekserveri ierobežotu ar apstiprinātiem klientiem, nevis atklājiet atvērtu releju.

Mēriet trāpījumu, nevis hronometru

Ātrāks otrais pieprasījums nepierāda, ka jaunā kešatmiņa kaut ko darīja, jo pārlūkprogrammas un operētājsistēmas pašas kešo agresīvi. Palūdziet starpniekserverim trāpījumu un netrāpījumu skaitītājus un vērojiet avota trafiku kontrolētā atkārtojumā. Izmantojiet vienu atkārtotu zināma objekta lejupielādi, vispirms ar ieslēgtu kešatmiņu, pēc tam to apsteidzot, un salīdziniet avota piegādātos baitus, nevis pagājušo laiku. Pēc tam pārbaudiet autorizācijas robežu: resursu, kam nepieciešama pieteikšanās, nedrīkst piegādāt citam klientam.

Pierakstiet darba slodzi, kešatmiņas atslēgu un politiku, kas atļāva atkārtotu izmantošanu. Kešatmiņa ir datu koplietošanas lēmums optimizācijas kostīmā.