Despois de tres anos de desenvolvemento, presentouse unha versión estable do servidor proxy Squid 5.1, lista para o seu uso en sistemas de produción (as versións 5.0.x tiñan o estado de versións beta). Despois de que a rama 5.x teña un estado estable, a partir de agora só se realizarán correccións de vulnerabilidades e problemas de estabilidade, e tamén se permiten optimizacións menores. O desenvolvemento de novas funcionalidades levarase a cabo na nova rama experimental 6.0. Recoméndase aos usuarios da rama anterior 4.x estable que planifiquen migrar á rama 5.x.
Novidades clave en Squid 5:
- A implementación do ICAP (Internet Content Adaptation Protocol), que se utiliza para a integración con sistemas externos de verificación de contido, engade soporte para un mecanismo de anexo de datos (tráiler), que permite anexar cabeceiras adicionais con metadatos á resposta, colocadas despois da mensaxe. corpo (por exemplo, pode enviar unha suma de verificación e detalles sobre os problemas identificados).
- Ao redireccionar as solicitudes utilízase o algoritmo "Happy Eyeballs", que utiliza inmediatamente o enderezo IP recibido, sen esperar a que se resolvan todos os enderezos IPv4 e IPv6 de destino potencialmente dispoñibles. En lugar de utilizar a configuración "dns_v4_first" para determinar se se usa unha familia de enderezos IPv4 ou IPv6, agora terase en conta a orde da resposta DNS: se a resposta DNS AAAA chega primeiro ao esperar a que se resolva un enderezo IP, entón o utilizarase o enderezo IPv6 resultante. Así, a configuración da familia de enderezos preferida faise agora no firewall, DNS ou nivel de inicio coa opción "--disable-ipv6". O cambio proposto permítenos acelerar o tempo de configuración das conexións TCP e reducir o impacto no rendemento dos atrasos durante a resolución de DNS.
- Para o seu uso na directiva "external_acl", engadiuse o controlador "ext_kerberos_sid_group_acl" para a autenticación coa comprobación de grupos en Active Directory mediante Kerberos. Para consultar o nome do grupo, use a utilidade ldapsearch proporcionada polo paquete OpenLDAP.
- O soporte para o formato Berkeley DB quedou en desuso debido a problemas de licenza. A rama Berkeley DB 5.x non se mantén durante varios anos e segue con vulnerabilidades sen parches, e a transición a versións máis recentes impídese mediante un cambio de licenza a AGPLv3, cuxos requisitos tamén se aplican ás aplicacións que usan BerkeleyDB en forma de unha biblioteca: Squid ofrécese baixo a licenza GPLv2 e AGPL non é compatible con GPLv2. En lugar de Berkeley DB, o proxecto foi transferido ao uso do DBMS TrivialDB, que, a diferenza de Berkeley DB, está optimizado para o acceso paralelo simultáneo á base de datos. Polo de agora mantense o soporte de Berkeley DB, pero os controladores "ext_session_acl" e "ext_time_quota_acl" agora recomendan usar o tipo de almacenamento "libtdb" en lugar de "libdb".
- Engadido soporte para a cabeceira HTTP CDN-Loop, definida no RFC 8586, que permite detectar bucles cando se usan redes de entrega de contido (a cabeceira ofrece protección contra situacións nas que unha solicitude en proceso de redirección entre CDN por algún motivo volve ao CDN orixinal, formando un bucle interminable).
- O mecanismo SSL-Bump, que permite interceptar o contido das sesións HTTPS cifradas, engadiu soporte para redirixir solicitudes HTTPS falsificadas (recifradas) a través doutros servidores proxy especificados en cache_peer, utilizando un túnel normal baseado no método HTTP CONNECT ( a transmisión a través de HTTPS non é compatible, xa que Squid aínda non pode transportar TLS dentro de TLS). SSL-Bump permítelle establecer unha conexión TLS co servidor de destino despois de recibir a primeira solicitude HTTPS interceptada e obter o seu certificado. Despois diso, Squid utiliza o nome de host do certificado real recibido do servidor e crea un certificado ficticio, co que imita ao servidor solicitado ao interactuar co cliente, mentres continúa utilizando a conexión TLS establecida co servidor de destino para recibir datos ( para que a substitución non leve aos avisos de saída nos navegadores no lado do cliente, cómpre engadir o seu certificado usado para xerar certificados ficticios ao almacén de certificados raíz).
- Engadíronse as directivas mark_client_connection e mark_client_pack para vincular as marcas de Netfilter (CONNMARK) ás conexións TCP do cliente ou a paquetes individuais.
Enseguida, publicáronse os lanzamentos de Squid 5.2 e Squid 4.17, nos que se corrixiron as vulnerabilidades:
- CVE-2021-28116: fuga de información ao procesar mensaxes WCCPv2 especialmente elaboradas. A vulnerabilidade permite a un atacante corromper a lista de enrutadores WCCP coñecidos e redirixir o tráfico dos clientes do servidor proxy ao seu host. O problema só aparece nas configuracións coa compatibilidade con WCCPv2 activada e cando é posible falsificar o enderezo IP do enrutador.
- CVE-2021-41611: un problema na verificación do certificado TLS permite o acceso mediante certificados non fiables.
Fonte: opennet.ru