Po třech letech vývoje byl představen stabilní release proxy serveru Squid 5.1, připravený k použití v pracovních systémech (verze 5.0.x měly status beta verzí). Po přiznání větvi 5.x statusu stabilní budou v ní prováděny pouze opravy zranitelností a stabilitních problémů, také budou povoleny drobné optimalizace. 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 přechod na větev 5.x.
Hlavní novinky Squid 5:
- Do implementace protokolu ICAP (Internet Content Adaptation Protocol), používajícího se pro integraci s externími systémy pro kontrolu obsahu, byla přidána podpora mechanismu připojení dat (trailer), který umožňuje připojit k odpovědi další hlavičky s metadaty umístěnými po těle zprávy (například lze předat kontrolní součet a detaily o zjištěných problémech).
- Při přesměrování požadavků je využíván algoritmus „Happy Eyeballs“, který okamžitě používá získanou IP adresu, aniž by čekal na vyřešení všech potenciálně dostupných cílových adres IPv4 a IPv6. Místo zohlednění nastavení „dns_v4_first“ pro určení pořadí používání rodiny adres IPv4 nebo IPv6 se nyní bere v úvahu pořadí odpovědi v DNS: pokud při čekání na vyřešení IP adres jako první dorazí odpověď DNS AAAA, bude použita získaná adresa IPv6. Takže nastavení preferované rodiny adres se nyní provádí na úrovni firewallu, DNS nebo spuštění s volbou „—disable-ipv6“. Navrhovaná změna umožňuje zrychlit čas navázání TCP spojení a snížit vliv na výkon zpoždění při vyřešení v DNS.
- Pro použití v direktivě „external_acl“ byl přidán zpracovatel „ext_kerberos_sid_group_acl“ pro autentizaci s kontrolou skupin v Active Directory pomocí Kerberosu. Pro dotaz na jméno skupiny se používá utilita ldapsearch, poskytovaná balíkem OpenLDAP.
- Podpora formátu DB Berkeley DB byla prohlášena za zastaralou kvůli licenčním problémům. Větev Berkeley DB 5.x již několik let není udržována a zůstává s neopravenými zranitelnostmi, a přechod na novější verze neumožňuje změna licence na AGPLv3, jejíž požadavky se vztahují i na aplikace, které používají BerkeleyDB ve formě knihovny — Squid je dodáván pod licencí GPLv2, a AGPL není kompatibilní s GPLv2. Místo Berkeley DB byl projekt převeden na použití DB TrivialDB, která, na rozdíl od Berkeley DB, je optimalizována pro současný paralelní přístup k databázi. Podpora Berkeley DB zatím zůstává zachována, ale v obsluhovačích „ext_session_acl“ a „ext_time_quota_acl“ se nyní doporučuje používat typ úložiště „libtdb“ namísto „libdb“.
- Byla přidána podpora HTTP hlavičky CDN-Loop, definované v RFC 8586, která umožňuje odhalit smyčky při používání sítí pro doručování obsahu (hlavička poskytuje ochranu před situacemi, kdy se požadavek během přesměrování mezi CDN z nějakého důvodu vrací zpět do původní CDN, což vytváří nekonečnou smyčku).
- Do mechanizmu SSL-Bump, který umožňuje organizaci zachycení obsahu šifrovaných HTTPS sezení, byla přidána podpora přesměrování pozměněných (znovu zašifrovaných) HTTPS požadavků přes jiné proxy servery uvedené v cache_peer, pomocí běžného tunelu na základě metody HTTP CONNECT (přenos přes HTTPS není podporován, protože Squid zatím nemůže přenášet TLS uvnitř TLS). SSL-Bump umožňuje při příjmu prvního zachyceného požadavku HTTPS navázat TLS spojení s cílovým serverem a získat jeho certifikát. Poté Squid používá jméno hostitele z reálně obdrženého certifikátu serveru a vytváří fiktivní certifikát, pomocí nějž imituje požadovaný server při interakci se zákazníkem, přičemž nadále využívá pro získání dat TLS spojení vytvořené s cílovým serverem (aby změna nezpůsobovala varování v prohlížečích na straně klienta, je třeba do úložiště kořenových certifikátů přidat svůj certifikát používaný pro generování fiktivních certifikátů).
- Byly přidány direktivy mark_client_connection a mark_client_pack pro přiřazení značek Netfilter (CONNMARK) k klientským TCP připojením nebo jednotlivým paketům.
Následně byly zveřejněny verze Squid 5.2 a Squid 4.17, které opravují zranitelnosti:
- CVE-2021-28116 — únik informací při zpracování speciálně formátovaných zpráv WCCPv2. Zranitelnost umožňuje útočníkovi poškodit seznam známých směrovačů WCCP a přesměrovat provoz klientů proxy serveru na svůj host. Problém se projevuje pouze v konfiguracích s povolenou podporou WCCPv2 a při možnosti spoofování IP adresy směrovače.
- CVE-2021-41611 — chyba při ověřování TLS certifikátů, která umožňuje přístup s použitím certifikátů, kterým nelze důvěřovat.
Zdroj: opennet.ru
