Os filtros de conteúdo bloqueiam sites e serviços por categoria, por nome ou por endereço, e alguns abrem o tráfego HTTPS para inspecionar o conteúdo. Um filtro que bloqueia o domínio de uma integração, ou que inspeciona uma conexão com certificado do cliente, produz erros que parecem do serviço, mas nascem na rede da loja.
Onde o filtro atua
O filtro pode trabalhar em pontos diferentes:
- No proxy: a requisição chega ao proxy, que confere o destino e devolve uma página de bloqueio ou um código de erro;
- No firewall: o firewall reconhece o destino da conexão pelo nome, pelo endereço ou pela categoria e encerra a conexão;
- No DNS: o servidor DNS da rede responde ao nome bloqueado com o endereço 0.0.0.0, com o endereço de uma página de bloqueio ou com uma recusa.
Para um programa, o bloqueio raramente aparece como uma página. A integração recebe uma conexão recusada ou encerrada, um tempo esgotado, um erro de certificado ou um endereço que não pertence ao serviço. A comparação entre a resposta do DNS da rede e a de um DNS público, com o nslookup, mostra se o nome está sendo desviado, e uma rede que bloqueia as consultas a DNS externos faz a segunda consulta falhar, o que também indica o controle do DNS.
A liberação de uma integração no filtro é feita pelos nomes que ela usa, e não pelos endereços IP, porque muitos serviços mudam de endereço e dividem os mesmos endereços com outros sites. A documentação do fornecedor costuma listar os domínios necessários.
A inspeção de HTTPS
Na inspeção de HTTPS, o filtro se coloca no meio da conexão: ele encerra a conexão protegida do computador, abre outra até o serviço e apresenta ao computador um certificado emitido na hora pela autoridade certificadora do próprio filtro. Os computadores da rede recebem essa autoridade como confiável, e o navegador aceita a conexão sem aviso. Nos detalhes do certificado, no navegador, o emissor aparece como a autoridade do filtro, e não como a autoridade pública que emitiu o certificado do serviço.
O problema aparece nos programas que não usam o repositório de certificados do Windows:
- o Java, que confia no próprio arquivo cacerts;
- o Python com a biblioteca Requests, que usa o pacote certifi;
- outras ferramentas com um conjunto próprio de autoridades.
Para esses programas, a autoridade do filtro é desconhecida, e a conexão falha com mensagens como PKIX path building failed, no Java, ou unable to get local issuer certificate. O curl do Windows usa o repositório do Windows e pode funcionar no mesmo computador em que a integração falha.
O que a inspeção quebra
Alguns serviços não funcionam com a inspeção, e a documentação dos próprios filtros prevê exceções para eles:
- Certificado do cliente: no mTLS, o filtro não tem a chave privada do certificado da loja e não consegue apresentá-lo ao serviço, como nas conexões com os serviços fiscais que usam o certificado A1;
- Certificado fixado: o programa aceita só o certificado esperado do serviço e recusa qualquer outro;
- Cadeias incompletas e cifras sem suporte: o filtro não consegue completar a conexão do lado do serviço.
As soluções
A solução segura é a exceção de inspeção para os domínios da integração, configurada no filtro pelo responsável pela rede. Outra solução é instalar a autoridade do filtro no repositório próprio do programa, como o cacerts do Java, pelo procedimento do fornecedor do programa, com nova manutenção a cada troca do certificado do filtro. Desligar a verificação de certificado na integração faz o erro sumir e deixa a conexão aberta a interceptações, e a própria documentação das bibliotecas alerta para esse risco.
No suporte
Diante de um erro de certificado em uma integração que funciona no navegador, convém ver quem emitiu o certificado recebido: com a inspeção, o emissor é a autoridade do filtro. A exceção de inspeção para os domínios da integração corrige o caso, e a verificação de certificado continua ligada.
Para guardar
- O filtro de conteúdo pode atuar no proxy, no firewall ou no DNS.
- Para um programa, o bloqueio aparece como recusa, tempo esgotado, erro de certificado ou endereço errado.
- A inspeção de HTTPS troca o certificado do serviço por um certificado da autoridade do filtro.
- Programas com repositório próprio de autoridades, como o Java, recusam a conexão inspecionada.
- Conexões com certificado do cliente ou com certificado fixado precisam de exceção de inspeção.
Depois da instalação de um filtro com inspeção de HTTPS, a integração em Java do servidor da loja passou a falhar com PKIX path building failed, enquanto o navegador do mesmo servidor abre o site do fornecedor sem aviso. O que explica a diferença?
O navegador usa o repositório do Windows, que recebeu a autoridade do filtro, e o Java usa o próprio cacerts, onde essa autoridade não existe. A exceção de inspeção para os domínios da integração resolve sem desligar a verificação de certificado.
A emissão de NFC-e da loja passou a falhar na negociação TLS no mesmo dia em que a rede começou a inspecionar o HTTPS. O certificado A1 está válido. Por quê?
A comunicação com os serviços fiscais usa o certificado do cliente, e o filtro não consegue apresentar esse certificado em nome da loja, porque não tem a chave privada. Os endereços dos serviços fiscais precisam ficar fora da inspeção.