Dopo tre anni di sviluppo, è stata presentata la versione stabile del server proxy Squid 5.1, pronta per l'uso nei sistemi di produzione (le versioni 5.0.x avevano lo stato di beta). Una volta conferito lo stato stabile al ramo 5.x, ora verranno effettuate solo correzioni di vulnerabilità e problemi di stabilità, oltre a possibili piccole ottimizzazioni. Sviluppi di nuove funzionalità saranno effettuati nel nuovo ramo sperimentale 6.0. Si consiglia agli utenti del precedente ramo stabile 4.x di pianificare la migrazione al ramo 5.x.
Novità principali di Squid 5:
- Nell'implementazione del protocollo ICAP (Internet Content Adaptation Protocol), utilizzato per l'integrazione con sistemi esterni di verifica dei contenuti, è stata aggiunta la supporto per il meccanismo di allegato dei dati (trailer), che consente di allegare alla risposta intestazioni aggiuntive con metadata, posizionate dopo il corpo del messaggio (ad esempio, è possibile trasmettere un checksum e dettagli sui problemi riscontrati).
- Nel reindirizzamento delle richieste è stato utilizzato l'algoritmo "Happy Eyeballs", che utilizza immediatamente l'indirizzo IP ricevuto, senza aspettare la risoluzione di tutti gli indirizzi di destinazione IPv4 e IPv6 disponibili. Invece di considerare l'impostazione "dns_v4_first" per determinare l'ordine di utilizzo della famiglia di indirizzi IPv4 o IPv6, ora viene considerato l'ordine della risposta DNS: se durante l'attesa per la risoluzione Indirizzi IP arriva per prima la risposta DNS AAAA, verrà utilizzato l'indirizzo IPv6 ricevuto. In questo modo, l'impostazione della famiglia di indirizzi preferita ora avviene a livello di firewall, DNS o esecuzione con l'opzione "—disable-ipv6". Questa modifica proposta consente di accelerare il tempo di stabilizzazione delle connessioni TCP e ridurre l'impatto sulle prestazioni causato dai ritardi nella risoluzione DNS.
- Per l'uso nella direttiva "external_acl" è stato aggiunto il gestore "ext_kerberos_sid_group_acl" per l'autenticazione con verifica dei gruppi in Active Directory tramite Kerberos. Per la richiesta del nome del gruppo viene utilizzato lo strumento ldapsearch, fornito dal pacchetto OpenLDAP.
- Il supporto del formato del database Berkeley DB è stato dichiarato obsoleto a causa di problemi di licenza. Il ramo Berkeley DB 5.x non viene più mantenuto da diversi anni e presenta vulnerabilità non corrette, mentre la transizione a versioni più recenti è impedita dalla modifica della licenza in AGPLv3, le cui condizioni si applicano anche alle applicazioni che utilizzano BerkeleyDB come libreria — Squid è distribuito sotto 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 concorrente ai database. Il supporto per Berkeley DB è ancora mantenuto, 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 in RFC 8586, che consente di rilevare i cicli durante l'uso delle reti di distribuzione dei contenuti (l'intestazione fornisce protezione contro situazioni in cui una richiesta, durante il processo di reindirizzamento tra CDN, ritorna per qualche motivo alla CDN di origine, creando un ciclo infinito).
- Nel meccanismo SSL-Bump, che consente di intercettare il contenuto delle sessioni HTTPS crittografate, è stato aggiunto il supporto per il reindirizzamento delle richieste HTTPS modificate (ri-cifrato) attraverso altri server proxy specificati in cache_peer, utilizzando un tunnel normale basato sul metodo HTTP CONNECT (il passaggio tramite HTTPS non è supportato, poiché Squid non può ancora trasmettere TLS all'interno di TLS). SSL-Bump consente, al momento dell'arrivo della prima richiesta HTTPS intercettata, di stabilire una connessione TLS con il server di destinazione e ottenere il suo certificato. Dopo di ciò, Squid utilizza il nome host dal certificato reale ricevuto dal server e crea un certificato fittizio, utilizzato per simulare il server richiesto durante l'interazione con il cliente, continuando a utilizzare per la raccolta dei dati la connessione TLS stabilita con il server di destinazione (per evitare che la sostituzione generi avvisi nei browser lato client, è necessario aggiungere al deposito dei certificati radice il proprio certificato utilizzato per generare certificati fittizi).
- Aggiunte le direttive mark_client_connection e mark_client_pack per associare etichette Netfilter (CONNMARK) alle connessioni TCP client o a singoli pacchetti.
Sono stati pubblicati i rilasci di Squid 5.2 e Squid 4.17 per correggere le vulnerabilità:
- CVE-2021-28116 — fuga di informazioni durante l'elaborazione di messaggi formattati in modo specifico WCCPv2. Questa vulnerabilità consente all'attaccante di compromettere l'elenco dei router WCCP conosciuti e di reindirizzare il traffico dei client del server proxy al proprio host. Il problema si manifesta solo in configurazioni con il supporto WCCPv2 attivato e con la possibilità di eseguire spoofing dell'indirizzo IP del router.
- CVE-2021-41611 — errore nella verifica di certificati TLS, che consente l'accesso utilizzando certificati non attendibili.
Fonte: opennet.ru
