Кеш иза VPN-а: шта HTTPS још крије од вас

Кеш поред VPN сервера звучи као бесплатан проток за све иза тунела. Није, јер бајтови који пролазе том тачком остају заштићени TLS сесијом чији су крајеви прегледач и веб-страница. VPN пролаз уклања само сопствено спољно шифровање, не оно апликације. Одлучите који поновљени објекат желите поново да користите пре него што додате хардвер.

TLS сесија припада прегледачу

У обичном HTTPS-у прегледач договара кључеве са страницом, а сваки запис после руковања шифрован је за тај пар крајева. VPN пролаз дешифрује тунел који је створио и затим прослеђује непрозирне TLS записе. Види одредишта, време и обим, али не ред захтева ни тело одговора. То је граница са којом сваки кеш мора да живи.

Сваки дизајн који је нарушава јесте дизајн пресретања TLS-а, са сопственим последицама по поверење у сертификате и управљање уређајима.

CONNECT је тунел, а не кеш

Експлицитни предњи прокси обично прими HTTP CONNECT захтев и затим преноси бајтове у оба смера. Пренос је кључна реч: прокси не рашчлањује шифровани разговор.

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

Заглавља одговора долазе из проксијеве обраде тунела, а не из кеширане копије странице. Успешан CONNECT значи да пут ради, а не да је нешто сачувано за поновну употребу. Усмеравање порта 443 на кеш такође га не учи да говори TLS, јер кеширање захтева читљиве поруке. Конфигурација клијента мора да користи подржану поставку експлицитног проксија, а не необјашњено преусмеравање.

Кеширајте оно што водите, а не оно што прегледате

Где је садржај ваш, обрнути прокси може да прекине TLS и намерно сачува одобрене одговоре. Где припада репозиторијуму пакета, употребите огледало које пројекат подржава.

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

Прва наредба показује да ли је кеш зона конфигурисана и где се примењује, а друга показује изворне кеш директиве за један објекат. Заједнички кеш мора да поштује свежину, кеш контроле и атрибуте захтева који разликују приказе; private и no-store значе различите ствари и ниједно не треба уклонити да би се повећала стопа погодака. HTTP правила кеширања такође ограничавају чување одговора на аутентификоване захтеве, и управо ту персонализована страница постаје излагање података. Држите прокси ограничен на одобрене клијенте уместо да излажете отворени релеј.

Мерите погодак, а не штоперицу

Бржи други захтев не доказује да је нови кеш нешто урадио, јер прегледачи и оперативни системи агресивно кеширају сами. Затражите од проксија бројаче погодака и промашаја и посматрајте саобраћај извора током контролисаног понављања. Употребите једно поновљено преузимање познатог објекта, прво са укљученим кешом, па заобиђеним, и упоредите бајтове које је извор послужио, а не протекло време. Затим проверите границу ауторизације: ресурс који захтева пријаву не сме да се послужи другом клијенту.

Забележите посао, кеш кључ и правило које је дозволило поновну употребу. Кеш је одлука о дељењу података у костиму оптимизације.