Proxy por perfil do navegador: DNS, autenticação e modos de falha

Este guia utiliza o comportamento de rede documentado do Chromium como referência. Outros navegadores e produtos podem tomar decisões diferentes, e um gerenciador de navegadores pode acrescentar um intermediário de rede local em torno do Chromium. Verifique o comportamento da compilação exata que utiliza.

Comece por quatro perguntas independentes

Um registro de proxy contém normalmente um esquema, um ponto terminal, uma porta e, por vezes, uma referência de autenticação. Esse registro deixa quatro questões de política separadas:

1. Cobertura: que pedidos e protocolos do navegador são atribuídos a este proxy?
2. Resolução de nomes: é o dispositivo ou o proxy que resolve o nome do host de destino?
3. Autenticação: que esquemas de cliente e proxy funcionam em conjunto e onde são guardadas as credenciais?
4. Falha: um erro de conexão interrompe o pedido, tenta outro proxy ou recorre a um caminho direto?

Tratar estas questões como um único interruptor de «proxy ativo» causa a maioria das surpresas. O Chromium documenta a escolha de proxy como resolução no nível do URL: um URL produz uma lista ordenada de opções de proxy antes de o destino ser necessariamente resolvido. As regras de exclusão e alternativa fazem parte desta decisão.

O que abrange um proxy por perfil

A política ProxySettings da Google é aplicada no nível do perfil do Chrome. Pode escolher os modos direto, do sistema, detectado automaticamente, de servidor fixo ou de script PAC, com campos explícitos para exclusões e obrigatoriedade do PAC.

Este limite é mais estreito do que uma VPN ou um espaço de nomes de rede do sistema operacional. Governa os pedidos tratados pelo contexto de rede do navegador. Não governa automaticamente:

• as próprias chamadas à API do gerenciador do aplicativo;
• um aplicativo ou um atualizador do navegador executados em outro processo;
• as verificações de DNS e conectividade do sistema operacional;
• outro aplicativo iniciado a partir de um arquivo transferido;
• um auxiliar nativo separado de uma extensão;
• serviços locais alcançados através de exclusões implícitas da interface de retorno; ou
• tráfego que use um protocolo que o caminho de proxy escolhido não consegue transportar.

Alguns destes componentes podem ter suporte próprio de proxy. Esse suporte deve ser especificado e testado separadamente. Uma afirmação de produto como «o tráfego do perfil utiliza este proxy» deve identificar os processos e protocolos incluídos, em vez de sugerir encaminhamento em todo o dispositivo.

Acompanhe um pedido HTTPS

Uma navegação HTTPS normal tem várias etapas.

1. Escolher o caminho

O navegador avalia regras fixas, um script de configuração automática do proxy ou as configurações do sistema. Uma correspondência de exclusão pode escolher uma conexão direta. Uma lista de proxies pode escolher um proxy principal seguido de alternativas, incluindo DIRECT se a conexão direta alternativa for permitida.

O Chromium também aplica exclusões implícitas a destinos localhost e link-local. Isto protege origens locais de configurações de proxy controladas externamente, mas significa que uma descrição ampla como «todo o tráfego» precisa de uma ressalva.

2. Resolver e alcançar o proxy

Se o ponto terminal do proxy for um nome de host, o dispositivo continua a precisar de uma forma de o resolver e contactar. A resolução remota do DNS de destino não elimina esta consulta inicial. Uma falha aqui é diferente de o proxy estar acessível, mas não conseguir resolver o destino.

3. Autenticar no proxy

Um proxy HTTP que exija credenciais devolve normalmente 407 Proxy Authentication Required com um desafio. A RFC 9110 define esta troca e os campos Proxy-Authenticate e Proxy-Authorization.

O Chromium não utiliza um nome de usuário e uma senha incorporados nas configurações manuais de proxy. A sua documentação sobre proxies indica que a autenticação segue o fluxo normal de credenciais do navegador. Um gerenciador de perfis precisa, portanto, de uma integração explícita para o desafio suportado, não de uma promessa de que qualquer texto usuário:senha@host funcionará.

4. Estabelecer a conexão ao destino

Com um proxy HTTP, o Chromium delega no proxy a resolução do nome de destino. Num destino HTTPS, o navegador pede ao proxy para criar um túnel CONNECT e, depois, realiza TLS ponto a ponto com o destino através desse túnel.

O proxy continua a conhecer o nome do host de destino e os metadados da conexão. Quando o salto entre cliente e proxy utiliza HTTP simples, o pedido CONNECT e o respectivo nome de host não estão protegidos nesse salto. Um proxy HTTPS acrescenta TLS entre o navegador e o proxy, protegendo esses metadados contra observadores entre ambos. Não impede o próprio proxy de ver o destino pedido.

Normalmente, o proxy não consegue ler o conteúdo da página HTTPS transportado no túnel. A interceptação TLS é um modelo de confiança diferente, em que o cliente confia numa autoridade de certificação que permite ao intermediário terminar e recriar o TLS. Nunca deve ser silenciosamente confundida com um simples encaminhamento.

