Privoxy 4.2.0 — стабильный релиз фильтрующего прокси с исправлениями безопасности и поддержкой ECC

Privoxy 4.2.0 вышел как стабильное обновление фильтрующего HTTP-прокси и в первую очередь интересен администраторам, которые используют его для приватности, блокировки рекламы, переписывания заголовков и контроля доступа. Релиз закрывает две потенциальные проблемы безопасности, улучшает работу ACL, обновляет HTTPS-инспекцию и добавляет генерацию сертификатов на elliptic-curve keys по умолчанию.

Privoxy 4.2.0 — стабильный релиз фильтрующего прокси
Privoxy 4.2.0 — стабильный релиз фильтрующего прокси

Privoxy остаётся гибким прокси для фильтрации трафика и контроля поведения браузера

Privoxy — это локальный или сетевой HTTP-прокси с расширенными правилами фильтрации. Он может удалять рекламу, управлять cookies, менять HTTP-заголовки, блокировать отдельные адреса, применять фильтры к содержимому страниц и передавать трафик дальше через другие прокси. В официальном описании проект называет Privoxy non-caching web proxy, то есть прокси без кэширования, ориентированный на фильтрацию и приватность.

На практике Privoxy часто используют в трёх сценариях.

Первый сценарий — персональная фильтрация на рабочей станции. Пользователь направляет HTTP и HTTPS-трафик браузера на 127.0.0.1:8118, после чего Privoxy применяет локальные правила. Такой подход удобен для тонкой настройки поведения сайтов, блокировки трекеров, отключения лишних баннеров и контроля заголовков.

Второй сценарий — фильтрация для небольшой сети. Администратор запускает Privoxy на сервере или шлюзе и разрешает доступ клиентам из локальной сети. Такой вариант требует аккуратной настройки listen-address, ACL и правил доступа, так как открытый прокси быстро становится проблемой безопасности.

Третий сценарий — цепочка прокси. Privoxy можно использовать перед SOCKS- или HTTP-прокси, чтобы сначала очистить и изменить запросы, затем отправить их дальше. Такой режим полезен в лабораторных стендах, тестовых окружениях и сетях, где требуется централизованная маршрутизация запросов.

Релиз 4.2.0 закрывает две потенциальные проблемы безопасности

Официальный раздел “What's New in this Release” сообщает, что Privoxy 4.2.0 исправляет несколько ошибок, добавляет общие улучшения и закрывает две потенциальные проблемы безопасности: Privoxy 4.2.0 User Manual.

Первая проблема связана с разбором размера блока в chunked transfer encoding. В новой версии размер блока разбирается отдельной функцией, а слишком большие значения отклоняются. Это снижает риск silent truncation через sscanf(), integer overflow и последующей неверной обработки содержимого. В описании также упомянуты alleged heap buffer overflows на платформах с 32-битными указателями. Проблема отслеживалась как OVE-20260515-0002.

Вторая проблема затрагивает функцию ssl_send_certificate_error(). Сообщение об ошибке сертификата теперь хранится в heap-памяти, что снижает риск сбоя при слишком длинной цепочке сертификатов. Этот пункт связан с OVE-20260515-0001.

Для обычного пользователя эти детали могут выглядеть слишком низкоуровневыми. Смысл проще: разработчики усилили обработку входных данных и сообщений TLS-ошибок, где ошибка в памяти могла привести к сбою или некорректному поведению. Для серверов, где Privoxy доступен нескольким клиентам, обновление выглядит особенно полезным.

Поддержка elliptic-curve keys ускоряет HTTPS-инспекцию в современных окружениях

Главное заметное изменение Privoxy 4.2.0 — директива elliptic-curve-keys. Она включена по умолчанию и позволяет Privoxy использовать группу SN_X9_62_prime256v1 при генерации ключей и сертификатов сайтов для HTTPS-инспекции. В документации указано, что такой вариант ожидаемо быстрее RSA, хотя очень старые клиенты могут его не поддерживать: раздел elliptic-curve-keys.

