Po troch rokoch vývoja bola vydaná nová stabilná verzia proxy servera Squid s názvom 5.1, ktorá je pripravená na použitie v produkčných systémoch (verzie 5.0.x boli beta).
Po dosiahnutí stabilného stavu vetvy 5.x sa odteraz implementujú iba opravy zraniteľností a problémov so stabilitou spolu s menšími optimalizáciami. Vývoj nových funkcií bude prebiehať v novej experimentálnej vetve 6.0. Používateľom predchádzajúcej stabilnej vetvy 4.x sa odporúča naplánovať migráciu na vetvu 5.x.
Squid 5.1 Hlavné nové funkcie
V tejto novej verzii je kompatibilita s formátom Berkeley DB z dôvodu problémov s licenciami zastaraná . Vetva Berkeley DB 5.x nebola niekoľko rokov udržiavaná a stále má neopravené zraniteľnosti a aktualizácia na novšie verzie neumožňuje zmenu licencie AGPLv3, ktorej požiadavky sa vzťahujú aj na aplikácie, ktoré používajú Berkeley DB ako knižnicu. Squid je vydaný pod licenciou GPLv2 a AGPL nie je kompatibilný s GPLv2.
Namiesto Berkeley DB projekt prešiel na používanie DBMS TrivialDB, ktorá je na rozdiel od Berkeley DB optimalizovaná pre simultánny paralelný prístup k databáze. Podpora Berkeley DB je zatiaľ zachovaná, ale v obslužných rutinách „ext_session_acl“ a „ext_time_quota_acl“ sa teraz odporúča používať typ úložiska „libtdb“ namiesto „libdb“.
Okrem toho bola pridaná podpora pre hlavičku HTTP CDN-Loop definovanú v RFC 8586, ktorá umožňuje detekciu slučiek pri použití sietí na doručovanie obsahu (hlavička poskytuje ochranu pred situáciami, v ktorých sa požiadavka počas presmerovania medzi sieťami CDN z nejakého dôvodu vracia do pôvodnej CDN, tvoriacej nekonečnú slučku).
Mechanizmus SSL-Bump, ktorý umožňuje zachytávanie obsahu šifrovaných HTTPS relácií, navyše pridal podporu pre presmerovanie sfalšovaných HTTPS požiadaviek cez iné proxy servery uvedené v cache_peer pomocou bežného tunela založeného na metóde HTTP CONNECT (prenos cez HTTPS nie je podporovaný, pretože Squid zatiaľ nedokáže prenášať TLS v rámci TLS).
SSL-Bump po prijatí prvej zachytenej HTTPS požiadavky nadviaže TLS pripojenie s cieľovým serverom a získa jeho certifikát. Squid potom použije názov hostiteľa skutočného certifikátu prijatého zo servera na vytvorenie falošného certifikátu, ktorý použije na zosobnenie požadovaného servera pri interakcii s klientom , pričom naďalej používa nadviazané TLS pripojenie s cieľovým serverom na príjem údajov.
Za zmienku tiež stojí, že implementácia protokolu ICAP (Internet Content Adaptation Protocol), ktorý sa používa na integráciu s externými systémami overovania obsahu, pridala podporu pre mechanizmus pripájania údajov , ktorý umožňuje pripojiť k odpovedi ďalšie hlavičky metadát umiestnené za telom správy.
Namiesto zohľadnenia „dns_v4_first»Ak chcete určiť poradie použitia rodiny adries IPv4 alebo IPv6, teraz sa berie do úvahy poradie reakcie v DNS- Ak sa pri čakaní na vyriešenie adresy IP najskôr zobrazí odpoveď AAAA zo systému DNS, použije sa výsledná adresa IPv6. Preferované nastavenie rodiny adries sa preto teraz vykonáva vo bráne firewall, DNS alebo pri spustení pomocou možnosti „–disable-ipv6“.
Navrhovaná zmena urýchli čas konfigurácie pripojení TCP a zníži vplyv oneskorení v rozlíšení DNS na výkon.
Pri presmerovaní požiadaviek sa používa algoritmus „Happy Eyeballs“, ktorý okamžite použije prijatú IP adresu bez čakania na vyriešenie všetkých potenciálne dostupných cieľových IPv4 a IPv6 adries.
Na použitie v smernici „external_acl“ bol pridaný ovládač „ext_kerberos_sid_group_acl“ na autentifikáciu pomocou overovacích skupín v službe Active Directory pomocou systému Kerberos. Na zadanie dotazu na názov skupiny sa používa nástroj ldapsearch poskytovaný balíkom OpenLDAP.
Pridané direktívy mark_client_connection a mark_client_pack na viazanie značiek Netfilter (CONNMARK) na jednotlivé pakety alebo klientske pripojenia TCP
Na záver sa uvádza, že podľa krokov publikovaných verzií Squid 5.2 a Squid 4.17 boli opravené nasledujúce zraniteľnosti:
- CVE-2021-28116-Únik informácií pri spracovaní špeciálne vytvorených správ WCCPv2. Zraniteľnosť umožňuje útočníkovi poškodiť zoznam známych smerovačov WCCP a presmerovať prenos z proxy klienta na hostiteľa. Problém sa prejavuje iba v konfiguráciách s povolenou podporou WCCPv2 a vtedy, keď je možné sfalšovať IP adresu smerovača.
- CVE-2021-41611: chyba pri validácii certifikátov TLS, ktoré umožňujú prístup pomocou nedôveryhodných certifikátov.
Nakoniec, ak sa chcete dozvedieť viac, podrobnosti si môžete pozrieť na nasledujúcom odkaze.