Alliberament estable del servidor intermediari Squid 5

Després de tres anys de desenvolupament, es presenta una versió estable del servidor intermediari Squid 5.1, llesta per al seu ús en sistemes de producció (les versions 5.0.x tenien l'estat de versions beta). Després d'establir la branca 5.x, ara només solucionarà vulnerabilitats i problemes d'estabilitat, i també es permeten optimitzacions menors. El desenvolupament de noves funcionalitats es durà a terme en una nova branca experimental 6.0. Es recomana als usuaris de l'última branca estable 4.x que planifiquen la migració a la branca 5.x.

Principals innovacions de Squid 5:

  • La implementació del protocol ICAP (Internet Content Adaptation Protocol), utilitzat per a la integració amb sistemes d'inspecció de contingut externs, ha afegit suport per al mecanisme d'adjunció de dades (tráiler), que permet adjuntar capçaleres addicionals amb metadades col·locades després del cos del missatge al resposta (per exemple, podeu enviar una suma de comprovació i detalls dels problemes identificats).
  • En redirigir les sol·licituds, s'utilitza l'algoritme "Happy Eyeballs", que utilitza immediatament l'adreça IP rebuda, sense esperar a la resolució de totes les adreces de destinació IPv4 i IPv6 potencialment disponibles. En lloc de respectar la configuració "dns_v4_first" per determinar l'ordre en què s'utilitza una família d'adreces IPv4 o IPv6, ara es respecta l'ordre de resposta del DNS: si una resposta DNS AAAA arriba primer mentre s'espera que es resolgui una adreça IP, aleshores el rebut. S'utilitzarà l'adreça IPv6. Així, la configuració de la família d'adreces preferida ara es fa al tallafoc, DNS o nivell d'inici amb l'opció "--disable-ipv6". El canvi proposat accelera el temps de configuració de la connexió TCP i redueix l'impacte en el rendiment de la latència de resolució de DNS.
  • Per utilitzar-lo a la directiva "external_acl", s'ha afegit el controlador "ext_kerberos_sid_group_acl" per a l'autenticació amb verificació de grup a Active Directory mitjançant Kerberos. Per consultar el nom del grup, utilitzeu la utilitat ldapsearch proporcionada pel paquet OpenLDAP.
  • El suport per al format Berkeley DB ha quedat obsolet a causa de problemes de llicència. La branca Berkeley DB 5.x no s'ha mantingut durant uns quants anys i continua amb vulnerabilitats sense pegats, i canviar a versions més noves no permet canviar la llicència a AGPLv3, els requisits de la qual també s'apliquen a les aplicacions que utilitzen BerkeleyDB en forma de biblioteca - Squid té llicència sota la GPLv2 i AGPL és incompatible amb GPLv2. En lloc de Berkeley DB, el projecte es va canviar a utilitzar el DBMS TrivialDB, que, a diferència de Berkeley DB, està optimitzat per a l'accés paral·lel simultani a la base de dades. De moment s'ha mantingut el suport de Berkeley DB, però ara es recomana als controladors "ext_session_acl" i "ext_time_quota_acl" utilitzar el tipus d'emmagatzematge "libtdb" en comptes de "libdb".
  • S'ha afegit suport per a la capçalera HTTP CDN-Loop, definida a RFC 8586, que permet detectar bucles quan s'utilitzen xarxes de lliurament de contingut (la capçalera proporciona protecció contra situacions en què una sol·licitud en procés de redirecció entre CDN per algun motiu torna a la CDN original, formant un bucle infinit).
  • S'ha afegit suport per a la redirecció de sol·licituds HTTPS falsificades (rexifrades) a través d'altres servidors proxy especificats a cache_peer mitjançant un túnel normal basat en el mètode HTTP CONNECT al mecanisme SSL-Bump, que permet organitzar la intercepció del contingut de les sessions HTTPS xifrades (transmissió). sobre HTTPS no és compatible ja que Squid encara no pot passar TLS dins de TLS). SSL-Bump permet, després de rebre la primera sol·licitud HTTPS interceptada, establir una connexió TLS amb el servidor de destinació i obtenir el seu certificat. Després d'això, Squid utilitza el nom d'amfitrió del certificat real rebut del servidor i crea un certificat fictici amb el qual imita el servidor sol·licitat quan interactua amb el client, alhora que continua utilitzant la connexió TLS establerta amb el servidor de destinació per rebre dades (per tant que la substitució no condueixi als avisos de sortida als navegadors del costat del client, heu d'afegir el vostre certificat utilitzat per generar certificats simulats al magatzem de certificats arrel).
  • S'han afegit les directives mark_client_connection i mark_client_pack per vincular les marques de Netfilter (CONNMARK) a connexions TCP de client o paquets individuals.

Després de la persecució, es van publicar les versions de Squid 5.2 i Squid 4.17 en què es van solucionar les vulnerabilitats següents:

  • CVE-2021-28116: informació filtrada durant el processament de missatges elaborats amb WCCPv2. La vulnerabilitat permet a un atacant corrompre la llista d'encaminadors WCCP coneguts i redirigir el trànsit del client intermediari al seu amfitrió. El problema només apareix en configuracions amb el suport WCCPv2 activat i quan és possible falsificar l'adreça IP de l'encaminador.
  • CVE-2021-41611: error de validació del certificat TLS que permet l'accés amb certificats que no són de confiança.

Font: opennet.ru

Afegeix comentari