Squid 5.1 llega después de tres años de desarrollo y estas son sus novedades

Después de tres años de desarrollo se ha presentado la liberación de la nueva versión estable del servidor proxy Squid 5.1 la cual esta lista para su uso en sistemas de producción (las versiones 5.0.x eran beta).

Después de hacer que la rama 5.x tenga un estado estable, a partir de ahora, solo se realizarán arreglos para vulnerabilidades y problemas de estabilidad, y también se permitirán optimizaciones menores. El desarrollo de nuevas funciones se realizará en la nueva rama experimental 6.0. Se anima a los usuarios de la rama estable 4.x anterior a planificar una migración a la rama 5.x.

Principales novedades de Squid 5.1

En esta nueva versión la compatibilidad con el formato Berkeley DB ha quedado obsoleta debido a problemas de licencia. La rama Berkeley DB 5.x no se ha administrado durante varios años y sigue teniendo vulnerabilidades sin parches, y la actualización a versiones más recientes no permite cambiar la licencia de AGPLv3, cuyos requisitos también se aplican a las aplicaciones que utilizan BerkeleyDB en forma de biblioteca. – Squid se publica bajo la licencia GPLv2 y AGPL es incompatible con GPLv2.

En lugar de Berkeley DB, el proyecto se transfirió para utilizar TrivialDB DBMS, que, a diferencia de Berkeley DB, está optimizado para el acceso paralelo simultáneo a la base de datos. El soporte de Berkeley DB se mantiene por ahora, pero ahora se recomienda usar el tipo de almacenamiento «libtdb» en lugar de «libdb» en los controladores «ext_session_acl» y «ext_time_quota_acl».

Además se agregó soporte para el encabezado HTTP CDN-Loop, definido en RFC 8586, que permite detectar bucles cuando se utilizan redes de entrega de contenido (el encabezado brinda protección contra situaciones en las que una solicitud, durante la redirección entre CDN por alguna razón, regresa a la CDN original, formando un bucle infinito).

Por otra parte, el mecanismo SSL-Bump, que permite interceptar el contenido de sesiones HTTPS encriptadas, ha agregado soporte para redirigir solicitudes HTTPS falsificadas a través de otros servidores proxy especificados en cache_peer usando un túnel regular basado en el método HTTP CONNECT ( la transmisión a través de HTTPS no es compatible, ya que Squid aún no puede transmitir TLS dentro de TLS).

SSL-Bump permite, al llegar la primera solicitud HTTPS interceptada, establecer una conexión TLS con el servidor de destino y obtener su certificado. Posteriormente, Squid usa el nombre de host del certificado real recibido del servidor y crea un certificado falso, con el cual imita al servidor solicitado al interactuar con el cliente, mientras continúa usando la conexión TLS establecida con el servidor de destino para recibir datos.

También se destaca que la implementación del protocolo ICAP (Internet Content Adaptation Protocol), que se utiliza para la integración con sistemas de verificación de contenido externos, ha agregado soporte para el mecanismo de adjunto de datos que permite adjuntar encabezados de metadatos adicionales a la respuesta, colocados después del mensaje. body.

En lugar de tener en cuenta la configuración «dns_v4_first» para determinar el orden de uso de la familia de direcciones IPv4 o IPv6, ahora se tiene en cuenta el orden de la respuesta en DNS: si la respuesta AAAA de DNS aparece primero mientras se espera la resolución de un Dirección IP, se utilizará la dirección IPv6 resultante. Por lo tanto, la configuración de la familia de direcciones preferida ahora se realiza en el firewall, DNS o en el inicio con la opción «–disable-ipv6».
El cambio propuesto acelerará el tiempo de configuración de las conexiones TCP y reducirá el impacto en el rendimiento de los retrasos en la resolución de DNS.

Al redirigir las solicitudes, se utiliza el algoritmo «Happy Eyeballs», que utiliza inmediatamente la dirección IP recibida, sin esperar a que se resuelvan todas las direcciones IPv4 e IPv6 de destino potencialmente disponibles.

Para su uso en la directiva «external_acl», se ha agregado el controlador «ext_kerberos_sid_group_acl» para la autenticación con grupos de verificación en Active Directory usando Kerberos. La utilidad ldapsearch proporcionada por el paquete OpenLDAP se utiliza para consultar el nombre del grupo.

Se agregaron las directivas mark_client_connection y mark_client_pack para vincular las etiquetas Netfilter (CONNMARK) a las conexiones TCP del cliente o paquetes individuales

Finalmente se menciona que siguiendo los pasos de las versiones publicadas de Squid 5.2 y Squid 4.17 se corrigieron las vulnerabilidades:

• CVE-2021-28116 : fuga de información al procesar mensajes WCCPv2 especialmente diseñados. La vulnerabilidad permite a un atacante corromper la lista de enrutadores WCCP conocidos y redirigir el tráfico del cliente proxy a su host. El problema se manifiesta solo en configuraciones con soporte WCCPv2 habilitado y cuando es posible falsificar la dirección IP del enrutador.
• CVE-2021-41611 : error al validar los certificados TLS que permiten el acceso mediante certificados que no son de confianza.

Finalmente si quieres conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Desde Linux https://ift.tt/3iN4OYC
via IFTTT