Кэш за 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 таксама абмяжоўваюць захаванне адказаў на аўтэнтыфікаваныя запыты, і менавіта тут персаналізаваная старонка становіцца ўцечкай даных. Трымайце проксі абмежаваным адабранымі кліентамі, а не адкрытым рэле.

Мерце пападанне, а не секундамер

Хутчэйшы другі запыт не даказвае, што новы кэш нешта зрабіў, бо браўзеры і аперацыйныя сістэмы агрэсіўна кэшуюць самі. Запытайце ў проксі лічыльнікі пападанняў і промахаў і назірайце за трафікам крыніцы падчас кантраляванага паўтору. Выкарыстайце адно паўторнае спампоўванне вядомага аб'екта — спачатку з уключаным кэшам, потым у абыход — і параўнайце байты, аддадзеныя крыніцай, а не прайшоўшы час. Затым праверце мяжу аўтарызацыі: рэсурс, які патрабуе ўваходу, не павінен аддавацца іншаму кліенту.

Запішыце нагрузку, ключ кэша і палітыку, якая дазволіла паўторнае выкарыстанне. Кэш — гэта рашэнне аб сумесным выкарыстанні даных у касцюме аптымізацыі.