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 gestor 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 registo de proxy contém normalmente um esquema, um ponto terminal, uma porta e, por vezes, uma referência de autenticação. Esse registo 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 anfitrião 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 ligação interrompe o pedido, tenta outro proxy ou recorre a um percurso 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 ao 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 ao nível do perfil do Chrome. Pode escolher os modos direto, do sistema, detetado 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 operativo. Governa os pedidos tratados pelo contexto de rede do navegador. Não governa automaticamente:

• as próprias chamadas à API do gestor da aplicação;
• uma aplicação ou um atualizador do navegador executados noutro processo;
• as verificações de DNS e conectividade do sistema operativo;
• outra aplicação iniciada a partir de um ficheiro 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 utilize um protocolo que o percurso 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 percurso

O navegador avalia regras fixas, um script de configuração automática do proxy ou as definições do sistema. Uma correspondência de exclusão pode escolher uma ligação direta. Uma lista de proxies pode escolher um proxy principal seguido de alternativas, incluindo DIRECT se a ligaçã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 definiçõ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 anfitrião, 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 utilizador e uma palavra-passe incorporados nas definições manuais de proxy. A sua documentação sobre proxies indica que a autenticação segue o fluxo normal de credenciais do navegador. Um gestor de perfis precisa, portanto, de uma integração explícita para o desafio suportado, não de uma promessa de que qualquer texto utilizador:palavra-passe@anfitrião funcionará.

4. Estabelecer a ligaçã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 anfitrião de destino e os metadados da ligação. Quando o salto entre cliente e proxy utiliza HTTP simples, o pedido CONNECT e o respetivo nome de anfitrião 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 interceçã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 controlo do DNS muda com o esquema de proxy

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

Percurso 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 utilizador e palavra-passe pode, portanto, exigir um intermediário suportado ou outro esquema de proxy. Confirme a implementação do navegador antes de aceitar o registo.

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 ao nível do navegador, enquanto ProxySettings funciona ao nível do perfil. Esta diferença é um aviso útil: a palavra «perfil» numa definição não implica que todos os controlos de DNS tenham o mesmo âmbito.

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 utilizado por pedidos diretos ou excluídos;
• o arranque 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. A utilização de autenticação Basic num proxy HTTP simples expõe a palavra-passe do proxy a qualquer pessoa que consiga observar esse salto.

Um gestor de perfis deve manter separados os seguintes dados:

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

Os ecrãs, registos, APIs, exportações e resultados de automação normais não precisam da palavra-passe 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 respetivos 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 ligação falha antes de alcançar o proxy	Que resolvedor realizou a consulta inicial?
A porta do proxy está inacessível	Tempo limite ou ligaçã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 ligação segura ao proxy é rejeitada	A validação de certificados permanece intacta?
O proxy não consegue resolver o destino	Falha de anfitrião 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 ficheiro PAC está indisponível	A resolução do proxy bloqueia ou muda de percurso	O PAC é obrigatório ou o Chromium pode utilizar silenciosamente DIRECT?
O padrão de exclusão é demasiado amplo	Os sites escolhidos estabelecem uma ligação direta	As regras exatas de anfitrião, subdomínio, porta e as regras implícitas são compreendidas?
O WebRTC utiliza outra interface	O percurso multimédia difere do tráfego da página	O UDP sem proxy está desativado para o perfil?
Uma ligação existente sobrevive a uma alteração	O percurso antigo permanece temporariamente ativo	As ligações são esvaziadas ou o perfil é reiniciado?
A captura de diagnóstico contém demasiados detalhes	URLs, nomes de anfitrião ou segredos entram num ficheiro 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 ao nível da ligaçã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 ficheiro 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 utilizar percursos WebRTC que não equivalem aos pedidos normais de URL por HTTP e HTTPS. A política WebRtcIPHandling predefinida do Chrome pode utilizar 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 ao nível do perfil, o que a torna relevante para um proxy de perfil, mas continua a ser um controlo 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 percurso 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 percurso escolhido não puder ser utilizado.
• Conjunto de proxies aprovado: tentar apenas alternativas indicadas com uma política equivalente.
• Alternativa direta permitida: mostrar que o percurso mudou e registar 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 percurso antes do arranque 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 utilizar o percurso errado.

Uma matriz de validação segura

Teste com pontos terminais e zonas DNS que controla ou está autorizado a inspecionar. Registe 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 contacto com o nome do proxy.
5. Faça expirar uma credencial de teste e confirme que nenhum valor em bruto aparece na interface, nos registos 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 ligações ativas e verifique quando o novo percurso 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 registos 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 ficheiro de apoio deve ser tratado de acordo com o modo de captura efetivo, não com o respetivo nome.