Dopo tre anni di sviluppo è stata presentata una release stabile del server proxy Squid 5.1, pronta per l'utilizzo sui sistemi di produzione (le release 5.0.x avevano lo status di versioni beta). Dopo che al ramo 5.x sarà stato assegnato lo stato stabile, d'ora in poi verranno apportate solo correzioni per vulnerabilità e problemi di stabilità e saranno consentite anche piccole ottimizzazioni. Lo sviluppo di nuove funzionalità verrà effettuato nel nuovo ramo sperimentale 6.0. Si consiglia agli utenti del precedente ramo stabile 4.x di pianificare la migrazione al ramo 5.x.
Principali innovazioni in Squid 5:
- L'implementazione dell'ICAP (Internet Content Adaptation Protocol), utilizzato per l'integrazione con sistemi esterni di verifica dei contenuti, ha aggiunto il supporto per un meccanismo di allegato dati (trailer), che consente di allegare alla risposta ulteriori intestazioni con metadati, poste dopo il messaggio corpo (ad esempio, è possibile inviare un checksum e dettagli sui problemi identificati).
- Quando si reindirizzano le richieste, viene utilizzato l'algoritmo "Happy Eyeballs", che utilizza immediatamente l'indirizzo IP ricevuto, senza attendere che tutti gli indirizzi di destinazione IPv4 e IPv6 potenzialmente disponibili vengano risolti. Invece di utilizzare l'impostazione "dns_v4_first" per determinare se viene utilizzata una famiglia di indirizzi IPv4 o IPv6, viene ora preso in considerazione l'ordine della risposta DNS: se la risposta DNS AAAA arriva per prima mentre si attende la risoluzione di un indirizzo IP, allora verrà utilizzato l'indirizzo IPv6 risultante. Pertanto, l'impostazione della famiglia di indirizzi preferita viene ora eseguita a livello di firewall, DNS o avvio con l'opzione "--disable-ipv6". La modifica proposta ci consente di accelerare i tempi di configurazione delle connessioni TCP e di ridurre l'impatto sulle prestazioni dei ritardi durante la risoluzione DNS.
- Per l'utilizzo nella direttiva "external_acl", è stato aggiunto il gestore "ext_kerberos_sid_group_acl" per l'autenticazione con il controllo del gruppo in Active Directory utilizzando Kerberos. Per interrogare il nome del gruppo, utilizzare l'utilità ldapsearch fornita dal pacchetto OpenLDAP.
- Il supporto per il formato Berkeley DB è stato deprecato a causa di problemi di licenza. Il ramo Berkeley DB 5.x non è stato mantenuto per diversi anni e presenta ancora vulnerabilità senza patch, e il passaggio a versioni più recenti è impedito da una modifica della licenza ad AGPLv3, i cui requisiti si applicano anche alle applicazioni che utilizzano BerkeleyDB sotto forma di una libreria: Squid è fornito con licenza GPLv2 e AGPL non è compatibile con GPLv2. Invece di Berkeley DB, il progetto è stato trasferito all'uso del DBMS TrivialDB, che, a differenza di Berkeley DB, è ottimizzato per l'accesso parallelo simultaneo al database. Per il momento il supporto Berkeley DB viene mantenuto, ma i gestori "ext_session_acl" e "ext_time_quota_acl" ora consigliano di utilizzare il tipo di archiviazione "libtdb" invece di "libdb".
- Aggiunto il supporto per l'intestazione HTTP CDN-Loop, definita nella RFC 8586, che consente di rilevare loop quando si utilizzano reti di distribuzione dei contenuti (l'intestazione fornisce protezione contro le situazioni in cui una richiesta nel processo di reindirizzamento tra CDN per qualche motivo ritorna all'intestazione CDN originale, formando un ciclo infinito).
- Il meccanismo SSL-Bump, che consente di intercettare il contenuto delle sessioni HTTPS crittografate, ha aggiunto il supporto per reindirizzare le richieste HTTPS spoofate (ricrittografate) attraverso altri server proxy specificati in cache_peer, utilizzando un tunnel regolare basato sul metodo HTTP CONNECT ( la trasmissione tramite HTTPS non è supportata poiché Squid non può ancora trasportare TLS all'interno di TLS). SSL-Bump consente di stabilire una connessione TLS con il server di destinazione al ricevimento della prima richiesta HTTPS intercettata e di ottenerne il certificato. Successivamente, Squid utilizza il nome host del certificato reale ricevuto dal server e crea un certificato fittizio, con il quale imita il server richiesto quando interagisce con il client, pur continuando a utilizzare la connessione TLS stabilita con il server di destinazione per ricevere dati ( affinché la sostituzione non porti agli avvisi di output nei browser sul lato client, è necessario aggiungere il certificato utilizzato per generare certificati fittizi all'archivio dei certificati radice).
- Aggiunte le direttive mark_client_connection e mark_client_pack per associare i contrassegni Netfilter (CONNMARK) alle connessioni TCP del client o ai singoli pacchetti.
Subito dopo sono state pubblicate le versioni Squid 5.2 e Squid 4.17, nelle quali sono state corrette le vulnerabilità:
- CVE-2021-28116: perdita di informazioni durante l'elaborazione di messaggi WCCPv2 appositamente predisposti. La vulnerabilità consente a un utente malintenzionato di corrompere l'elenco dei router WCCP noti e reindirizzare il traffico dai client del server proxy al relativo host. Il problema si presenta solo nelle configurazioni con supporto WCCPv2 abilitato e quando è possibile effettuare lo spoofing dell'indirizzo IP del router.
- CVE-2021-41611 - Un problema nella verifica del certificato TLS consente l'accesso utilizzando certificati non attendibili.
Fonte: opennet.ru