Squid 5.1 chega despois de tres anos de desenvolvemento e estas son as súas novidades

Despois de tres anos de desenvolvemento lanzouse a nova versión estable do servidor proxy Squid 5.1 que está listo para o seu uso en sistemas de produción (as versións 5.0.x eran beta).

Despois de facer estable a rama 5.x, a partir de agora, só se fixarán solucións para problemas de estabilidade e vulnerabilidades, e tamén se permitirán pequenas optimizacións. O desenvolvemento de novas funcións farase na nova rama experimental 6.0. Recoméndase aos usuarios da rama estable 4.x máis antiga que planifiquen unha migración á rama 5.x.

Novidades principais de Squid 5.1

Nesta nova versión O soporte para o formato Berkeley DB quedou obsoleto debido a problemas de licenza. A rama Berkeley DB 5.x non se xestiona desde hai varios anos e segue tendo vulnerabilidades sen parches e a actualización a versións máis novas non permite cambiar a licenza AGPLv3, cuxos requisitos tamén se aplican ás aplicacións que usan BerkeleyDB en forma de biblioteca. - Squid libérase baixo a licenza GPLv2 e AGPL é incompatible con GPLv2.

En lugar de Berkeley DB, o proxecto foi trasladado para usar TrivialDB DBMS, que, a diferenza de Berkeley DB, está optimizado para o acceso paralelo simultáneo á base de datos. O soporte de Berkeley DB mantense por agora, pero agora recoméndase usar o tipo de almacenamento "libtdb" no canto de "libdb" nos controladores "ext_session_acl" e "ext_time_quota_acl".

Ademais, engadiuse soporte para a cabeceira HTTP CDN-Loop, definida na RFC 8586, que permite detectar bucles cando se utilizan redes de entrega de contido (a cabeceira ofrece protección contra situacións nas que unha solicitude, durante a redirección entre CDN por algún motivo, devolve ao CDN orixinal, formando un bucle infinito).

Por outra banda, o mecanismo SSL-Bump, o que permite interceptar o contido das sesións HTTPS cifradas, hun soporte adicional para redireccionar peticións HTTPS falsificadas a través doutros servidores proxy especificado en cache_peer usando 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 transmitir TLS dentro de TLS).

SSL-Bump permite, cando chega a primeira solicitude HTTPS interceptada, establecer unha conexión TLS co servidor de destino e obtén o seu certificado. Posteriormente, Squid usa o nome de host do certificado recibido dende o servidor e cree un certificado falso, co que imita o servidor solicitado ao interactuar co cliente, mentres continúa a usar a conexión TLS establecida co servidor de destino para recibir datos.

Tamén se destaca que a implementación do protocolo ICAP (Protocolo de adaptación de contido de Internet), que se usa para a integración con sistemas de verificación de contido externos, engadiu soporte para o mecanismo de anexo de datos o que lle permite engadir cabeceiras de metadatos adicionais á resposta, colocada despois da mensaxe. corpo.

En vez de ter en conta o "dns_v4_first»Para determinar a orde de uso da familia de enderezos IPv4 ou IPv6, agora tense en conta a orde da resposta en DNS- Se a resposta AAAA de DNS aparece primeiro mentres agarda a resolución dunha dirección IP, usarase a dirección IPv6 resultante. Polo tanto, a configuración de familia de enderezos preferida faise agora no cortalumes, DNS ou ao inicio coa opción "–disable-ipv6".
O cambio proposto acelerará o tempo para configurar as conexións TCP e reducirá o impacto no rendemento dos atrasos na resolución DNS.

Ao redireccionar solicitudes, úsase o algoritmo "Happy Eyeballs", que usa inmediatamente o enderezo IP recibido, sen esperar a que se resolvan todos os enderezos IPv4 e IPv6 de destino potencialmente dispoñibles.

Para usalo na directiva "external_acl", engadiuse o controlador "ext_kerberos_sid_group_acl" para a autenticación con grupos de verificación en Active Directory usando Kerberos. A utilidade ldapsearch fornecida polo paquete OpenLDAP úsase para consultar o nome do grupo.

Engadíronse directivas mark_client_connection e mark_client_pack para enlazar etiquetas Netfilter (CONNMARK) a paquetes individuais ou conexións TCP de cliente

Finalmente mencionase que seguindo os pasos das versións lanzadas de Squid 5.2 e Squid 4.17 solucionáronse as vulnerabilidades:

  • CVE-2021-28116 - Fuga de información cando se procesan mensaxes WCCPv2 especialmente elaboradas. A vulnerabilidade permite que un atacante corrompa a lista de enrutadores WCCP coñecidos e redirixa o tráfico do cliente proxy ao seu host. O problema só se manifesta en configuracións con soporte WCCPv2 activado e cando é posible falsificar a dirección IP do enrutador.
  • CVE-2021-41611: erro ao validar certificados TLS que permiten o acceso mediante certificados non fiables.

Finalmente, se queres saber máis sobre el, podes consultar os detalles Na seguinte ligazón.


O contido do artigo adhírese aos nosos principios de ética editorial. Para informar dun erro faga clic en aquí.

Sexa o primeiro en opinar sobre

Deixa o teu comentario

Enderezo de correo electrónico non será publicado. Os campos obrigatorios están marcados con *

*

*

  1. Responsable dos datos: Miguel Ángel Gatón
  2. Finalidade dos datos: controlar SPAM, xestión de comentarios.
  3. Lexitimación: o seu consentimento
  4. Comunicación dos datos: os datos non serán comunicados a terceiros salvo obrigación legal.
  5. Almacenamento de datos: base de datos aloxada por Occentus Networks (UE)
  6. Dereitos: en calquera momento pode limitar, recuperar e eliminar a súa información.