Después de tres años de desarrollo, se ha presentado una versión estable del servidor proxy Squid 5.1, lista para su uso en sistemas de producción (las versiones 5.0.x tenían el estado de versiones beta). Después de que a la rama 5.x se le haya otorgado el estado estable, de ahora en adelante solo se realizarán correcciones para vulnerabilidades y problemas de estabilidad, y también se permitirán optimizaciones menores. El desarrollo de nuevas funcionalidades se realizará en la nueva rama experimental 6.0. Se recomienda a los usuarios de la rama estable anterior 4.x que planeen migrar a la rama 5.x.
Innovaciones clave en Squid 5:
- La implementación del ICAP (Protocolo de adaptación de contenido de Internet), utilizado para la integración con sistemas de verificación de contenido externos, ha agregado soporte para un mecanismo de adjunto de datos (tráiler), que permite adjuntar encabezados adicionales con metadatos a la respuesta, colocados después del mensaje. cuerpo (por ejemplo, puede enviar una suma de verificación y detalles sobre los problemas identificados).
- 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 IPv4 e IPv6 potencialmente disponibles. En lugar de utilizar la configuración "dns_v4_first" para determinar si se utiliza una familia de direcciones IPv4 o IPv6, ahora se tiene en cuenta el orden de la respuesta DNS: si la respuesta DNS AAAA llega primero cuando se espera que se resuelva una dirección IP, entonces el Se utilizará la dirección IPv6 resultante. Por lo tanto, la configuración de la familia de direcciones preferida ahora se realiza en el nivel de firewall, DNS o inicio con la opción “--disable-ipv6”. El cambio propuesto nos permite acelerar el tiempo de configuración de las conexiones TCP y reducir el impacto en el rendimiento de los retrasos durante la resolución DNS.
- Para su uso en la directiva "external_acl", se agregó el controlador "ext_kerberos_sid_group_acl" para la autenticación con verificación de grupo en Active Directory usando Kerberos. Para consultar el nombre del grupo, utilice la utilidad ldapsearch proporcionada por el paquete OpenLDAP.
- La compatibilidad con el formato Berkeley DB ha quedado obsoleta debido a problemas de licencia. La rama Berkeley DB 5.x no se ha mantenido durante varios años y sigue teniendo vulnerabilidades sin parches, y la transición a versiones más recientes se evita mediante un cambio de licencia a AGPLv3, cuyos requisitos también se aplican a las aplicaciones que utilizan BerkeleyDB en forma de una biblioteca: Squid se suministra bajo la licencia GPLv2 y AGPL no es compatible con GPLv2. En lugar de Berkeley DB, el proyecto pasó al uso del DBMS TrivialDB, que, a diferencia de Berkeley DB, está optimizado para el acceso paralelo simultáneo a la base de datos. La compatibilidad con Berkeley DB se mantiene por ahora, pero los controladores "ext_session_acl" y "ext_time_quota_acl" ahora recomiendan usar el tipo de almacenamiento "libtdb" en lugar de "libdb".
- Se agregó soporte para el encabezado HTTP CDN-Loop, definido en RFC 8586, que le permite detectar bucles cuando se utilizan redes de entrega de contenido (el encabezado brinda protección contra situaciones en las que una solicitud en el proceso de redireccionamiento entre CDN por algún motivo regresa al CDN original, formando un bucle sin fin).
- El mecanismo SSL-Bump, que le permite interceptar el contenido de sesiones HTTPS cifradas, ha agregado soporte para redirigir solicitudes HTTPS falsificadas (recifradas) a través de otros servidores proxy especificados en cache_peer, utilizando un túnel normal 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 transportar TLS dentro de TLS). SSL-Bump le permite establecer una conexión TLS con el servidor de destino al recibir la primera solicitud HTTPS interceptada y obtener su certificado. Después de esto, Squid utiliza el nombre de host del certificado real recibido del servidor y crea un certificado ficticio, con el que imita el servidor solicitado al interactuar con el cliente, mientras continúa usando la conexión TLS establecida con el servidor de destino para recibir datos ( Para que la sustitución no genere advertencias en los navegadores del lado del cliente, debe agregar su certificado utilizado para generar certificados ficticios al almacén de certificados raíz).
- Se agregaron las directivas mark_client_connection y mark_client_pack para vincular las marcas de Netfilter (CONNMARK) a las conexiones TCP del cliente o a paquetes individuales.
Pisándoles los talones se publicaron los lanzamientos de Squid 5.2 y Squid 4.17, en los que se solucionaron 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 desde los clientes del servidor proxy a su host. El problema sólo aparece en configuraciones con soporte WCCPv2 habilitado y cuando es posible falsificar la dirección IP del enrutador.
- CVE-2021-41611: un problema en la verificación del certificado TLS permite el acceso mediante certificados que no son de confianza.
Fuente: opennet.ru