Dopo tre anni di sviluppo, è stata rilasciata la versione stabile del server proxy Squid 5.1, pronta per essere utilizzata nei sistemi operativi (le versioni 5.0.x avevano lo stato di beta). Dopo aver conferito alla linea 5.x lo stato di stabilità, verranno effettuate solo correzioni di vulnerabilità e problemi di stabilità, e saranno consentite anche piccole ottimizzazioni. Lo sviluppo di nuove funzionalità sarà condotto in una nuova linea sperimentale 6.0. Si consiglia agli utenti della precedente versione stabile 4.x di pianificare il passaggio alla linea 5.x.
Novità principali di Squid 5:
- Nell'implementazione del protocollo ICAP (Internet Content Adaptation Protocol), usato per integrare sistemi esterni di verifica dei contenuti, è stata aggiunta la supporto per il meccanismo di allegato dati (trailer), che consente di allegare intestazioni aggiuntive con metadati alla risposta, posizionate dopo il corpo del messaggio (ad esempio, è possibile trasmettere un checksum e dettagli su eventuali problemi rilevati).
- Quando si reindirizzano le richieste, viene utilizzato l'algoritmo "Happy Eyeballs", che utilizza immediatamente l'indirizzo IP ricevuto, senza attendere la risoluzione di tutti i potenziali indirizzi target IPv4 e IPv6. Invece di considerare l'impostazione "dns_v4_first" per determinare l'ordine di utilizzo delle famiglie di indirizzi IPv4 o IPv6, ora si tiene conto dell'ordine di risposta nel DNS: se durante l'attesa della risoluzione arriva prima una risposta DNS AAAA, verrà utilizzato l'indirizzo IPv6 ricevuto. Pertanto, l'impostazione della famiglia di indirizzi preferita ora viene eseguita a livello di firewall, DNS o avvio con l'opzione "--disable-ipv6". La modifica proposta consente di accelerare i tempi di instaurazione delle connessioni TCP e di ridurre l'impatto delle latenze durante la risoluzione nel DNS. Indirizzi IP Se arriva prima una risposta DNS AAAA, verrà utilizzato l'indirizzo IPv6 ricevuto. Pertanto, l'impostazione della famiglia di indirizzi preferita ora viene eseguita a livello di firewall, DNS o avvio con l'opzione "--disable-ipv6". La modifica proposta consente di accelerare i tempi di instaurazione delle connessioni TCP e di ridurre l'impatto delle latenze durante la risoluzione nel DNS.
- È stato aggiunto il gestore "ext_kerberos_sid_group_acl" per l'autenticazione con verifica dei gruppi in Active Directory mediante Kerberos da utilizzare nella direttiva "external_acl". Per richiedere il nome del gruppo viene utilizzata l'utilità ldapsearch fornita dal pacchetto OpenLDAP.
- Il supporto per il formato del database Berkeley DB è considerato obsoleto a causa di problemi di licenza. Il ramo Berkeley DB 5.x non è stato mantenuto per diversi anni e presenta vulnerabilità irrisolte; la transizione a versioni più recenti è impedita dalla modifica della licenza a AGPLv3, i cui requisiti si applicano anche alle applicazioni che utilizzano BerkeleyDB in forma di libreria. Squid è fornito sotto licenza GPLv2, e AGPL non è compatibile con GPLv2. Invece di Berkeley DB, il progetto è stato spostato sull'uso del DBMS TrivialDB, che, a differenza di Berkeley DB, è ottimizzato per l'accesso parallelo simultaneo al database. Il supporto per Berkeley DB è ancora disponibile, ma nei gestori «ext_session_acl» e «ext_time_quota_acl» ora si raccomanda di utilizzare il tipo di archiviazione «libtdb» invece di «libdb».
- Aggiunto il supporto per l'intestazione HTTP CDN-Loop, definita nel RFC 8586, che consente di rilevare cicli durante l'uso di reti di distribuzione dei contenuti (l'intestazione fornisce protezione contro situazioni in cui una richiesta, durante la ridirezione tra CDN, per qualche motivo torna alla CDN originale, creando un ciclo infinito).
- Nel meccanismo SSL-Bump, che consente l'intercettazione del contenuto delle sessioni HTTPS crittografate, è stata aggiunta la supporto per reindirizzare le richieste HTTPS modificate (ricrittografate) attraverso altri server proxy, come specificato in cache_peer, utilizzando un tunnel standard basato sul metodo HTTP CONNECT (la trasmissione tramite HTTPS non è supportata, poiché Squid non può ancora trasferire TLS all'interno di TLS). SSL-Bump consente, all'arrivo della prima richiesta HTTPS intercettata, di stabilire una connessione TLS con il server di destinazione e di ottenere il suo certificato. Successivamente, Squid utilizza il nome host dal certificato reale ricevuto dal server e crea un certificato falso, mediante il quale simula il server richiesto durante l'interazione con il cliente, continuando a utilizzare per l'acquisizione dei dati la connessione TLS stabilita con il server di destinazione (per evitare che la sostituzione faccia apparire avvisi nei browser lato cliente, è necessario aggiungere il proprio certificato, utilizzato per generare certificati falsi, al negozio di certificati radice).
- Sono state aggiunte le direttive mark_client_connection e mark_client_pack per l'associazione di etichette Netfilter (CONNMARK) alle connessioni TCP dei client o ai singoli pacchetti.
A seguire, sono state pubblicate le versioni di Squid 5.2 e Squid 4.17 in cui sono state corrette le vulnerabilità:
- CVE-2021-28116 — fuga di informazioni durante l'elaborazione di messaggi WCCPv2 appositamente formattati. Questa vulnerabilità consente a un aggressore di compromettere l'elenco dei router WCCP conosciuti e reindirizzare il traffico dei client del server proxy verso il proprio host. Il problema si manifesta solo nelle configurazioni con il supporto WCCPv2 attivato e con la possibilità di spoofing dell'indirizzo IP del router.
- CVE-2021-41611 — errore nella verifica certificati TLS., che consente l'accesso utilizzando certificati non affidabili.
Fonte: opennet.ru
