Após três anos de desenvolvimento, foi lançado o release estável do servidor proxy Squid 5.1, pronto para ser utilizado em sistemas de produção (as versões 5.0.x tinham status de beta). Com a versão 5.x recebendo o status de estável, agora serão produzidas apenas correções de vulnerabilidades e problemas de estabilidade, além de pequenas otimizações permitidas. O desenvolvimento de novas funcionalidades será realizado em uma nova branch experimental 6.0. Usuários da versão estável anterior 4.x são aconselhados a planejar a migração para a versão 5.x.
Principais novidades do Squid 5:
- A implementação do protocolo ICAP (Internet Content Adaptation Protocol), utilizado para integração com sistemas externos de verificação de conteúdo, agora inclui suporte ao mecanismo de anexo de dados (trailer), que permite adicionar cabeçalhos com metadados à resposta, colocados após o corpo da mensagem (por exemplo, pode-se transmitir um checksum e detalhes sobre problemas identificados).
- Na gestão de redirecionamento de solicitações, foi implementado o algoritmo 'Happy Eyeballs', que utiliza imediatamente o endereço IP recebido, sem aguardar a resolução de todos os endereços-alvo potenciais IPv4 e IPv6. Ao contrário da configuração 'dns_v4_first' para determinar a ordem de utilização das famílias de endereços IPv4 ou IPv6, agora é considerada a ordem da resposta do DNS: se ao aguardar a resolução endereços IP a primeira resposta recebida for um endereço DNS AAAA, o endereço IPv6 recebido será utilizado. Assim, a configuração da família de endereços preferida agora é feita no nível do firewall, DNS ou ao iniciar com a opção '--disable-ipv6'. A alteração proposta permite acelerar o tempo de estabelecimento de conexões TCP e reduzir o impacto nas mudanças de desempenho causadas por atrasos na resolução no DNS.
- Para uso na diretiva 'external_acl', foi adicionado o manipulador 'ext_kerberos_sid_group_acl' para autenticação com verificação de grupos no Active Directory usando Kerberos. Para solicitar o nome do grupo, é utilizada a ferramenta ldapsearch, fornecida pelo pacote OpenLDAP.
- O suporte ao formato de banco de dados Berkeley DB foi declarado obsoleto devido a problemas de licença. A versão Berkeley DB 5.x não é mais mantida há vários anos e permanece com vulnerabilidades não corrigidas, e a transição para versões mais novas é inviável devido à alteração da licença para AGPLv3, cujos requisitos se aplicam também a aplicativos que utilizam BerkeleyDB na forma de biblioteca — o Squid é fornecido sob a licença GPLv2, e a AGPL é incompatível com a GPLv2. Em vez disso, o projeto foi migrado para o uso do banco de dados TrivialDB, 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 nos manipuladores “ext_session_acl” e “ext_time_quota_acl”, agora é recomendado usar o tipo de armazenamento “libtdb” em vez de “libdb”.
- Foi adicionado suporte para o cabeçalho HTTP CDN-Loop, definido na 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, retorna para a CDN original, criando um loop infinito).
- O mecanismo SSL-Bump, que permite interceptar o conteúdo de sessões HTTPS criptografadas, agora suporta redirecionamento de solicitações HTTPS modificadas (recriptografadas) por meio de outros servidores proxy especificados em cache_peer, usando um túnel padrão baseado no método HTTP CONNECT (a transmissão via HTTPS não é suportada, pois o Squid ainda não pode transmitir TLS dentro de TLS). O SSL-Bump permite que, ao receber a primeira solicitação HTTPS interceptada, uma conexão TLS seja estabelecida com o servidor de destino e seu certificado seja obtido. Depois disso, o Squid usa o nome do host do certificado real recebido do servidor e cria um certificado fictício, com o qual simula o servidor solicitado ao interagir com o cliente, continuando a usar a conexão TLS estabelecida com o servidor de destino para obter dados (para que a substituição não resulte em avisos nos navegadores do lado do cliente, é necessário adicionar o seu certificado, usado para gerar certificados fictícios, ao armazenamento de certificados raiz).
- Diretivas mark_client_connection e mark_client_pack foram adicionadas para vincular marcas Netfilter (CONNMARK) a conexões TCP do cliente ou a pacotes individuais.
Em seguida, foram lançadas as versões Squid 5.2 e Squid 4.17, nas quais foram corrigidas vulnerabilidades:
- CVE-2021-28116 — vazamento de informações ao processar mensagens WCCPv2 formatadas de forma especial. A vulnerabilidade permite que um atacante corrompa a lista de roteadores WCCP conhecidos e redirecione o tráfego de clientes do servidor proxy para seu próprio host. O problema ocorre apenas em configurações com suporte WCCPv2 ativado e com a possibilidade de realizar spoofing do endereço IP do roteador.
- CVE-2021-41611 — erro na verificação certificados TLS, permitindo o acesso usando certificados não confiáveis.
Fonte: opennet.ru
