Après trois années de développement, une version stable du serveur proxy Squid 5.1 a été présentée, prête à être utilisée sur les systèmes de production (les versions 5.0.x avaient le statut de versions bêta). Une fois que la branche 5.x a obtenu le statut stable, seules les corrections de vulnérabilités et de problèmes de stabilité y seront désormais apportées, et des optimisations mineures sont également autorisées. Le développement de nouvelles fonctionnalités sera réalisé dans la nouvelle branche expérimentale 6.0. Il est conseillé aux utilisateurs de la branche stable 4.x précédente de prévoir de migrer vers la branche 5.x.
Principales innovations de Squid 5 :
- La mise en œuvre du protocole ICAP (Internet Content Adaptation Protocol), utilisé pour l'intégration avec des systèmes de vérification de contenu externes, a ajouté la prise en charge d'un mécanisme de pièce jointe de données (bande-annonce), qui vous permet d'attacher des en-têtes supplémentaires avec des métadonnées à la réponse, placés après le message. corps (par exemple, vous pouvez envoyer une somme de contrôle et des détails sur les problèmes identifiés).
- Lors de la redirection des demandes, l'algorithme « Happy Eyeballs » est utilisé, qui utilise immédiatement l'adresse IP reçue, sans attendre que toutes les adresses cibles IPv4 et IPv6 potentiellement disponibles soient résolues. Au lieu d'utiliser le paramètre "dns_v4_first" pour déterminer si une famille d'adresses IPv4 ou IPv6 est utilisée, l'ordre de la réponse DNS est désormais pris en compte : si la réponse DNS AAAA arrive en premier lors de l'attente de la résolution d'une adresse IP, alors le L’adresse IPv6 résultante sera utilisée. Ainsi, le paramétrage de la famille d'adresses préférée se fait désormais au niveau du pare-feu, du DNS ou du démarrage avec l'option « --disable-ipv6 ». Le changement proposé nous permet d'accélérer le temps d'établissement des connexions TCP et de réduire l'impact sur les performances des retards lors de la résolution DNS.
- Pour être utilisé dans la directive "external_acl", le gestionnaire "ext_kerberos_sid_group_acl" a été ajouté pour l'authentification avec vérification de groupe dans Active Directory à l'aide de Kerberos. Pour interroger le nom du groupe, utilisez l'utilitaire ldapsearch fourni par le package OpenLDAP.
- La prise en charge du format Berkeley DB est obsolète en raison de problèmes de licence. La branche Berkeley DB 5.x n'a pas été maintenue depuis plusieurs années et reste avec des vulnérabilités non corrigées, et la transition vers des versions plus récentes est empêchée par un changement de licence vers AGPLv3, dont les exigences s'appliquent également aux applications qui utilisent BerkeleyDB sous la forme de une bibliothèque - Squid est fourni sous licence GPLv2 et AGPL n'est pas compatible avec GPLv2. Au lieu de Berkeley DB, le projet a été transféré vers l'utilisation du SGBD TrivialDB, qui, contrairement à Berkeley DB, est optimisé pour un accès parallèle simultané à la base de données. La prise en charge de Berkeley DB est conservée pour l'instant, mais les gestionnaires "ext_session_acl" et "ext_time_quota_acl" recommandent désormais d'utiliser le type de stockage "libtdb" au lieu de "libdb".
- Ajout de la prise en charge de l'en-tête HTTP CDN-Loop, défini dans la RFC 8586, qui vous permet de détecter les boucles lors de l'utilisation de réseaux de diffusion de contenu (l'en-tête offre une protection contre les situations où une requête en cours de redirection entre CDN pour une raison quelconque revient au CDN original, formant une boucle sans fin).
- Le mécanisme SSL-Bump, qui vous permet d'intercepter le contenu des sessions HTTPS chiffrées, a ajouté la prise en charge de la redirection des requêtes HTTPS usurpées (rechiffrées) via d'autres serveurs proxy spécifiés dans cache_peer, en utilisant un tunnel régulier basé sur la méthode HTTP CONNECT ( la transmission via HTTPS n'est pas prise en charge, car Squid ne peut pas encore transporter TLS au sein de TLS). SSL-Bump permet d'établir une connexion TLS avec le serveur cible dès réception de la première requête HTTPS interceptée et d'obtenir son certificat. Après cela, Squid utilise le nom d'hôte du vrai certificat reçu du serveur et crée un certificat factice, avec lequel il imite le serveur demandé lors de l'interaction avec le client, tout en continuant à utiliser la connexion TLS établie avec le serveur cible pour recevoir des données ( afin que la substitution n'entraîne pas d'avertissements de sortie dans les navigateurs côté client, vous devez ajouter votre certificat utilisé pour générer des certificats fictifs au magasin de certificats racine).
- Ajout des directives mark_client_connection et mark_client_pack pour lier les marques Netfilter (CONNMARK) aux connexions TCP client ou aux paquets individuels.
Dans la foulée, les versions de Squid 5.2 et Squid 4.17 ont été publiées, dans lesquelles les vulnérabilités ont été corrigées :
- CVE-2021-28116 – Fuite d’informations lors du traitement de messages WCCPv2 spécialement conçus. Cette vulnérabilité permet à un attaquant de corrompre la liste des routeurs WCCP connus et de rediriger le trafic des clients du serveur proxy vers leur hôte. Le problème n'apparaît que dans les configurations avec la prise en charge WCCPv2 activée et lorsqu'il est possible d'usurper l'adresse IP du routeur.
- CVE-2021-41611 - Un problème dans la vérification des certificats TLS permet l'accès à l'aide de certificats non fiables.
Source: opennet.ru