HTTPS-инспекция в Privoxy работает так: браузер подключается к прокси, Privoxy создаёт локальный сертификат для посещаемого сайта, затем анализирует и фильтрует содержимое соединения. Для этого администратор должен настроить CA-сертификат Privoxy и добавить его в доверенные на клиентской стороне. В корпоративной или домашней сети такой режим даёт тонкий контроль над содержимым, но требует строгой дисциплины: доступ к ключам, каталогам сертификатов и конфигурации должен быть ограничен.

Появление ECC полезно там, где Privoxy регулярно генерирует сертификаты для большого числа сайтов. Меньшая нагрузка на криптографические операции может дать более отзывчивую работу прокси, особенно на слабом железе, старых мини-ПК, роутерах и виртуальных машинах с ограниченными ресурсами.

Если нужна совместимость со старыми клиентами, директиву можно отключить:

elliptic-curve-keys 0

В таком режиме Privoxy будет генерировать RSA-сертификаты. Это может пригодиться в старых тестовых стендах, где клиенты не поддерживают современные elliptic-curve keys.

Исправления ACL повышают предсказуемость правил доступа

В Privoxy 4.2.0 исправлена логика block_acl(). Теперь совпадения ACL игнорируются в момент, когда пункт назначения ещё не известен, если само правило требует destination для проверки. После разбора запроса Privoxy снова применяет ACL уже с известным адресом назначения. В релиз-нотах указано, что это исправляет SF bug #913.

Для администратора это важный момент. ACL часто используются для ограничения доступа к прокси: разрешить только локальную сеть, запретить отдельные направления, разграничить клиентов по IP или подсетям. Ошибка в моменте применения правил может приводить к странному поведению: часть запросов блокируется неожиданно, часть проходит по условиям, которые администратор считал закрытыми.

В релиз также добавили код для более удобной отладки ACL-правил. Он включается на этапе сборки через новый параметр:

./configure --enable-acl-debugging

Такой режим полезен разработчикам пакетов, сопровождающим дистрибутивы и администраторам, которые собирают Privoxy самостоятельно. Для типовой установки из репозитория этот параметр обычно зависит от того, как пакет собран сопровождающим.

Обновления фильтров и action-файлов улучшают повседневную фильтрацию

Privoxy хранит правила поведения в action-файлах и filter-файлах. Они определяют, какие адреса блокировать, какие заголовки менять, какие фильтры применять к HTML и какие исключения делать для отдельных сайтов.

В версии 4.2.0 появились точечные изменения:

  • отключены fast-redirects для некоторых шаблонов URL;
  • добавлена блокировка .siteintercept.qualtrics.com/;
  • расширены правила для .parsely.com/;
  • разблокирован gitlab./search/count?;
  • добавлен фильтр для taz.de, скрывающий paywall-баннер;
  • обновлён фильтр SourceForge для скрытия рекламных элементов.

Такие изменения не выглядят масштабными, но они важны для инструмента, который работает на уровне правил. Сайты регулярно меняют структуру страниц, адреса трекеров и параметры редиректов. Поэтому фильтрующий прокси требует периодического обновления правил, даже когда основной функционал кажется стабильным.

Администраторам стало проще работать с документацией и инструментами

В релизе обновили документацию, man-страницы и вспомогательные утилиты. Для privoxy-log-parser, privoxy-regression-test и uagen теперь есть man pages, а раньше они документировались через perldoc. Это упрощает работу на серверах, где администратор привык быстро получать справку через man.

Также обновлён раздел о сообщении проблем безопасности. Проект просит раскрывать использование AI при подготовке отчётов и быть готовым отвечать на уточняющие вопросы. Это отражает общую проблему open source-проектов в 2026 году: сопровождающим приходится отделять полезные отчёты от автоматически сгенерированных сообщений с неполным контекстом.

Для обычного пользователя важнее другое: официальная документация Privoxy 4.2.0 уже обновлена и доступна как единая точка входа. В ней есть разделы по установке, настройке, HTTPS-инспекции, action-файлам, фильтрам, шаблонам и диагностике: Privoxy User Manual.

Обновление начинается с создания резервной копии конфигурации

Официальная памятка для обновления рекомендует сначала сохранить старые конфигурационные файлы, затем установить новые, проверить запуск Privoxy и только после этого перенести свои изменения через diff или patch: Note to Upgraders.