O controle do DNS muda com o esquema de proxy

O comportamento documentado do Chromium varia conforme o tipo de proxy:

Caminho escolhido	Resolução do nome de destino no Chromium	Limite importante
Direto ou excluído	Resolvedor do dispositivo ou navegador	O tráfego para o destino sai sem o proxy do perfil
Proxy HTTP	Lado do proxy	O transporte HTTP simples entre cliente e proxy expõe os pedidos HTTP; HTTPS utiliza CONNECT
Proxy HTTPS	Lado do proxy	O cliente tem de validar o certificado TLS do proxy
Proxy SOCKS4	Lado do cliente	Apenas destinos IPv4; o Chromium não implementa a alternativa SOCKS4a
Proxy SOCKS5	Lado do proxy	O Chromium utiliza-o para pedidos de URL por TCP e documenta que não suporta autenticação SOCKS5

A RFC 1928 permite que um pedido SOCKS5 transporte um nome de domínio e define vários identificadores de métodos de autenticação. Uma capacidade do protocolo não garante a implementação do cliente. Atualmente, o Chromium envia nomes de destino a um proxy SOCKS5, mas afirma que o seu cliente SOCKS5 integrado não suporta métodos de autenticação. Um fornecedor que disponibilize acesso SOCKS5 com nome de usuário e senha pode, portanto, exigir um intermediário suportado ou outro esquema de proxy. Confirme a implementação do navegador antes de aceitar o registro.

O DNS através de HTTPS acrescenta outra camada. A política DnsOverHttpsMode do Chrome distingue automatic, que pode recorrer a DNS não seguro, de secure, que falha a resolução quando o DNS seguro falha. A mesma política está documentada no nível do navegador, enquanto ProxySettings funciona no nível do perfil. Esta diferença é um aviso útil: a palavra «perfil» numa configuração não implica que todos os controles de DNS tenham o mesmo escopo.

Um produto que execute cada perfil num processo separado do navegador pode criar um limite efetivo mais estreito, mas isso é uma escolha de implementação. Teste-a. As provas devem distinguir:

• a resolução do ponto terminal do proxy;
• a resolução do destino pedido;
• o DNS usado por pedidos diretos ou excluídos;
• a inicialização e as alternativas do DNS seguro; e
• o DNS realizado por componentes fora do contexto de rede do perfil.

A autenticação é um problema de compatibilidade e de tratamento de segredos

O Chromium documenta Basic, Digest, Negotiate e NTLM para proxies HTTP. Os proxies HTTPS acrescentam um canal protegido entre cliente e proxy e também podem suportar certificados de cliente. A autenticação de SOCKS4 e SOCKS5 não é implementada pelo cliente de proxy integrado no Chromium, apesar de existirem métodos de autenticação na especificação SOCKS5.

Mesmo um esquema compatível pode ser inseguro no transporte errado. A RFC 7617 explica que as credenciais Basic apenas são codificadas em Base64 e exigem um canal protegido, como TLS. O uso de autenticação Basic num proxy HTTP simples expõe a senha do proxy a qualquer pessoa que consiga observar esse salto.

Um gerenciador de perfis deve manter separados os seguintes dados:

• metadados não secretos do ponto terminal, como esquema, host, porta e etiqueta do fornecedor;
• uma referência secreta usada pelo serviço de ciclo de vida ou de rede;
• o valor da credencial num armazenamento protegido;
• estado de conexão ocultado para a interface e o registro de auditoria; e
• detalhes de diagnóstico disponíveis apenas através de um fluxo de apoio controlado.

As telas, registros, APIs, exportações e resultados de automação normais não precisam da senha do proxy. Um operador precisa, em geral, de saber que a autenticação falhou, que esquema foi pedido, que ponto terminal esteve envolvido e se ocorreu alguma alternativa.

Modos de falha e respectivos sinais

Falha	Sintoma provável	Limite a verificar
Esquema de proxy errado	Falha do handshake TLS ou do protocolo	Um ponto terminal HTTPS foi declarado como HTTP, ou o inverso?
Não é possível resolver o nome do proxy	A conexão falha antes de alcançar o proxy	Que resolvedor realizou a consulta inicial?
A porta do proxy está inacessível	Tempo limite ou conexão recusada	Existe outro proxy ou DIRECT a seguir na lista?
O desafio de autenticação não é suportado	407 repetido ou pedido de início de sessão	O navegador implementa o esquema solicitado?
A credencial está errada ou expirou	407 depois de enviar a credencial	A referência secreta foi resolvida e o valor foi ocultado dos resultados?
O certificado do proxy HTTPS falha	A conexão segura ao proxy é rejeitada	A validação de certificados permanece intacta?
O proxy não consegue resolver o destino	Falha de host ou túnel específica do proxy	O cliente evitou tentar novamente o destino de forma direta?
CONNECT é recusado	A navegação HTTPS falha nesse destino	A recusa é tratada como política e não como autorização para contornar?
O arquivo PAC está indisponível	A resolução do proxy bloqueia ou muda de caminho	O PAC é obrigatório ou o Chromium pode usar silenciosamente DIRECT?
O padrão de exclusão é demasiado amplo	Os sites escolhidos estabelecem uma conexão direta	As regras exatas de host, subdomínio, porta e as regras implícitas são compreendidas?
O WebRTC utiliza outra interface	O caminho multimídia difere do tráfego da página	O UDP sem proxy está desativado para o perfil?
Uma conexão existente sobrevive a uma alteração	O caminho antigo permanece temporariamente ativo	As conexões são esvaziadas ou o perfil é reiniciado?
A captura de diagnóstico contém demasiados detalhes	URLs, nomes de host ou segredos entram num arquivo de apoio	Que modo de ocultação e regra de retenção se aplicam?

