Після трьох років розробки вийшла нова стабільна версія проксі-сервера Squid, 5.1, яка готова до використання у виробничих системах (версії 5.0.x були бета-версією).
Після того, як гілка 5.x досягне стабільного стану, відтепер будуть впроваджуватися лише виправлення вразливостей та проблем зі стабільністю , а також незначні оптимізації. Розробка нових функцій відбуватиметься в новій експериментальній гілці 6.0. Користувачам попередньої стабільної гілки 4.x рекомендується планувати міграцію до гілки 5.x.
Основні нові функції Squid 5.1
У цій новій версії сумісність з форматом Berkeley DB була припинена через проблеми з ліцензуванням . Гілка Berkeley DB 5.x не підтримувалася протягом кількох років і досі має невиправлені вразливості, а оновлення до новіших версій не дозволяє змінювати ліцензію AGPLv3, вимоги якої також поширюються на програми, що використовують Berkeley DB як бібліотеку. Squid випускається під ліцензією GPLv2, а AGPL несумісний з GPLv2.
Замість Berkeley DB проєкт перейшов на використання СУБД TrivialDB, яка, на відміну від Berkeley DB, оптимізована для одночасного паралельного доступу до бази даних. Підтримка Berkeley DB наразі зберігається, але тепер рекомендується використовувати тип сховища "libtdb" замість "libdb" в обробниках "ext_session_acl" та "ext_time_quota_acl".
Крім того, була додана підтримка заголовка HTTP CDN-Loop, визначеного в RFC 8586, що дозволяє виявляти цикли при використанні мереж доставки контенту (заголовок забезпечує захист від ситуацій, коли запит під час перенаправлення між CDN з якоїсь причини повертається до вихідного CDN, утворюючи нескінченну петлю).
Крім того, механізм SSL-Bump, який дозволяє перехоплювати вміст зашифрованих HTTPS-сесій, має додану підтримку для перенаправлення підроблених HTTPS-запитів через інші проксі-сервери, зазначені в cache_peer, використовуючи звичайний тунель на основі методу HTTP CONNECT (передача через HTTPS не підтримується, оскільки Squid поки що не може передавати TLS всередині TLS).
SSL-Bump, отримавши перший перехоплений HTTPS-запит, встановлює TLS-з'єднання з цільовим сервером та отримує його сертифікат. Потім Squid використовує ім'я хоста справжнього сертифіката, отриманого від сервера, для створення підробленого сертифіката, який він використовує для імітації запитуваного сервера під час взаємодії з клієнтом , продовжуючи використовувати встановлене TLS-з'єднання з цільовим сервером для отримання даних.
Варто також зазначити, що реалізація ICAP ( Internet Content Adaptation Protocol), який використовується для інтеграції із зовнішніми системами перевірки контенту, додала підтримку механізму приєднання даних , що дозволяє додавати до відповіді додаткові заголовки метаданих, розміщуючи їх після тіла повідомлення.
Замість того, щоб враховувати "dns_v4_first»Щоб визначити порядок використання сімейства адрес IPv4 або IPv6, тепер враховується порядок відповіді в DNS- Якщо відповідь AAAA від DNS з'являється першою під час очікування вирішення IP -адреси, буде використана отримана адреса IPv6. Тому бажаний параметр сімейства адрес тепер виконується у брандмауері, DNS або при запуску з опцією "–disable-ipv6".
Запропонована зміна прискорить час налаштування TCP -з'єднань та зменшить вплив затримок у вирішенні DNS на продуктивність.
Під час перенаправлення запитів використовується алгоритм «Щасливі очі», який одразу використовує отриману IP-адресу, не чекаючи на розв'язання всіх потенційно доступних IPv4 та IPv6 адрес призначення.
Для використання у директиві "external_acl" додано драйвер "ext_kerberos_sid_group_acl" для автентифікації з групами перевірки в Active Directory за допомогою Kerberos. Утиліта ldapsearch, надана пакетом OpenLDAP, використовується для запиту імені групи.
Додано директиви mark_client_connection та mark_client_pack для прив'язки тегів Netfilter (CONNMARK) до окремих пакетів або клієнтських TCP -з'єднань
Нарешті, зазначається, що, дотримуючись кроків, описаних у опублікованих версіях Squid 5.2 та Squid 4.17, було виправлено такі вразливості:
- CVE-2021-28116-Витік інформації під час обробки спеціально створених повідомлень WCCPv2. Вразливість дозволяє зловмиснику пошкодити список відомих маршрутизаторів WCCP і перенаправити трафік з проксі -клієнта на його хост. Проблема проявляється тільки в конфігураціях з увімкненою підтримкою WCCPv2 і коли є можливість підробити IP -адресу маршрутизатора.
- CVE-2021-41611: помилка під час перевірки сертифікатів TLS, які дозволяють доступ за допомогою ненадійних сертифікатів.
Зрештою, якщо ви хочете дізнатися більше про це, ви можете перевірити деталі за наступним посиланням.