Después de tres años de desarrollo, se presenta la versión estable del servidor proxy Squid 5.1, lista para su uso en sistemas en producción (las versiones 5.0.x tenían el estado de beta). Una vez que la rama 5.x se ha declarado estable, solo se realizarán correcciones de vulnerabilidades y problemas de estabilidad en ella, así como optimizaciones menores. El desarrollo de nuevas funcionalidades se realizará en una nueva rama experimental 6.0. Se recomienda a los usuarios de la rama estable anterior 4.x planificar la transición a la rama 5.x.
Novedades principales de Squid 5:
- Se ha añadido soporte para el mecanismo de acoplamiento de datos (trailer) en la implementación del protocolo ICAP (Internet Content Adaptation Protocol), utilizado para la integración con sistemas externos de verificación de contenido, lo que permite adjuntar a la respuesta encabezados adicionales con metadatos, que se colocan después del cuerpo del mensaje (por ejemplo, se pueden transmitir sumas de verificación y detalles sobre problemas encontrados).
- Al redirigir solicitudes, se utiliza el algoritmo 'Happy Eyeballs', que utiliza inmediatamente la dirección IP recibida sin esperar a que se resuelvan todas las direcciones de destino disponibles en IPv4 e IPv6. En lugar de considerar la configuración 'dns_v4_first' para determinar el orden de uso de las familias de direcciones IPv4 o IPv6, ahora se considera el orden de la respuesta en DNS: si la respuesta DNS AAAA llega primero, se utilizará la dirección IPv6 recibida. Así, la configuración de la familia de direcciones preferida ahora se realiza a nivel de firewall, DNS o al iniciar con la opción '--disable-ipv6'. Este cambio propuesto permite acelerar el tiempo de establecimiento de conexiones TCP y reducir el impacto en el rendimiento de las latencias durante la resolución en DNS. IP Para su uso en la directiva 'external_acl', se ha añadido el manejador 'ext_kerberos_sid_group_acl' para la autenticación con verificación de grupos en Active Directory mediante Kerberos. Para solicitar el nombre del grupo se utiliza la utilidad ldapsearch, proporcionada por el paquete OpenLDAP.
- Se añadió un procesador 'ext_kerberos_sid_group_acl' en la directiva 'external_acl' para la autenticación de verificación de grupos en Active Directory mediante Kerberos. Para solicitar el nombre del grupo se utiliza la herramienta ldapsearch, que es parte del paquete OpenLDAP.
- El soporte para el formato de base de datos Berkeley DB ha sido desaprobado debido a problemas de licencia. La rama Berkeley DB 5.x no ha recibido soporte durante varios años y presenta vulnerabilidades no corregidas. Además, la transición a versiones más recientes se ve obstaculizada por el cambio en la licencia a AGPLv3, cuyas exigencias también aplican a las aplicaciones que utilizan BerkeleyDB como biblioteca; Squid se distribuye bajo la licencia GPLv2, y AGPL no es compatible con GPLv2. En lugar de Berkeley DB, el proyecto ha sido trasladado a utilizar la base de datos TrivialDB, la cual, a diferencia de Berkeley DB, está optimizada para el acceso paralelo simultáneo a la base de datos. El soporte para Berkeley DB se mantiene por el momento, pero en los controladores 'ext_session_acl' y 'ext_time_quota_acl' se recomienda utilizar el tipo de almacenamiento 'libtdb' en lugar de 'libdb'.
- Se ha añadido soporte para el encabezado HTTP CDN-Loop, definido en el RFC 8586, que permite detectar bucles al utilizar redes de entrega de contenido (el encabezado proporciona protección contra situaciones en las que una solicitud, durante la redirección entre CDNs, regresa por alguna razón a la CDN original, creando un bucle infinito).
- Se ha añadido soporte para redirigir solicitudes HTTPS alteradas (reescriptas) a través de otros servidores proxy especificados en cache_peer, utilizando un túnel común basado en el método HTTP CONNECT en el mecanismo SSL-Bump, que permite interceptar el contenido de las sesiones HTTPS cifradas (la transmisión a través de HTTPS no está soportada, ya que Squid aún no puede transmitir TLS dentro de TLS). SSL-Bump permite establecer una conexión TLS con el servidor de destino y obtener su certificado al recibir la primera solicitud HTTPS interceptada. Después de eso, Squid utiliza el nombre de host del certificado real recibido del servidor y crea un certificado ficticio, con el cual simula al servidor solicitado al interactuar con el cliente, mientras sigue utilizando la conexión TLS establecida con el servidor de destino para obtener datos (para evitar que las sustituciones generen advertencias en los navegadores del lado del cliente, es necesario agregar su certificado, utilizado para generar certificados ficticios, al almacén de certificados raíz).
- Se han añadido las directivas mark_client_connection y mark_client_pack para asociar etiquetas Netfilter (CONNMARK) a conexiones TCP de clientes o paquetes individuales.
Seguido de cerca, se han publicado las versiones Squid 5.2 y Squid 4.17, en las que se han solucionado vulnerabilidades:
- CVE-2021-28116 — fuga de información al procesar mensajes especialmente formateados de WCCPv2. Esta vulnerabilidad permite a un atacante dañar la lista de enrutadores conocidos de WCCP y redirigir el tráfico de los clientes del servidor proxy a su propio host. El problema se manifiesta solo en configuraciones con soporte de WCCPv2 habilitado y con la capacidad de spoofing de la dirección IP del enrutador.
- CVE-2021-41611 — error en la verificación de certificados TLS, que permite el acceso utilizando certificados no confiables.
Fuente: opennet.ru