Практический порядок для Linux-сервера может выглядеть так:

sudo systemctl stop privoxy
sudo cp -a /etc/privoxy /etc/privoxy.backup.$(date +%F)

Дальше стоит обновить пакет штатным способом для своего дистрибутива. На Debian и Ubuntu команда обычно выглядит так:

sudo apt update
sudo apt install privoxy

После установки нужно проверить версию и статус службы:

privoxy --version
sudo systemctl status privoxy

Затем полезно сравнить старые и новые конфиги:

diff -ru /etc/privoxy.backup.$(date +%F) /etc/privoxy

Если конфигурация обслуживает несколько клиентов, обновление лучше сначала проверить на отдельном узле или в контейнере. Особенно внимательно стоит смотреть на:

  • listen-address;
  • permit-access и deny-access;
  • настройки HTTPS-инспекции;
  • пользовательские user.action и user.filter;
  • включение удалённого редактирования правил;
  • уровень логирования после обновления.

Настройки по умолчанию требуют проверки после перехода с ранних версий

В заметках для обновляющихся указано, что в конфигурации по умолчанию теперь логируются только fatal errors. Также три настройки выключены по умолчанию: enable-remote-toggle, enable-remote-http-toggle и enable-edit-actions. Пользователям, которым нужны эти возможности, придётся включить их явно и учитывать связанные риски.

Это разумная модель безопасности: удалённое переключение, HTTP-toggle и web-based action editor удобны, но при неверной публикации наружу дают лишнюю поверхность атаки. Если Privoxy работает только на локальной машине, риск ниже. Если сервис слушает сетевой интерфейс, такие параметры требуют строгого ограничения доступа.

Минимальная проверка после обновления:

grep -E "listen-address|enable-remote-toggle|enable-remote-http-toggle|enable-edit-actions" /etc/privoxy/config

Для домашнего компьютера типичная безопасная привязка выглядит так:

listen-address  127.0.0.1:8118

Для сетевого режима нужна явная ACL-политика. Например, разрешение только локальной подсети:

listen-address  192.168.1.10:8118
permit-access   192.168.1.0/24

Такой пример нужно адаптировать под реальную сеть. Оставлять прокси доступным всем адресам опасно: открытый прокси может быть использован посторонними для нежелательного трафика.

Privoxy 4.2.0 прекрасно подходит тем, кто использует HTTPS-инспекцию и сетевые ACL

Обновление стоит поставить в первую очередь тем, кто использует Privoxy как постоянный сервис на рабочей станции, домашнем сервере, шлюзе или тестовом стенде. Исправления безопасности, улучшения ACL и переход к elliptic-curve keys дают практическую пользу именно там, где прокси обрабатывает много запросов и работает с HTTPS-инспекцией.

Для разовой установки, где Privoxy запускается локально и используется редко, релиз тоже полезен. Он обновляет фильтры, документацию и поведение по умолчанию. Главная рекомендация остаётся простой: обновляться через штатный пакетный менеджер, сохранять старые конфиги и проверять работу браузера после изменения версии.

Быстрый тест после запуска:

curl -x http://127.0.0.1:8118 http://config.privoxy.org/

Если команда возвращает страницу конфигурации Privoxy, локальный прокси отвечает. После этого можно проверить браузер, правила блокировки и исключения для сайтов, где фильтрация мешает нормальной работе.

Главный вывод

Privoxy 4.2.0 — полезный стабильный релиз для тех, кто ценит управляемую фильтрацию HTTP/HTTPS-трафика и хочет держать прокси в актуальном состоянии. Самые важные изменения связаны с безопасностью, ACL, HTTPS-инспекцией и новой директивой elliptic-curve-keys.

Перед обновлением стоит сохранить /etc/privoxy, проверить локальные action- и filter-файлы, затем внимательно посмотреть на сетевые параметры доступа. Такой подход позволит получить исправления Privoxy 4.2.0 и сохранить уже настроенное поведение прокси.

При использовании материалов сайта необходимо указывать ссылку на TGLand.ru. Если вы копируете фрагменты текста в интернете, прямая гиперссылка, доступная для индексации поисковыми системами, должна быть размещена в начале материала.

Вам также может понравиться