Após três anos de desenvolvimento o lançamento da nova versão estável do servidor proxy Squid 5.1 foi lançado que está pronto para uso em sistemas de produção (as versões 5.0.x eram beta).
Depois de tornar o branch 5.x estável, de agora em diante, apenas correções serão feitas para vulnerabilidades e problemas de estabilidade, e pequenas otimizações também serão permitidas. O desenvolvimento de novas funções será feito no novo ramo experimental 6.0. Os usuários do branch estável 4.x mais antigo são incentivados a planejar uma migração para o branch 5.x.
Novos recursos principais do Squid 5.1
Nesta nova versão O suporte ao formato Berkeley DB foi descontinuado devido a problemas de licenciamento. O ramo do Berkeley DB 5.x não é gerenciado há vários anos e continua a ter vulnerabilidades não corrigidas, e a atualização para versões mais recentes não permite alterar a licença AGPLv3, cujos requisitos também se aplicam a aplicativos que usam BerkeleyDB na forma de biblioteca. - O Squid é lançado sob a licença GPLv2 e AGPL é incompatível com GPLv2.
Em vez de Berkeley DB, o projeto foi transportado para usar TrivialDB DBMS, que, ao contrário do Berkeley DB, é otimizado para acesso paralelo simultâneo ao banco de dados. O suporte ao Berkeley DB é mantido por enquanto, mas agora é recomendado usar o tipo de armazenamento "libtdb" em vez de "libdb" nos drivers "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 que o conteúdo de sessões HTTPS criptografadas seja interceptado, hum suporte adicional para redirecionar solicitações HTTPS falsas por meio de outros servidores proxy especificado em cache_peer usando um túnel regular baseado no método HTTP CONNECT (streaming por HTTPS não é suportado porque o Squid ainda não pode transmitir TLS dentro de TLS).
SSL-Bump permite, na chegada da primeira solicitação HTTPS interceptada, estabelecer uma conexão TLS com o servidor de destino e obtenha seu certificado. Subseqüentemente, O Squid usa o nome do host do certificado recebido do servidor e criar um certificado falso, com o qual imita o servidor solicitado ao interagir com o cliente, enquanto continua a usar a conexão TLS estabelecida com o servidor de destino para receber dados.
Destaca-se também que a implementação do protocolo ICAP (Internet Content Adaptation Protocol), que é usado para integração com sistemas de verificação de conteúdo externo, adicionou suporte para o mecanismo de anexação de dados que permite anexar cabeçalhos de metadados adicionais à resposta, colocados após a mensagem. corpo.
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, o algoritmo "Happy Eyeballs" é usado, 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
Finalmente, é mencionado que seguir os passos das versões lançadas do Squid 5.2 e Squid 4.17 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 você quiser saber mais sobre isso, você pode verificar os detalhes no link a seguir.