A alternativa do Chromium tem estado. Um proxy com uma falha no nível da conexão pode ser marcado como indisponível e colocado atrás de outras entradas durante algum tempo. Se DIRECT estiver na lista, os pedidos posteriores podem sair sem o proxy. Uma recusa de CONNECT é tratada de forma diferente, pois pode representar uma política intencional de destino e não a indisponibilidade do proxy.

Uma falha do PAC exige atenção especial. O Chromium documenta que um arquivo PAC indisponível pode provocar uma alternativa direta silenciosa, salvo se o PAC estiver marcado como obrigatório. A política ProxySettings do Chrome expõe ProxyPacMandatory precisamente para impedir essa alternativa direta.

O WebRTC e o UDP precisam de uma decisão própria

Uma página pode usar caminhos WebRTC que não equivalem aos pedidos normais de URL por HTTP e HTTPS. A política WebRtcIPHandling padrão do Chrome pode usar todas as interfaces disponíveis. O modo disable_non_proxied_udp restringe o WebRTC a TCP na interface pública, salvo se um proxy configurado suportar UDP.

Esta política está documentada no nível do perfil, o que a torna relevante para um proxy de perfil, mas continua a ser um controle separado. Pode reduzir o desempenho multimídia ou interromper um fluxo que exija UDP direto. Escolha e teste o compromisso expressamente. Não afirme que o proxy abrange tudo com base apenas no carregamento bem-sucedido de uma página.

Decida entre falhar de forma fechada e manter a disponibilidade

A alternativa direta pode ser legítima num perfil de navegação geral que privilegie a disponibilidade. É insegura num fluxo cuja autorização, privacidade ou validade de um teste regional dependa de um caminho de saída específico.

Uma boa política de perfil indica o comportamento pretendido:

• Proxy obrigatório: interromper os pedidos de rede afetados quando o caminho escolhido não puder ser usado.
• Conjunto de proxies aprovado: tentar apenas alternativas indicadas com uma política equivalente.
• Alternativa direta permitida: mostrar que o caminho mudou e registrar o evento sem valores secretos.
• Exclusão explícita: documentar a classe de destinos e a razão pela qual o acesso direto é necessário.

A interface deve tornar visível o estado do caminho antes da inicialização e após uma falha. Mudar silenciosamente de proxy para direto transforma um erro de rede num erro de integridade: o fluxo pode parecer bem-sucedido apesar de usar o caminho errado.

Uma matriz de validação segura

Teste com pontos terminais e zonas DNS que controla ou está autorizado a inspecionar. Registre os resultados esperados antes de executar o teste.

1. Verifique o esquema de proxy declarado em relação ao transporte real do ponto terminal.
2. Confirme o comportamento bem-sucedido de HTTP, HTTPS, WebSocket e do WebRTC necessário.
3. Observe o endereço de saída num destino controlado.
4. Observe que resolvedor recebe a consulta do destino e que resolvedor inicia o contato com o nome do proxy.
5. Faça expirar uma credencial de teste e confirme que nenhum valor em bruto aparece na interface, nos registros ou nos resultados de automação.
6. Torne o proxy de teste inacessível e confirme o resultado configurado de falha fechada ou alternativa.
7. Recuse um destino CONNECT controlado e confirme que a recusa da política não se transforma em acesso direto.
8. Torne um PAC de teste indisponível e confirme o comportamento obrigatório.
9. Exercite os casos de exclusão exata, subdomínio, local, link-local, IPv4 e IPv6 necessários ao fluxo.
10. Altere o proxy enquanto houver conexões ativas e verifique quando o novo caminho entra em vigor.
11. Capture apenas os detalhes de diagnóstico necessários ao teste e, depois, verifique a retenção e a eliminação.

As orientações do Chromium sobre o NetLog tratam os registros de rede como uma questão de privacidade e segurança. Os modos ocultados podem omitir campos sensíveis, enquanto os modos mais detalhados podem incluir cookies ou cabeçalhos de autenticação. Um arquivo de apoio deve ser tratado de acordo com o modo de captura efetivo, não com o respectivo nome.