Brave explica sobre sua Rede de Distribuição de Conteúdo Privado

Texto traduzido do blog oficial do Brave Browser.

Escrito em 10/12/2020 

Esta postagem descreve o trabalho realizado pelo engenheiro sênior de segurança do produto François Marier e pelo engenheiro de desenvolvimento sênior Ben Kero. Muito obrigado ao Pesquisador Sênior de Privacidade Pete Snyder (@ pes10k) e Tom Lowenthal por sua ajuda no projeto deste sistema, e a Matteo Varvello pelos testes de desempenho completos.

Brave é uma empresa onde a privacidade não é apenas um recurso; é um requisito. Isso talvez seja mais óbvio no Brave Browser, onde bloqueamos rastreadores, evitamos impressões digitais e incluímos um sistema de anúncios que preserva a privacidade, opt-in e o usuário primeiro, mas o foco do Brave na privacidade vai muito além do navegador.

Por exemplo, embora o Brave limite agressivamente a frequência com que o navegador se conecta de volta aos servidores do Brave, há casos em que o navegador precisa buscar atualizações ou ativos de nossos servidores. Enquanto seguimos as melhores práticas de minimização de dados, aspiramos ir mais longe. A promessa de fazer a coisa certa é necessária, mas não suficiente: nosso objetivo é impossibilitar a Brave de prejudicar a privacidade do usuário.

Por exemplo, no que diz respeito aos endereços IP de nossos usuários, atualmente os filtramos de solicitações no nível de CDN para a maioria dos nossos serviços, de modo que não podemos incluí-los acidentalmente nos registros. Para um novo tipo de serviço, no entanto, queríamos dar o próximo passo: garantir que a rede de distribuição de conteúdo que usamos não pudesse ser reconfigurada para registrar endereços IP, mesmo que quiséssemos.

Aqui está uma descrição da primeira fase de nosso trabalho nesta direção: uma rede de distribuição de conteúdo com preservação de privacidade para os serviços da Brave.

Motivação

Os novos recursos do Brave aumentaram a proteção dos endereços IP dos clientes. O mais recente foi um novo serviço chamado Brave Today, que fornece um feed de notícias personalizado na página nova guia.

Servir o feed de notícias em si pode ser feito usando uma rede de entrega de conteúdo tradicional, porque enviamos o mesmo feed para todos os usuários e decidimos localmente no navegador quais itens mostrar. A parte que exigia um CDN privado era o uso das imagens contidas nos feeds. Se essas imagens fossem baixadas sob demanda enquanto um usuário rolava pelo feed, qualquer pessoa que olhasse as solicitações de imagem do usuário seria capaz de determinar quais artigos de notícias foram exibidos no feed. Isso, por sua vez, vazaria informações sobre o modelo de aprendizado de máquina local usado para personalizar o feed e, indiretamente, sobre o histórico de navegação usado para treinar esse modelo.

Design

A abordagem tradicional para lidar com serviços sensíveis à latência, como Brave Today, é servir e armazenar conteúdo em cache em uma rede de distribuição de conteúdo. Sob tal design, no entanto, a organização executando o CDN (e encerrando a criptografia TLS) veria as solicitações de um usuário e o endereço IP. Nosso caso de uso requer que mantenhamos esses dois elementos separados. Portanto, decidimos melhorar a abordagem tradicional de CDN adicionando um balanceador de carga TCP na frente do CDN.

Esta é a aparência da solução completa:

Sob esse modelo, o fornecedor do balanceador de carga não vê o conteúdo das solicitações ou das respostas porque tudo o que pode ver é o tráfego TCP criptografado na porta 443, que pode ser descriptografado apenas pelo CDN. Além disso, embora o fornecedor de CDN possa ver o conteúdo do tráfego HTTP criptografado, ele não pode ver o verdadeiro endereço IP do usuário e, em vez disso, obter um dos endereços IP do balanceador de carga.

Para garantir que todas as solicitações passem pelo balanceador de carga e pelo CDN, o CDN aceita conexões apenas de endereços IP que pertencem ao balanceador de carga. Da mesma forma, o bucket S3 é privado e requer uma chave de acesso mantida pelo CDN.

Uma parte crucial desse design é o uso de dois fornecedores / concorrentes diferentes para reduzir o risco de esses fornecedores conspirarem para desanonimizar nossos usuários.

Proteções de privacidade adicionais

Embora o balanceador de carga TCP não tenha a capacidade de descriptografar o tráfego que transita por ele em seu caminho para o CDN, ele pode observar o tamanho das solicitações e respostas, o que pode indicar o que está sendo solicitado por um determinado usuário. Não temos motivos para acreditar que nossos fornecedores tentariam inferir o histórico de navegação de nossos usuários dessa forma, mas decidimos implementar uma camada de proteção adicional.

Preenchimento

As solicitações para esse serviço precisam, idealmente, parecer idênticas umas às outras, para que o tamanho da solicitação não possa ser usado para adivinhar o arquivo que está sendo solicitado.

