Conforme usuários e, por consequente, SysAdmins, perceberam desde as últimas atualizações dos navegadores baseados no motor de renderização no Chromium (Chrome, Edge, Opera, Brave, etc..), redes corporativas que implementam Filtros SSL com Webproxy vêm enfrentando instabilidades no acesso a sites HTTPS.

Estes navegadores, em seus últimos updates, impuseram configurações de segurança adicionais que podem interferir na Filtragem de conexões SSL realizadas pelos Webproxys mais populares, como é o caso do Squid ou mesmo do E2Guardian – vastamente utilizados em servidores Linux e pfSense®, por exemplo.

Atualização do post em 06/05/2024

Dentre as principais mudanças em relação aos componentes impostos de segurança nos navegadores, vale destacar:

  1. TLS 1.3 Hybridized Kyber ativado por padrão: Recurso avançado utilizado na proteção contra futuras criptoanálises quânticas que vem ativado por default nas novas versões dos navegadores. As informações são do site Bleeping Computer;
  2. Imposição de HTTP Strict Transport Security (HSTS): A partir da versão 124.0.6367.60/.61 do Chrome, por exemplo, houve uma adesão mais rigorosa às políticas de HSTS, fazendo com que os navegadores ignorem quaisquer configurações de proxy configuradas no nível da rede;
  3. Protocolos de criptografia aprimorados: Atualizações recentes dos respectivos navegadores podem fortalecer as conexões SSL/TLS, tornando mais difícil para servidores proxy ou software de filtragem como o Squid e o E2Guardian inspecionarem o tráfego criptografado;
  4. Mudanças no tratamento de certificados: Novas medidas de segurança implementadas nos browsers podem afetar certificados autoassinados usados pelos Webproxys quando da implementação do SSL MITM (man-in-the-middle). Como resultado, o navegador poderá rejeitar o certificado apresentado pelo proxy, não conseguindo estabelecer uma conexão entre o cliente e o servidor de destino;
  5. Novos métodos de autenticação: As atualizações recentes podem introduzir novos métodos de autenticação que não são totalmente compatíveis com a configuração atual dos pacotes Squid ou E2Guardian no Linux ou pfSense®.

Como CONTORNAR o problema?

No exato momento em que publicamos este post (24/04/2024), ainda não existem atualizações expressas no código dos Webproxys (Squid/E2Guardian) que compatibilizem estes novos requisitos impostos pelas mais recentes versões dos navegadores.

Vale lembrar que estes projetos são completamente open-sources e, deste modo, dependem do envolvimento das suas respectivas comunidades de desenvolvimento para que novas features ou fix sejam implementados. Só então, isso tudo acaba sendo portado nos pacotes que utilizamos em plataformas como Linux ou pfSense®, por exemplo.

Isso posto, seguem algumas alternativas para contornar o comportamento indesejado de imediato e suas respectivas consequências:

  1. Desativar o Recurso de Hybridized Kyber: Você pode desativar o recurso acessando diretamente as configurações nos navegadores. No caso do Chrome, basta ir até: chrome://flags/#enable-tls13-kyber e desabilitar. O inconveniente óbvio, é que você vai precisar fazer isso ou orientar seu usuário a fazê-lo manualmente (um por um);
  2. Desligar a Interceptação do Filtro SSL/TLS do seu Webproxy: Como resultado, seu proxy deixará de inspecionar e registrar as conexões HTTPS (todos os usuários acessarão qualquer conteúdo HTTPS na web);
  3. Passar os destinos por bypass no seu Webproxy: O resultado é basicamente o mesmo do relatado acima, mas apenas para os destinos que você configurar no bypass destination do seu serviço de proxy. Obviamente que aqui temos adicionalmente o trabalho de fazermos isso de forma ‘manual’;
  4. Desativar completamente o serviço de Webproxy: Neste cenário, você resolve o problema, mas, ao mesmo tempo, perde todo e qualquer compliance ou controle do que seus usuários podem e estão fazendo na web – o que pode ser um grave leso aos marcos regulatórios brasileiros como: LGPD e Marco Civil da Internet;
  5. Usar ferramentas de terceiros para Filtros DNS Simples: Você também pode eventualmente usar serviços de terceiros como o OpenDNS, por exemplo, para aplicar filtros simples (onde libera ou bloqueia determinados tipos de sites para a REDE TODA). Neste caso, você perde as políticas individualizadas de acesso à Internet, corre um sério risco de ter seu filtro burlado por DoT (DNS over TLS) e perde o recurso de autenticação de usuários;
  6. Utilizar outros pacotes de software: Se você for um administrador pfSense®, pode eventualmente tentar implementar bloqueios de conexões para alguns sites utilizando o pfBlocker ou o próprio Snort, por exemplo. Contudo, boa parte das consequências acima também ocorrem neste cenário. Além disso, os pacotes citados aqui são extremamente pesados para hardwares mais modestos no papel de firewall.

Como RESOLVER o problema?

A verdade é que a arquitetura da web vem se modificando muito nos últimos anos. O advento e a necessidade de diversos componentes e recursos extras de segurança da informação e outros protocolos (como o Protocolo QUIC, por exemplo), vem dificultando muito os métodos tradicionais de inspeção e filtragem de conexões web – como os puramente baseados em proxy – por exemplo.

De olho em tudo isso, é que lançamos recentemente o UserAuth 4.0. Com ele, você transforma o seu Firewall pfSense® num verdadeiro NGFW (firewall de próxima geração) com autenticação, controle e auditoria dos acessos à web dos seus colaboradores.

Com o UserAuth 4 usar Webproxy (Squid ou E2Guardian) é OPCIONAL!

Graças à integração com NGRules, que agora é um recurso NATIVO do UserAuth, é possível filtrar, bloquear ou permitir conexões de internet diretamente, sem a necessidade de um proxy intermediário. Esta é uma mudança significativa que simplifica a gestão de rede, ao mesmo tempo que mantém altos padrões de segurança da informação.

Portanto, se você é um administrador de redes e firewall pfSense®, não deixe de testar e conferir todas as novidades das múltiplas camadas de SEGURANÇA e AUDITORIA implementadas na última versão do UserAuth. 😉

Se você já é cliente do UserAuth, basta atualizar seu pacote (caso ainda não tenha feito) e implementar a abordagem de FILTRO DNS em conjunto com as regras de firewall dinâmicas providas pelo NGRules.

Você continua AUTENTICANDO e REGISTRANDO os acessos dos seus usuários (transparentemente ou pelo Captive Portal) – inclusive com a possibilidade de EXPORTAR RELATÓRIOS – e pode abandonar de vez o uso de Webproxy na sua rede.

“pfSense® é uma marca registrada da Electric Sheep Fencing, LLC”