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

Измеряйте попадание, а не секундомер

Более быстрый второй запрос не доказывает, что новый кэш что-то сделал, потому что браузеры и операционные системы агрессивно кэшируют сами. Попросите у прокси счётчики попаданий и промахов и наблюдайте за трафиком источника при контролируемом повторе. Используйте одну повторную загрузку известного объекта — сначала с включённым кэшем, затем в обход — и сравните байты, отданные источником, а не прошедшее время. Затем проверьте границу авторизации: ресурс, требующий входа, не должен отдаваться другому клиенту.

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