Po třech letech vývoje byla vydána nová stabilní verze proxy serveru Squid s názvem 5.1, která je připravena k použití v produkčních systémech (verze 5.0.x byly beta).
Jakmile větev 5.x dosáhne stabilního stavu, budou od nynějška implementovány pouze opravy zranitelností a problémů se stabilitou spolu s drobnými optimalizacemi. Vývoj nových funkcí bude probíhat v nové experimentální větvi 6.0. Uživatelům předchozí stabilní větve 4.x se doporučuje naplánovat migraci na větev 5.x.
Squid 5.1 Hlavní nové funkce
V této nové verzi je kompatibilita s formátem Berkeley DB z důvodu licenčních problémů zastaralá . Větev Berkeley DB 5.x nebyla několik let udržována a stále obsahuje neopravené zranitelnosti a upgrade na novější verze neumožňuje změnu licence AGPLv3, jejíž požadavky platí i pro aplikace, které používají Berkeley DB jako knihovnu. Squid je vydáván pod licencí GPLv2 a AGPL je s GPLv2 nekompatibilní.
Místo Berkeley DB projekt přešel na používání SŘBD TrivialDB, která je na rozdíl od Berkeley DB optimalizována pro simultánní paralelní přístup k databázi. Podpora Berkeley DB je prozatím zachována, ale nyní se doporučuje používat v obslužných rutinách „ext_session_acl“ a „ext_time_quota_acl“ typ úložiště „libtdb“ místo „libdb“.
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).
Mechanismus SSL-Bump, který umožňuje zachycovat obsah šifrovaných HTTPS relací, dále přidal podporu pro přesměrování padělaných HTTPS požadavků přes jiné proxy servery uvedené v cache_peer pomocí běžného tunelu založeného na metodě HTTP CONNECT (přenos přes HTTPS není podporován, protože Squid zatím nemůže přenášet TLS v rámci TLS).
SSL-Bump po přijetí prvního zachyceného HTTPS požadavku naváže TLS spojení s cílovým serverem a získá jeho certifikát. Squid poté použije název hostitele skutečného certifikátu přijatého od serveru k vytvoření falešného certifikátu, který používá k zosobnění požadovaného serveru při interakci s klientem , zatímco nadále používá navázané TLS spojení s cílovým serverem k příjmu dat.
Za zmínku také stojí, že implementace protokolu ICAP (Internet Content Adaptation Protocol), který se používá pro integraci s externími systémy pro ověřování obsahu, přidala podporu pro mechanismus připojení dat , který umožňuje připojení dalších záhlaví metadat k odpovědi, umístěných za tělem zprávy.
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žije přijatou IP adresu, aniž by čekal na vyřešení všech potenciálně dostupných cílových IPv4 a IPv6 adres.
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 v návaznosti na kroky publikovaných verzí Squid 5.2 a Squid 4.17 byly opraveny následující zranitelnosti:
- 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 chcete dozvědět více, můžete si podrobnosti prohlédnout na následujícím odkazu.