Po třech letech vývoje bylo vydáno vydání nové stabilní verze proxy serveru Squid 5.1 který je připraven k použití na produkčních systémech (verze 5.0.x byly beta).
Poté, co je větev 5.x stabilní, od nynějška budou prováděny pouze opravy zranitelností a problémů se stabilitou, a budou povoleny také drobné optimalizace. Vývoj nových funkcí bude probíhat v nové experimentální větvi 6.0. Uživatelům starší stabilní větve 4.x doporučujeme naplánovat migraci na větev 5.x.
Squid 5.1 Hlavní nové funkce
V této nové verzi Podpora formátu Berkeley DB byla zastaralá kvůli problémům s licencí. Větev Berkeley DB 5.x není spravována již několik let a nadále má nezachycené chyby zabezpečení a upgrade na novější verze neumožňuje změnu licence AGPLv3, jejíž požadavky platí také pro aplikace využívající BerkeleyDB ve formě knihovny. - Squid je vydán pod licencí GPLv2 a AGPL není kompatibilní s GPLv2.
Místo Berkeley DB byl projekt přenesen na použití TrivialDB DBMS, který je na rozdíl od Berkeley DB optimalizován pro simultánní paralelní přístup k databázi. Podpora Berkeley DB je prozatím zachována, ale nyní se doporučuje použít v ovladačích „ext_session_acl“ a „ext_time_quota_acl“ místo „libdb“ typ úložiště „libtdb“.
Kromě toho byla přidána podpora pro hlavičku HTTP CDN-Loop definovanou v RFC 8586, která umožňuje detekovat smyčky při použití sítí pro doručování obsahu (záhlaví poskytuje ochranu před situacemi, ve kterých se požadavek z nějakého důvodu během přesměrování mezi CDN vrací k původní CDN, tvořící nekonečnou smyčku).
Kromě toho, mechanismus SSL-Bump, což umožňuje zachytit obsah šifrovaných relací HTTPS, hpřidaná podpora pro přesměrování falešných požadavků HTTPS prostřednictvím jiných serverů proxy zadaný v cache_peer pomocí pravidelného tunelu založeného na metodě HTTP CONNECT (streamování přes HTTPS není podporováno, protože Squid zatím nemůže streamovat TLS v rámci TLS).
SSL-Bump umožňuje po příchodu prvního zachyceného požadavku HTTPS navázat připojení TLS s cílovým serverem a získat jeho certifikát. Následně, Squid používá název hostitele skutečného přijatého certifikátu ze serveru a vytvořte falešný certifikát, se kterým při interakci s klientem napodobuje požadovaný serverpři současném používání připojení TLS navázaného s cílovým serverem k přijímání dat.
Rovněž je zdůrazněno, že implementace protokolu ICAP (Internet Content Adaptation Protocol), který se používá pro integraci s externími systémy ověřování obsahu, přidal podporu pro mechanismus připojení dat což vám umožňuje připojit k odpovědi další záhlaví metadat umístěná za zprávou. tělo.
Namísto zohlednění „dns_v4_first»Chcete -li určit pořadí použití rodiny adres IPv4 nebo IPv6, nyní je zohledněno pořadí odpovědi v DNS- Pokud se při čekání na vyřešení adresy IP nejprve zobrazí odpověď AAAA od DNS, použije se výsledná adresa IPv6. Nastavení upřednostňované skupiny adres se proto nyní provádí v bráně firewall, DNS nebo při spuštění pomocí možnosti „–disable-ipv6“.
Navrhovaná změna zrychlí čas konfigurace připojení TCP a sníží dopad zpoždění při rozlišení DNS na výkon.
Při přesměrování požadavků se používá algoritmus „Happy Eyeballs“, který okamžitě používá přijatou IP adresu, aniž by čekal na vyřešení všech potenciálně dostupných cílových adres IPv4 a IPv6.
Pro použití ve směrnici „external_acl“ byl přidán ovladač „ext_kerberos_sid_group_acl“ pro ověřování pomocí ověřovacích skupin ve službě Active Directory pomocí Kerberos. K dotazu na název skupiny slouží nástroj ldapsearch poskytovaný balíčkem OpenLDAP.
Přidány direktivy mark_client_connection a mark_client_pack pro vazbu značek Netfilter (CONNMARK) na jednotlivé pakety nebo připojení TCP klienta
Nakonec je uvedeno, že podle kroků vydaných verzí Squid 5.2 a Squid 4.17 chyby zabezpečení byly opraveny:
- CVE-2021-28116-Únik informací při zpracování speciálně vytvořených zpráv WCCPv2. Tato chyba zabezpečení umožňuje útočníkovi poškodit seznam známých směrovačů WCCP a přesměrovat provoz z proxy klienta na hostitele. Problém se projevuje pouze v konfiguracích s povolenou podporou WCCPv2 a když je možné zfalšovat IP adresu routeru.
- CVE-2021-41611: chyba při ověřování certifikátů TLS, které umožňují přístup pomocí nedůvěryhodných certifikátů.
Nakonec, pokud se o tom chcete dozvědět více, můžete zkontrolovat podrobnosti Na následujícím odkazu.