Após três anos de desenvolvimento, a nova versão estável do servidor proxy Squid, 5.1, foi lançada e está pronta para uso em sistemas de produção (as versões 5.0.x eram beta).
Após a versão 5.x atingir um estado estável, a partir de agora serão implementadas apenas correções para vulnerabilidades e problemas de estabilidade , juntamente com pequenas otimizações. O desenvolvimento de novos recursos ocorrerá na nova versão experimental 6.0. Os usuários da versão estável anterior, 4.x, são encorajados a planejar uma migração para a versão 5.x.
Novos recursos principais do Squid 5.1
Nesta nova versão, a compatibilidade com o formato Berkeley DB foi descontinuada devido a problemas de licenciamento . A versão 5.x do Berkeley DB não recebe manutenção há vários anos e ainda apresenta vulnerabilidades não corrigidas, e a atualização para versões mais recentes não permite a alteração da licença AGPLv3, cujos requisitos também se aplicam a aplicativos que utilizam o Berkeley DB como biblioteca. O Squid é distribuído sob a licença GPLv2, e a AGPL é incompatível com a GPLv2.
Em vez do Berkeley DB, o projeto migrou para o TrivialDB DBMS, que, ao contrário do Berkeley DB, é otimizado para acesso paralelo simultâneo ao banco de dados. O suporte ao Berkeley DB ainda é mantido, mas agora é recomendado usar o tipo de armazenamento "libtdb" em vez de "libdb" nos manipuladores "ext_session_acl" e "ext_time_quota_acl".
Além disso, foi adicionado suporte para o cabeçalho HTTP CDN-Loop, definido no RFC 8586, que permite detectar loops ao usar redes de entrega de conteúdo (o cabeçalho fornece proteção contra situações em que uma solicitação, durante o redirecionamento entre CDNs por algum motivo, retorna para o CDN original, formando um loop infinito).
Além disso, o mecanismo SSL-Bump, que permite interceptar o conteúdo de sessões HTTPS criptografadas, agora oferece suporte para redirecionar solicitações HTTPS falsificadas por meio de outros servidores proxy especificados em cache_peer, usando um túnel regular baseado no método HTTP CONNECT (a transmissão via HTTPS não é suportada, pois o Squid ainda não consegue transmitir TLS dentro de TLS).
Ao receber a primeira requisição HTTPS interceptada, o SSL-Bump estabelece uma conexão TLS com o servidor alvo e obtém seu certificado. Em seguida, o Squid utiliza o nome do host do certificado real recebido do servidor para criar um certificado falso, que usa para se passar pelo servidor solicitado ao interagir com o cliente , enquanto continua a usar a conexão TLS estabelecida com o servidor alvo para receber dados.
Vale ressaltar também que a implementação do ICAP (Internet Content Adaptation Protocol), usado para integração com sistemas externos de verificação de conteúdo, adicionou suporte ao mecanismo de anexo de dados , que permite que cabeçalhos de metadados adicionais sejam anexados à resposta, colocados após o corpo da mensagem.
Em vez de levar em consideração o "dns_v4_first»Para determinar a ordem de uso da família de endereços IPv4 ou IPv6, agora a ordem da resposta no DNS é levada em consideração- Se a resposta AAAA do DNS aparecer primeiro enquanto aguarda a resolução de um endereço IP, o endereço IPv6 resultante será usado. Portanto, a configuração da família de endereços preferida agora é feita no firewall, DNS ou na inicialização com a opção "–disable-ipv6".
A mudança proposta irá acelerar o tempo para configurar as conexões TCP e reduzir o impacto no desempenho de atrasos na resolução de DNS.
Ao redirecionar solicitações, é utilizado o algoritmo "Happy Eyeballs", que usa imediatamente o endereço IP recebido, sem esperar que todos os endereços IPv4 e IPv6 de destino potencialmente disponíveis sejam resolvidos.
Para uso na diretiva "external_acl", o driver "ext_kerberos_sid_group_acl" foi adicionado para autenticação com grupos de verificação no Active Directory usando Kerberos. O utilitário ldapsearch fornecido pelo pacote OpenLDAP é usado para consultar o nome do grupo.
Adicionadas as diretivas mark_client_connection e mark_client_pack para vincular as tags Netfilter (CONNMARK) a pacotes individuais ou conexões TCP cliente
Por fim, menciona-se que, seguindo os passos das versões publicadas do Squid 5.2 e do Squid 4.17, as seguintes vulnerabilidades foram corrigidas:
- CVE-2021-28116 - Vazamento de informações ao processar mensagens WCCPv2 especialmente criadas. A vulnerabilidade permite que um invasor corrompa a lista de roteadores WCCP conhecidos e redirecione o tráfego do cliente proxy para seu host. O problema se manifesta apenas em configurações com suporte a WCCPv2 habilitado e quando é possível falsificar o endereço IP do roteador.
- CVE-2021-41611: erro ao validar certificados TLS que permitem acesso usando certificados não confiáveis.
Por fim, se quiser saber mais sobre isso, você pode conferir os detalhes no seguinte link.