Atualização do Private Network Access: lançamento de um teste de descontinuação

Titouan Rigoudy

Yifan Luo

Atualizações

• 23 de março de 2023: o cronograma foi atualizado, e a descontinuação só ocorrerá no Chrome 117.

• 19 de janeiro de 2023: o cronograma foi atualizado, e a descontinuação não ocorrerá até o Chrome 114.

• 12 de agosto de 2022: o cronograma foi atualizado, e a descontinuação não ocorrerá até o Chrome 109.

• 10 de fevereiro de 2022: publicamos um artigo atualizado em Private Network Access: introdução a simulações

• 25 de agosto de 2021: anúncio atualizado sobre o cronograma e introdução de um teste de descontinuação.

O Chrome está descontinuando o acesso a endpoints de rede privada de sites não seguros como parte da especificação de Acesso à rede privada. O objetivo é proteger os usuários contra ataques de falsificação de solicitações entre sites (CSRF, na sigla em inglês) que visam roteadores e outros dispositivos em redes privadas. Esses ataques afetaram centenas de milhares de usuários, permitindo que invasores os redirecionem para servidores maliciosos.

O Chrome vai introduzir as seguintes mudanças:

• Bloqueio de solicitações para redes privadas feitas por sites públicos não seguros a partir do Chrome 94.
• Apresentamos um teste de descontinuação que vai terminar no Chrome
  1. Ele permite que os desenvolvedores solicitem uma extensão de tempo para as origens escolhidas, o que não será afetado durante o teste de descontinuação.
• Apresentamos uma política do Chrome que permitirá que as implantações gerenciadas do Chrome ignorem a descontinuação permanentemente. Disponível no Chrome 92.

Se você precisar de mais tempo para reduzir o impacto do registro de descontinuação do teste de descontinuação.

Se você tiver controle administrativo sobre seus usuários, poderá reativar o recurso usando as políticas do Chrome.

Para reduzir o impacto das novas restrições, use uma destas estratégias:

• Faça upgrade do seu site para HTTPS e, se necessário, o servidor de destino.
• Faça upgrade do seu site para HTTPS e use o WebTransport.
• Inverta a relação de embedding.

Cronograma

• Novembro de 2020: ligação para feedback sobre as próximas mudanças.
• Março de 2021: depois de analisar o feedback e entrar em contato, as próximas mudanças foram anunciadas. A especificação foi renomeada de CORS-RFC1918 para o Private Network Access.
• Abril de 2021: o Chrome 90 será lançado para a versão estável, com avisos de descontinuação.
• Junho de 2021: o Chrome 92 foi lançado na versão Beta, proibindo solicitações de rede privada em contextos não seguros. Após o feedback dos desenvolvedores que solicitaram mais tempo para se ajustar, a descontinuação foi adiada para o Chrome 93 e será acompanhada de um teste de descontinuação.
• Julho de 2021: após mais feedback dos desenvolvedores, a descontinuação e o teste complementar são adiados para o Chrome 94. Além disso, os sites particulares não serão mais afetados pela suspensão de uso.
• Agosto de 2021: lançamento da versão Beta do Chrome 94. Os desenvolvedores da Web podem começar a se inscrever para o teste de descontinuação.
• Setembro de 2021: lançamento do Chrome 94 para a versão Stable. Os desenvolvedores da Web precisam se inscrever no teste de descontinuação e implantar os tokens de teste na produção.
• Dezembro de 2022: pesquisa de teste de origem enviada e feedback recebido. O teste de descontinuação foi estendido para o Chrome 113.
• Março de 2023: o teste de descontinuação foi estendido para o Chrome 116 e terminará no Chrome 117. Um mecanismo alternativo com base em permissão está em desenvolvimento para a versão inicial no Chrome 114.
• Maio de 2023 (provisório): lançamento do mecanismo baseado em permissões no Chrome 114. Os sites podem usá-lo para sair do teste de descontinuação.
• Setembro de 2023: o Chrome 117 foi lançado para a versão estável, encerrando o teste de descontinuação. O Chrome bloqueia todas as solicitações de rede particular de contextos públicos e não seguros.