Por exemplo, um serviço que solicita imagens como estas:

- /article/12/image/3927.png

- /article/8/image/148.jpg

pode ser modificado para preencher os IDs de solicitação como este:

- /article/0012/image/03927.png

- /article/0008/image/00148.jpg

Do lado da resposta, pode ser um desperdício preencher todos os arquivos com o mesmo tamanho, mas podemos, pelo menos, tentar limitar o número de diferentes tamanhos de resposta possíveis. Isso significa que cada aplicativo que usa esse CDN privado precisa descobrir como é a resposta média e, em seguida, escolher um pequeno número de tamanhos padrão para que as respostas sejam distribuídas uniformemente em todos eles.

Para tornar mais fácil para nossos aplicativos fazerem o preenchimento de resposta corretamente, criamos um esquema de preenchimento muito simples, juntamente com uma biblioteca de referência e uma implementação comum no navegador.

Claro, não importa o quão preciso seja o nosso preenchimento de tamanho, tudo seria em vão se não desabilitássemos qualquer tipo de compressão de resposta (normalmente gzip ou deflate) no lado do CDN.

Omitindo cabeçalhos de solicitação

Embora o CDN nunca veja o endereço IP do usuário, existem outros cabeçalhos HTTP que podem ser usados para imprimir as impressões digitais do usuário em algum grau, dependendo da exclusividade dos valores nesses cabeçalhos.

É por isso que cada aplicativo que usa nosso CDN privado é solicitado a remover os seguintes cabeçalhos de suas solicitações:

- Accept-Language

- Cookies

- DNT

- Referer

- Agente-usuário

E sobre Brave?

Até agora, cobrimos como podemos evitar que nossos fornecedores de infraestrutura conheçam o conteúdo da solicitação de um usuário e o endereço IP do usuário. No entanto, pode-se perguntar: e a Brave, que tem acesso aos painéis de ambos os fornecedores?

Esta é uma boa pergunta. Para poder correlacionar solicitações com base no tempo, precisaríamos:

- têm acesso a registros em ambos os sistemas, ou

- anexar informações adicionais às solicitações conforme elas saem do balanceador de carga TCP.

A primeira abordagem é fácil de neutralizar porque o fornecedor do balanceador de carga configurou nossa conta para desabilitar o acesso aos recursos de registro que eles oferecem.

Em termos de adicionar informações adicionais às solicitações, não podemos adicionar nenhum cabeçalho HTTP porque o balanceador de carga não encerra o TLS, mas poderíamos configurá-lo para habilitar o protocolo de proxy a fim de inserir o endereço IP do cliente original em todos os pedidos de saída.

Felizmente, nosso provedor de CDN atual não oferece realmente a capacidade de analisar e usar essas informações de proxy de entrada, mas como essa limitação técnica pode desaparecer no futuro, decidimos adicionar uma proteção contratual adicional. Como parte de nosso contrato empresarial com o fornecedor do balanceador de carga, solicitamos que nosso serviço esteja sujeito aos seguintes termos adicionais:

O Serviço incluirá [balanceador de carga TCP] e o Cliente concorda em usar [balanceador de carga TCP] apenas com o protocolo proxy desativado. O Cliente entende que está proibido de acessar IPs de Cliente e em conexão com o Serviço, [Fornecedor] não fornecerá acesso a [instalações de registro], mesmo a pedido do Cliente.

Confie mas verifique

Ter um bom design é importante, mas a menos que os usuários possam verificar nossas afirmações de forma independente, contamos com a confiança deles. Por mais que nos consideremos privilegiados por ter conquistado a confiança de nossos usuários, pretendemos ser o mais transparentes possível no que diz respeito à privacidade.

Para começar, qualquer pessoa pode verificar as afirmações que fazemos sobre o processamento do lado do cliente, uma vez que o navegador Brave é Open Source.

Em segundo lugar, os usuários podem verificar se o navegador está se conectando a um endereço IP que pertence ao fornecedor do balanceador de carga examinando o tráfego do navegador usando um proxy local, como mitmproxy, ou simplesmente verificando qual endereço IP o nome de host pcdn.brave.com resolve para.

Por fim, para verificar se o primeiro fornecedor está encaminhando solicitações para outro CDN e se esse outro CDN está encerrando o TLS, você pode comparar os cabeçalhos de resposta que obtém em https://pcdn.brave.com/ aos de um site atendido diretamente pelo primeiro fornecedor, como https://haveibeenpwned.com/.

Se você ver algo, diga algo

O objetivo de desenvolver este novo sistema é permitir serviços que enriquecem a experiência que a Brave oferece, sem comprometer as propriedades de privacidade que nossos usuários esperam. À medida que desenvolvemos esses recursos e adicionamos outros, queremos que você tenha certeza de que estamos fazendo as coisas certas. Portanto, como sempre, se você descobrir que alguma parte de nosso sistema não está funcionando conforme o esperado, recomendamos que entre em contato por meio de nosso programa de recompensa por bug de segurança.