Представлена новая стабильная ветка прокси-сервера Squid 3.3, которая по заявлению разработчиков достигла состояния готовности для промышленного использования.

После придания ветке 3.3.x статуса стабильной, в ней отныне будут производиться только исправления уязвимостей и проблем со стабильностью, также допускается внесение небольших оптимизаций. Поддержка прошлой стабильной ветки 3.2.x в ближайшее время будет прекращена, пользователям рекомендуется спланировать переход на ветку 3.3.x. В настоящий момент усилия разработчиков направлены на развитие экспериментальной ветки Squid 3.4, в которой планируется реализовать систему проверки SSL-сертификатов, добавить директиву note для создания аннотированный транзакций, обеспечить возможность работы ACL без разрешения имён в DNS.

Основные новшества Squid 3.3:

• Новый хелпер log_db_daemon для организации хранения содержимого логов access.log в SQL БД. Для организации записи логов в БД подготовлен специальный фоновый процесс, написанный на языке Perl и поддерживающий любые СУБД для которых имеется DBD-драйвер;
• Новый хелпер ext_time_quota_acl для ограничения сессий по времени работы. При помощи данного хелпера администратор может определить квоту на время, которое пользователь может провести в сети (например, разрешить работать не больше часа в день). Например, можно использовать данную возможность для лимитирования доступа детей, пользователей публичных Wifi-сетей или работников офиса в Интернет. Для логического связывания серии запросов в непрерывную сессию в конфигурации задаётся порог, определяющий максимальный промежуток между двумя запросами, если время между запросами не превысило порог, то оно засчитывается как потраченное в рамках квоты;
• Поддержка режима SSL-Bump server для перехвата и кэширования содержимого шифрованных HTTPS-сеансов. При поступлении первого перехватываемого HTTPS-запроса, Squid осуществляет SSL-соединение с сервером и получает его сертификат. После этого Squid использует имя хоста из реального полученного от сервера сертификата и создаёт фиктивный сертификат, при помощи которого имитирует запрошенный сервер при взаимодействии с клиентом, продолжая при этом использовать SSL-соединение, установленное с сервером. Кроме HTTPS-соединений, указанная схема может использоваться для перехвата большинства HTTP-запросов с методом CONNECT.

  Прошлая реализация SSL-Bump отличалась созданием на первом этапе SSL-соединения между клиентом и Squid и только затем созданием соединения с сервером, что не позволяло использовать в фиктивном сертификате детали реального сертификата, получаемого от сервера. Кроме того, новый метод позволяет работать в ситуациях, когда браузер не передаёт имя хоста при отправке запроса CONNECT;

• Режим имитации SSL-сертификата сервера, при котором клиенту, при генерации фиктивного сертификата, транслируются все детали из реального сертификата сервера, что позволяет клиенту более осмысленно принять решение доверять данному сертификату или нет;
• Возможность определения собственных дополнительных HTTP-заголовков, добавляемых при отправке запросов на сервер. Для добавления HTTP-заголовков в исходящие запросы следует использовать директиву request_header_add. Если в директиве задан уже установленный клиентом заголовок, то он будет заменён. В составе аргументов request_header_add может использоваться большинство макросов "%имя", поддерживаемых системой ведения логов (некоторые макромы на этапе отправки заголовка могут быть недоступны). Для принятия решения добавлять заголовок или нет могут быть задействованы ACL;
• На этапе сборки отныне автоматически определяется и включается поддержка подсистемы kqueue, без необходимости ручного указания опции "--enable-kqueue".