Após três anos de desenvolvimento, é apresentada uma versão estável do servidor proxy Squid 5.1, pronta para uso em sistemas de produção (as versões 5.0.x tinham o status de versões beta). Depois de tornar a ramificação 5.x estável, ela agora corrigirá apenas vulnerabilidades e problemas de estabilidade, e pequenas otimizações também são permitidas. O desenvolvimento de novas funcionalidades será realizado em uma nova ramificação experimental 6.0. Recomenda-se que os usuários da ramificação estável 4.x anterior planejem migrar para a ramificação 5.x.
Principais inovações do Squid 5:
- A implementação do protocolo ICAP (Internet Content Adaptation Protocol), utilizado para integração com sistemas externos de inspeção de conteúdo, adicionou suporte ao mecanismo de anexação de dados (trailer), que permite anexar cabeçalhos adicionais com metadados colocados após o corpo da mensagem ao resposta (por exemplo, você pode enviar uma soma de verificação e detalhes dos problemas identificados).
- Ao redirecionar as solicitações, é utilizado o algoritmo "Happy Eyeballs", que utiliza imediatamente o endereço IP recebido, sem aguardar a resolução de todos os endereços de destino IPv4 e IPv6 potencialmente disponíveis. Em vez de considerar a configuração "dns_v4_first" para determinar a ordem na qual uma família de endereços IPv4 ou IPv6 é usada, a ordem de resposta do DNS agora é respeitada: se uma resposta DNS AAAA chegar primeiro enquanto aguarda a resolução de um endereço IP, o resultado O endereço IPv6 será usado. Assim, a configuração da família de endereços preferenciais agora é feita no firewall, no DNS ou no nível de inicialização com a opção "--disable-ipv6". A alteração proposta acelera o tempo de configuração da conexão TCP e reduz o impacto no desempenho da latência de resolução do DNS.
- Para uso na diretiva "external_acl", o manipulador "ext_kerberos_sid_group_acl" foi adicionado para autenticação com verificação de grupo no Active Directory usando Kerberos. O utilitário ldapsearch fornecido pelo pacote OpenLDAP é usado para consultar o nome do grupo.
- O suporte para o formato Berkeley DB foi preterido devido a problemas de licenciamento. A ramificação Berkeley DB 5.x não é mantida há vários anos e permanece com vulnerabilidades não corrigidas, e a mudança para versões mais recentes não permite alterar a licença para AGPLv3, cujos requisitos também se aplicam a aplicativos que usam BerkeleyDB na forma de uma biblioteca - O Squid é licenciado sob a GPLv2 e a AGPL é incompatível com a GPLv2. Em vez do Berkeley DB, o projeto foi alterado para usar o TrivialDB DBMS, que, ao contrário do Berkeley DB, é otimizado para acesso paralelo simultâneo ao banco de dados. O suporte do Berkeley DB foi mantido por enquanto, mas os manipuladores "ext_session_acl" e "ext_time_quota_acl" agora são recomendados para usar o tipo de armazenamento "libtdb" em vez de "libdb".
- Adicionado suporte para o cabeçalho CDN-Loop HTTP, 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 no processo de redirecionamento entre CDNs por algum motivo retorna ao CDN original, formando um loop infinito).
- Suporte para redirecionar solicitações HTTPS falsificadas (recriptografadas) através de outros servidores proxy especificados em cache_peer usando um túnel regular baseado no método HTTP CONNECT foi adicionado ao mecanismo SSL-Bump, que permite organizar a interceptação do conteúdo das sessões HTTPS criptografadas (transmissão sobre HTTPS não é suportado, pois o Squid ainda não pode passar TLS dentro de TLS). O SSL-Bump permite, após o recebimento da primeira solicitação HTTPS interceptada, estabelecer uma conexão TLS com o servidor de destino e obter seu certificado. Depois disso, o Squid usa o nome do host do certificado real recebido do servidor e cria um certificado fictício com o qual imita o servidor solicitado ao interagir com o cliente, continuando a usar a conexão TLS estabelecida com o servidor de destino para receber dados (então que a substituição não leve a avisos de saída em navegadores no lado do cliente, você precisa adicionar seu certificado usado para gerar certificados fictícios ao armazenamento de certificados raiz).
- Adicionadas as diretivas mark_client_connection e mark_client_pack para vincular as marcas do Netfilter (CONNMARK) às conexões TCP do cliente ou pacotes individuais.
Seguindo na perseguição, foram publicados os releases do Squid 5.2 e Squid 4.17 nos quais foram corrigidas as seguintes vulnerabilidades:
- CVE-2021-28116 - Vazamento de informações durante o processamento de mensagens criadas WCCPv2. 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 aparece apenas em configurações com suporte WCCPv2 ativado e quando é possível falsificar o endereço IP do roteador.
- CVE-2021-41611 - Ocorreu um erro ao validar os certificados TLS, permitindo o acesso usando certificados não confiáveis.
Fonte: opennet.ru