O que é o Acesso à rede privada

O acesso à rede privada (anteriormente conhecido como CORS-RFC1918) restringe a capacidade dos sites de enviar solicitações para servidores em redes privadas. Ele permite essas solicitações apenas de contextos seguros. A especificação também estende o protocolo de compartilhamento de recursos entre origens (CORS, na sigla em inglês), para que os sites agora precisem solicitar explicitamente uma concessão de servidores em redes privadas antes de poderem enviar solicitações arbitrárias.

Solicitações de rede privada são aquelas cujo endereço IP do servidor de destino é mais particular do que aquele de onde o iniciador da solicitação foi buscado. Por exemplo, uma solicitação de um site público (https://example.com) para um site particular (http://router.local) ou uma solicitação de um site particular para o localhost.

Relação entre redes públicas, privadas e locais no acesso à rede privada (CORS-RFC1918).

Saiba mais em Feedback: CORS para redes privadas (RFC1918).

O que é um teste de descontinuação

Testes de descontinuação (anteriormente conhecidos como testes de origem reversa) são uma forma de testes de origem usada para facilitar a descontinuação de recursos da Web. Os testes de descontinuação permitem que o Chrome suspenda o uso de determinados recursos da Web e impeçam que sites formem novas dependências com eles, além de dar aos sites dependentes mais tempo para migrar.

Durante um teste de descontinuação, os recursos descontinuados ficam indisponíveis para todos os sites por padrão. Os desenvolvedores que ainda precisarem usar os recursos afetados precisarão se inscrever no teste de descontinuação, receber tokens para origens específicas da Web e modificar os sites para exibir esses tokens em cabeçalhos HTTP ou metatags (exceto nesse caso). Se um site disponibilizar tokens válidos correspondentes à origem, o Chrome vai permitir o uso do recurso descontinuado por um período limitado.

Para saber mais, consulte os artigos Primeiros passos com os testes de origem do Chrome e o guia para desenvolvedores da Web sobre testes de origem.

O que vai mudar no Chrome

Chrome 94

A partir do Chrome 94, contextos públicos não seguros (em geral, sites que não são enviados por HTTPS ou de um endereço IP particular) são proibidos de fazer solicitações à rede privada. Isso foi planejado anteriormente para o Chrome 92. Portanto, as mensagens de descontinuação ainda podem mencionar o marco anterior.

Essa descontinuação é acompanhada por um teste de descontinuação, permitindo que os desenvolvedores da Web com sites que usam o recurso descontinuado continuem a usá-lo até o Chrome 116, mediante registro de tokens. Confira abaixo instruções sobre como registrar e ativar o teste no seu site.

Um par de políticas do Chrome pode ser utilizado para desativar a descontinuação totalmente ou em origens específicas, indefinidamente. Isso permite que as instalações gerenciadas do Chrome, por exemplo, em configurações corporativas, evitem falhas.

Chrome 117

O teste de descontinuação termina. Todos os sites precisam ser migrados do recurso descontinuado ou as políticas dos usuários dos usuários precisam ser configuradas para continuar ativando o recurso.

Ações do desenvolvedor recomendadas

É provável que a primeira etapa para os sites afetados precise de mais tempo até que uma correção adequada possa ser implantada, seja se inscrevendo no teste de descontinuação ou usando políticas. Então, o curso de ação recomendado varia de acordo com as circunstâncias de cada site afetado.

Fazer o registro para o teste de descontinuação

Observação:para usar várias origens (como examplepetstore.com e example-pet-store.com), repita essas etapas para cada uma delas.

1. Clique em Registrar no teste de origem do Acesso à rede privada de contextos não seguros para receber um token de teste para a origem participante.
2. Adicione o Origin-Trial: $token específico da origem ao cabeçalho de resposta. Esse cabeçalho de resposta só precisa ser definido nas respostas de navegação e recurso principal quando o documento resultante usa o recurso descontinuado. É inútil (embora inofensivo) anexar esse cabeçalho às respostas de sub-recursos.

Como esse teste precisa ser ativado ou desativado antes que um documento possa fazer solicitações, ele não pode ser ativado com uma tag <meta>. Essas tags só são analisadas no corpo da resposta após a emissão de solicitações de recursos secundários. Isso apresenta um desafio para sites que não controlam cabeçalhos de resposta, como sites estáticos github.io exibidos por terceiros.

Para saber mais, consulte o Guia para desenvolvedores da Web sobre testes de origem.

Ativar políticas

Se você tiver controle administrativo sobre seus usuários, poderá reativar o recurso descontinuado usando uma das seguintes políticas:

• InsecurePrivateNetworkRequestsAllowed
• InsecurePrivateNetworkRequestsAllowedForUrls

Para mais detalhes sobre como gerenciar políticas para seus usuários, acesse este artigo da Central de Ajuda.

Como acessar o localhost

Se o site precisar emitir solicitações para o localhost, basta fazer upgrade dele para HTTPS.

As solicitações direcionadas a http://localhost (ou http://127.*.*.*, http://[::1]) não são bloqueadas por conteúdo misto, mesmo quando emitidas de contextos seguros.

O mecanismo WebKit e os navegadores baseados nele (principalmente o Safari) se desviam da especificação de conteúdo misto do W3C e proíbem essas solicitações como conteúdo misto (link em inglês). Eles também não implementam o Acesso à rede privada, portanto, os sites podem querer redirecionar clientes que usam esses navegadores para uma versão HTTP de texto simples do site, que ainda poderia fazer solicitações ao localhost.

Como acessar endereços IP privados

Se o site precisar emitir solicitações para um servidor de destino em um endereço IP privado, basta fazer upgrade do site do iniciador para HTTPS. O conteúdo misto impede que contextos seguros façam solicitações em HTTP texto simples e, por isso, o site recém-protegido ainda não vai conseguir fazer as solicitações. Há algumas maneiras de resolver esse problema:

• Faça upgrade das duas extremidades para HTTPS.
• Use o WebTransport para se conectar com segurança ao servidor de destino.
• Reverta a relação de embedding.

Faça upgrade das duas extremidades para HTTPS

Essa solução requer controle sobre a resolução de DNS dos usuários, como pode ser o caso em contextos de intranet ou se os usuários receberem os endereços dos servidores de nomes de um servidor DHCP sob seu controle. Isso também exige que você tenha um nome de domínio público.

O principal problema na exibição de sites particulares por HTTPS é que as autoridades de certificação de infraestrutura de chave pública (ICP CA) só fornecem certificados TLS a sites com nomes de domínio público. Para contornar isso:

1. Registre um nome de domínio público (por exemplo, intranet.example) e publique registros DNS que apontem esse nome de domínio para um servidor público de sua escolha.
2. Consiga um certificado TLS para intranet.example.
3. Dentro da rede privada, configure o DNS para resolver intranet.example para o endereço IP particular do servidor de destino.
4. Configure seu servidor particular para usar o certificado TLS para intranet.example. Isso permite que seus usuários acessem o servidor particular em https://intranet.example.

Em seguida, faça upgrade do site que inicia as solicitações para HTTPS e continue fazendo as solicitações como antes.

Essa solução é preparada para o futuro e reduz a confiança que você deposita na sua rede, ampliando o uso da criptografia de ponta a ponta na sua rede privada.

WebTransport

Essa solução não exige controle sobre a resolução de DNS dos usuários. É necessário que o servidor de destino execute um servidor WebTransport mínimo (servidor HTTP/3 com algumas modificações).

É possível ignorar a falta de um certificado TLS válido assinado por uma CA confiável usando WebTransport e seu mecanismo de fixação de certificados. Isso permite estabelecer conexões seguras com dispositivos particulares que podem ter um certificado autoassinado, por exemplo. As conexões WebTransport permitem transferência de dados bidirecional, mas não solicitações de busca. É possível combinar essa abordagem com um service worker para representar solicitações HTTP de maneira transparente na conexão, do ponto de vista do aplicativo da Web. No lado do servidor, uma camada de tradução correspondente pode converter as mensagens WebTransport em solicitações HTTP.

Sabemos que isso representa uma quantidade razoável de trabalho, mas deve ser significativamente mais fácil do que criar com base em WebRTC. Também esperamos que parte do investimento necessário seja implementado como bibliotecas reutilizáveis. Também acreditamos que isso é especialmente válido, considerando o fato de que contextos não seguros podem perder acesso a cada vez mais recursos da plataforma da Web, à medida que ela avança no sentido de incentivar o uso de HTTPS de maneiras mais fortes ao longo do tempo. Independentemente do acesso à rede privada, esse seria um bom investimento de qualquer forma.

Esperamos que o WebTransport via HTTP/3 seja enviado no Chrome 96 (começou um teste de origem) com mitigações para proteção contra compartilhamento de chaves e outras práticas de segurança abaixo do padrão, incluindo:

• Um prazo de validade máximo curto para certificados fixados.
• Um mecanismo específico do navegador para revogar determinadas chaves sujeitas a abuso.

Não enviaremos a restrição de contexto seguro até pelo menos dois marcos após o lançamento da WebTransport. O teste de descontinuação será estendido se necessário.

Embedding inverso

Essa solução não requer controle administrativo sobre a rede e pode ser usada quando o servidor de destino não for poderoso o suficiente para executar HTTPS.

Em vez de buscar sub-recursos particulares de um app da Web público, um esqueleto do app pode ser disponibilizado pelo servidor particular, que busca todos os sub-recursos (como scripts ou imagens) de um servidor público, como uma CDN. O app da Web resultante pode fazer solicitações ao servidor particular, já que elas são consideradas da mesma origem. Ele pode até fazer solicitações para outros servidores com IPs particulares (mas não pelo localhost), mas isso pode mudar a longo prazo.

Ao hospedar apenas um esqueleto no servidor particular, é possível atualizar o app da Web enviando novos recursos ao servidor público, assim como atualizaria um app público da Web. Por outro lado, o app da Web resultante não é um contexto seguro e, por isso, não tem acesso a alguns dos recursos mais avançados da Web.

Planos para o futuro

Restringir solicitações de rede privada a contextos seguros é apenas a primeira etapa no lançamento do Acesso à rede privada. O Chrome está trabalhando para implementar o restante da especificação nos próximos meses. Não perca as atualizações.

Como restringir o acesso de sites privados ao localhost

As alterações no Chrome 94 afetam apenas sites públicos que acessam endereços IP privados ou o localhost. A especificação de Acesso à rede privada também classifica como problemáticas solicitações de sites privados para o localhost. O Chrome também vai descontinuar o uso desses recursos. Isso apresenta um conjunto de desafios um pouco diferente, no entanto, já que muitos sites particulares não têm nomes de domínio, complicando o uso de tokens de teste de descontinuação.

Solicitações de simulação do CORS

A segunda parte do Acesso à rede privada é bloquear solicitações de rede privada iniciadas de contextos seguros com solicitações de simulação do CORS. A ideia é que, mesmo quando a solicitação é iniciada de um contexto seguro, é solicitado que o servidor de destino forneça uma concessão explícita ao iniciador. A solicitação só é enviada se a concessão for bem-sucedida.

Em resumo, uma solicitação de simulação do CORS é uma solicitação HTTP OPTIONS que contém alguns cabeçalhos Access-Control-Request-* que indicam a natureza da solicitação subsequente. O servidor pode decidir se concede ou não acesso detalhado respondendo 200 OK com cabeçalhos Access-Control-Allow-*.

Encontre mais detalhes sobre isso na especificação.

Restringir buscas de navegação

O Chrome está descontinuando e bloqueando solicitações de recursos secundários para redes privadas. Isso não afeta as navegações para redes privadas, que também podem ser usadas em ataques CSRF.

A especificação de Acesso à rede privada não faz distinção entre os dois tipos de busca, que estarão sujeitos às mesmas restrições.

Foto da capa de Markus Spiske no Unsplash (links em inglês)