Sortie de la version stable du serveur proxy Squid 5

Après trois ans de développement, la version stable du serveur proxy Squid 5.1 est maintenant disponible pour une utilisation dans des systèmes de production (les versions 5.0.x avaient le statut de versions bêta). Avec le passage de la branche 5.x au statut stable, seules des corrections de vulnérabilités et de problèmes de stabilité seront désormais effectuées, ainsi que de petites optimisations. Le développement de nouvelles fonctionnalités se fera dans une nouvelle branche expérimentale 6.0. Il est recommandé aux utilisateurs de l'ancienne branche stable 4.x de planifier leur transition vers la branche 5.x.

Les principales nouveautés de Squid 5 :

• Le protocole ICAP (Internet Content Adaptation Protocol), utilisé pour l'intégration avec des systèmes externes de vérification de contenu, a été enrichi d'une prise en charge du mécanisme de données jointes (trailer), permettant d'attacher des en-têtes supplémentaires avec des métadonnées au sein de la réponse, placées après le corps du message (par exemple, il est possible de transmettre un contrôle de somme et des détails sur les problèmes détectés).
• Lors de la redirection des requêtes, l'algorithme « Happy Eyeballs » est utilisé, qui emploie immédiatement l'adresse IP reçue sans attendre la résolution de toutes les adresses cibles IPv4 et IPv6 potentiellement accessibles. Au lieu de prendre en compte le paramètre « dns_v4_first » pour déterminer l'ordre d'utilisation des adresses IPv4 ou IPv6, c'est maintenant l'ordre des réponses DNS qui est pris en compte : si une réponse DNS AAAA arrive en premier, l'adresse IPv6 obtenue sera utilisée. adresses IP Ainsi, la configuration de la famille d'adresses préférée s'effectue désormais au niveau du pare-feu, du DNS ou en lançant l'option « --disable-ipv6 ». Ce changement proposé permet d'accélérer le temps d'établissement des connexions TCP et de réduire l'impact des retards dus à la résolution DNS sur les performances.
• Pour utilisation dans la directive « external_acl », le gestionnaire « ext_kerberos_sid_group_acl » a été ajouté pour l'authentification avec vérification des groupes dans Active Directory via Kerberos. Pour demander le nom d'un groupe, l'outil ldapsearch, fourni par le paquet OpenLDAP, est utilisé.
• Le support du format de base de données Berkeley DB a été déclaré obsolète en raison de problèmes de licence. La branche Berkeley DB 5.x n'est plus maintenue depuis plusieurs années et présente des vulnérabilités non corrigées. De plus, le passage à des versions plus récentes est entravé par le changement de licence vers l'AGPLv3, dont les exigences s'appliquent également aux applications utilisant BerkeleyDB sous forme de bibliothèque. Squid est distribué sous licence GPLv2, et l'AGPL n'est pas compatible avec la GPLv2. Au lieu de Berkeley DB, le projet a été transféré à l'utilisation de la base de données TrivialDB, qui, contrairement à Berkeley DB, est optimisée pour un accès concurrent à la base de données. Le support de Berkeley DB est encore maintenu, mais dans les gestionnaires « ext_session_acl » et « ext_time_quota_acl », il est désormais recommandé d'utiliser le type de stockage « libtdb » au lieu de « libdb ».
• Un support a été ajouté pour l'en-tête HTTP CDN-Loop, défini dans la RFC 8586, permettant de détecter les boucles lors de l'utilisation de réseaux de distribution de contenu (cet en-tête protège contre les situations où une requête, au cours du processus de redirection entre les CDN, retourne pour une raison quelconque vers le CDN d'origine, créant ainsi une boucle infinie).
• Le mécanisme SSL-Bump, qui permet de capturer le contenu des sessions HTTPS chiffrées, a été amélioré avec le support de la redirection des requêtes HTTPS altérées (réchiffrées) à travers d'autres serveurs proxy spécifiés dans cache_peer, en utilisant un tunnel standard basé sur la méthode HTTP CONNECT (le passage par HTTPS n'est pas pris en charge, car Squid ne peut pas encore transmettre le TLS à l'intérieur du TLS). SSL-Bump permet, à la réception de la première requête HTTPS interceptée, d'établir une connexion TLS avec le serveur cible et d'obtenir son certificat. Ensuite, Squid utilise le nom d'hôte provenant du certificat reçu du serveur et crée un certificat fictif, avec lequel il imite le serveur demandé lors de l'interaction avec le client, tout en continuant à utiliser pour obtenir des données la connexion TLS établie avec le serveur cible (pour éviter que le remplacement n'entraîne des avertissements dans les navigateurs côté client, il faut ajouter le certificat racine utilisé pour générer les certificats fictifs dans le magasin des certificats racines).
• Des directives mark_client_connection et mark_client_pack ont été ajoutées pour associer des étiquettes Netfilter (CONNMARK) aux connexions TCP des clients ou à des paquets individuels.

Les nouvelles versions de Squid 5.2 et Squid 4.17 ont été publiées, corrigeant des vulnérabilités :

• CVE-2021-28116 — fuite d'informations lors du traitement de messages spécialement formatés WCCPv2. 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 son propre hôte. Le problème se manifeste uniquement dans les configurations avec le support WCCPv2 activé et la possibilité de spoofing de l'adresse IP du routeur.
• CVE-2021-41611 — erreur lors de la vérification des certificats TLS, permettant d'accéder à des certificats non fiables.

Source : opennet.ru