Nos últimos dez anos, a Cloudflare tornou-se numa parte importante da Infraestrutura da Internet, alimentando sites, APIs e serviços da web para ajudá-los a tornarem-se mais seguros e eficientes. A internet não só está a crescer em termos de capacidade e de número de utilizadores, mas também em processo evolutivo no que toca ao seu design e funcionalidade. Enquanto principal player no ecossistema da Internet, a Cloudflare tem a responsabilidade de a ajudar a crescer de forma que ela respeite e acrescente valor aos seus utilizadores. Hoje lançamos diversos anúncios no âmbito de ajudar a melhorar os protocolos da Internet em relação a algo que é importante para os nossos clientes e utilizadores da Internet de todo o mundo: a privacidade.
Estas iniciativas são:
- Corrigir uma das últimas fugas de informação em HTTPS através do Encrypted Client Hello (ECH), conhecido anteriormente como Encrypted SNI
- Tornar o DNS ainda mais privado, dando suporte ao"Oblivious DNS-over-HTTPS" (OdoH)
- Desenvolver um protocolo superior para autenticação de palavra-passe, o "OPAQUE" , que torna mais improváveis as violações de palavra-passe.
Cada um destes projetos tem impacto sobre um aspecto da Internet que influencia as nossas vidas online e a nossa pegada digital. Saibamo-lo ou não, há imensa informação privada sobre nós e as nossas vidas à deriva online. Isto é algo que podemos ajudar a consertar.
Há mais de um ano que trabalhamos através de organizações de padrões, como o IETF, e em parceria com os maiores nomes de tecnologia da Internet (incluindo Mozilla, Google e Equinix, entre outros) para projetar, implementar e testar esses novos protocolos de preservação de privacidade à escala da Internet. Cada um destes três protocolos aborda um aspecto crítico das nossas vidas online, pelo que esperamos que ajudem a produzir melhorias reais na privacidade online à medida que ganham adoção.
Uma tradição continuada na Cloudflare
Uma das principais missões da Cloudflare é apoiar e desenvolver tecnologia que ajude a construir uma Internet melhor. Enquanto indústria, fizemos progressos excecionais para tornar a Internet mais segura e robusta. A Cloudflare orgulha-se de ter desempenhado um papel neste progresso, através de múltiplas iniciativas ao longo dos anos.
Aqui estão alguns dos destaques:
- Universal SSL™. Temos sido uma das forças motrizes para encriptar a web. Lançámos o Universal SSL em 2014 para fornecer gratuitamente encriptação de sites aos nossos clientes e temos trabalhado ativamente com autoridades de certificação - como a Let's Encrypt, navegadores da web e operadores de sites para ajudar a remover conteúdo misto. Antes de o Universal SSL ser lançado para oferecer HTTPS gratuitamente a todos os clientes da Cloudflare, apenas 30% das ligações a sites eram encriptadas. Através dos esforços da indústria, esse número é agora 80% - e uma proporção muito maior do tráfego total de Internet. Além de fazer a nossa parte para encriptar a web, apoiámos o projeto Transparência de Certificados ("Certificate Transparency") através do Nimbus e do Merkle Town, o que melhorou a responsabilidade pelo ecossistema de certificados do qual o HTTPS depende pata ter confiança.
- TLS 1.3 e QUIC. Também fomos acérrimos defensores da atualização dos protocolos de segurança existentes. Consideremos o Transport Layer Security (TLS), o protocolo estrutural que protege o HTTPS. Os engenheiros da Cloudflare ajudaram a contribuir para a conceção do TLS 1.3, a versão de referência mais recente e, em 2016, lançámos o suporte para uma versão inicial do protocolo. Este lançamento inicial ajudou a conduzir a melhorias na versão final do protocolo. O TLS 1.3 é, agora, o protocolo de encriptação mais utilizado na web, sendo um componente chave do padrão QUIC emergente, que também fomos pioneiros a adotar.
- Proteger o Roteamento, Nomeação e a Hora. Fizemos grandes esforços para ajudar a proteger outros componentes críticos da Internet. Os nossos esforços para ajudar a proteger o roteamento da Internet através do nosso kit de ferramentas RPKI , estudo de medições e a nossa ferramenta “Is BGP Safe Yet” melhoraram significativamente a resistência da Internet contra fugas de roteamento causadoras de perturbações. O nosso serviço de hora (time.cloudflare.com) ajudou a manter os relógios das pessoas em sincronia com protocolos mais seguros, como o NTS e o Roughtime. Também tornámos o DNS mais seguro ao suportar o DNS-over-HTTPS e o DNS-over-TLS no 1.1.1.1 desde o lançamento, juntamente com o DNSSEC com um só clique no nosso serviço de DNS autoritário e no registrar.
Continuar a melhorar a segurança dos sistemas de confiança online é fundamental para o crescimento da Internet. No entanto, está em jogo um princípio ainda mais fundamental: o respeito. A infraestrutura subjacente à Internet deve ser concebida para respeitar os seus utilizadores.
Construir uma Internet que respeite os utilizadores
Quando inicia sessão num site ou num serviço específicos que tenham uma política de privacidade, sabe o que é que esse site deve fazer com os seus dados. É explícito. Não existe, no entanto, nenhum acordo semelhante entre os utilizadores e os operadores da Internet propriamente dita. Pode ter um acordo com o seu Provedor de Serviços de Internet (ISP) e com o site que está a visitar, mas é muito improvável que saiba sequer que redes é que os seus dados estão a percorrer. A maioria das pessoas não tem um conceito da Internet para além do que veem no seu ecrã, por isso é difícil de imaginar que as pessoas aceitassem ou sequer que compreendessem o que é uma política de privacidade de um provedor de tráfego ou de uma "middlebox" de inspeção.
Sem encriptação, as informações de navegação na Internet são implicitamente partilhadas com inúmeros terceiros online, porquanto a informação vai passando entre as redes. Sem roteamento seguro, o tráfego dos utilizadores pode ser sequestrado e perturbado. Sem protocolos de salvaguarda da privacidade, a vida dos utilizadores online não é tão privada quanto eles pensam ou esperam. A infraestrutura da Internet não foi construída de uma forma que reflita as suas expectativas.
A boa notícia é que a Internet está em constante evolução. Um dos grupos que ajuda a orientar essa evolução é o Internet Architecture Board (IAB), que providencia supervisão arquitetónica ao Internet Engineering Task Force (IETF), o principal órgão de definição de padrões para a Internet. O IAB publicou recentemente o RFC 8890, que afirma que os utilizadores finais individuais devem ser a prioridade aquando da conceção de protocolos de Internet. Declara que, se houver um conflito entre os interesses dos utilizadores finais e o interesse dos provedores de serviços, corporações ou governos, as decisões do IETF devem favorecer os utilizadores finais. Um dos principais interesses dos utilizadores finais é o direito à privacidade, pelo que o IAB publicou o RFC 6973 para indicar como os protocolos da Internet devem levar em conta a privacidade.
As publicações técnicas no blog de hoje são sobre melhorias na Internet que foram projetadas para respeitar a privacidade do utilizador. A privacidade é um tópico complexo e que abrange diversas disciplinas, por isso, é importante ser claro sobre o que queremos dizer com “melhorar a privacidade”. Falamos especificamente sobre alterar os protocolos que lidam com informações sensíveis em relação à privacidade e que agora estão expostas “on-the-wire” (na rede), modificando-as para que esses dados fiquem expostos a menos intervenientes. Esses dados continuam a existir, apenas já não estão disponíveis ou visíveis para terceiros sem criar um mecanismo que os recolha numa camada mais elevada da pilha da Internet, a camada de aplicações. Estas mudanças vão além da encriptação do site; atingem a fundo o design dos sistemas que são fundamentais para fazer da Internet o que ela é.
A caixa de ferramentas: criptografia e proxies seguros
Duas ferramentas para garantir que os dados possam ser usados sem serem vistos são a criptografia e os proxy seguros.
A criptografia permite que a informação seja transformada num formato que um número muito limitado de pessoas (que têem a chave) pode compreender. Alguns descrevem a criptografia como uma ferramenta que transforma problemas de segurança de dados em problemas de gestão de chaves. Esta é uma descrição bem-humorada, mas justa. A criptografia torna mais fácil racionalizar a privacidade, pois apenas os titulares de chaves podem visualizar dados.
Outra ferramenta para proteger o acesso aos dados é o isolamento/segmentação. Ao limitar fisicamente que partes têm acesso aos dados, o utilizador constrói eficazmente muros de privacidade. Uma arquitetura comum é confiar nos proxy com reconhecimento de políticas para transmitir dados de um lugar para outro. Esses proxy podem ser configurados para retirar dados sensíveis ou bloquear transferências de dados entre as partes, de acordo com o que a política de privacidade diz.
Ambas as ferramentas são eficazes, individualmente, mas podem ser ainda mais eficazes se combinadas. O roteamento em cebola (a técnica criptográfica subjacente ao Tor) é um exemplo de como os proxies e a criptografia podem ser usados em conjunto para impor uma privacidade forte. No geral, se o sujeito A quiser enviar dados ao sujeito B, eles podem encriptar os dados com a chave do sujeito B e encriptar os metadados com uma chave de proxy, enviando-os para o proxy.
As plataformas e serviços construídos sobre a Internet podem incluir sistemas de consentimento, como as políticas de privacidade apresentadas através de interfaces de utilizador. A infraestrutura da Internet depende de camadas de protocolos subjacentes e, uma vez que essas camadas da Internet se encontram tão abaixo de onde o utilizador interage com elas, é quase impossível construir um conceito de consentimento do utilizador. Para respeitar os utilizadores e protegê-los contra problemas de privacidade, os protocolos que agregam a Internet devem ser projetados tendo a privacidade pré-ativada.
Dados vs. metadados
A transição de uma web maioritariamente não encriptada para uma web encriptada tem feito muito pela privacidade do utilizador final. Por exemplo, o “coffeeshop stalker” já não é um problema para a maioria dos sites. Ao aceder à maioria dos sites online, os utilizadores já não estão a difundir todos os aspetos da sua experiência de navegação na web (consultas de pesquisa, versões do navegador, cookies de autenticação, etc.) pela Internet, para que qualquer participante no caminho os possa ver. Se um site estiver configurado corretamente para usar HTTPS, os utilizadores podem ter certeza de que os seus dados estão seguros contra mirones e que alcançam apenas o destinatário pretendido, porque as suas ligações são encriptadas e autenticadas.
No entanto, o HTTPS protege apenas o conteúdo das solicitações da web. Mesmo que navegue apenas em sites sobre HTTPS, isso não significa que os seus padrões de navegação sejam privados. Isto acontece porque o HTTPS não consegue encriptar um aspecto importante da troca: os metadados. Quando faz uma chamada telefónica, os metadados representam o número de telefone, não o conteúdo da chamada. Os metadados são dados sobre os dados.
Para ilustrar a diferença - e o porquê de isso ser importante -, aqui está um diagrama do que acontece quando visita um site como uma galeria de imagens. Digamos que vai para uma página específica dessa galeria (https://<imageboard>.com/room101/) que tenha imagens específicas incorporadas hospedadas em <embarassing>.com.
O espaço dentro da linha tracejada representa aqui a parte da Internet de que os seus dados precisam para transitar. Incluem a sua rede local ou café, o seu ISP, podendo ser um provedor de tráfego de Internet ou a parte da rede do provedor de nuvem que aloja o servidor. Os utilizadores geralmente não têm uma relação com essas entidades, ou um contrato que impeça essas partes de fazer algo com os dados do utilizador. E mesmo se essas entidades não vissem os dados, um observador bem posicionado que intercetasse o tráfego da Internet poderia ver qualquer coisa que fosse enviada sem encriptação. Seria melhor se não o vissem, de todo. Neste exemplo, o facto de o utilizador ter visitado <imageboard>.com pode ser visto por um observador, o que é expectável. No entanto, apesar de o conteúdo da página estar encriptado, é possível saber que página específica visitou, uma vez que <embarassing>.com também fica visível.
A regra geral diz que se os dados estiverem disponíveis para as partes no caminho na Internet, algumas dessas partes usarão esses dados. Também é verdade que essas partes no caminho precisam de alguns metadados para facilitar o transporte desses dados. Este equilíbrio é explorado no RFC 8558, que explica como os protocolos devem ser cuidadosamente projetados no que diz respeito ao equilíbrio entre demasiados metadados (mau para a privacidade) e metadados diminutos (mau para as operações).
Num mundo ideal, os protocolos de Internet seriam desenhados com o princípio do menor privilégio. Forneceriam a quantidade mínima de informações necessárias para as partes no caminho (as tubagens) fazerem o trabalho de transportar os dados para o lugar certo, mantendo por defeito tudo o resto confidencial. Os protocolos atuais, incluindo o TLS 1.3 e o QUIC, são passos importantes para este ideal, mas ficam aquém no que toca à privacidade dos metadados.
Saber simultaneamente quem você é e o que faz online pode levar a que sejam traçados perfis
As comunicações de hoje refletem dois níveis de proteção de metadados: o primeiro envolve limitar a quantidade de metadados disponíveis para outros observadores (como ISPs), sendo que o segundo envolve limitar a quantidade de metadados que os utilizadores partilham com os próprios provedores de serviços.
Os nomes de "host" são um exemplo de metadados que têm de ser protegidos de observadores terceiros, coisa que o DoH e o ECH pretendem fazer. No entanto, não faz sentido ocultar o nome de host do site que está a visitar. Também não faz sentido ocultá-lo de um serviço de diretórios como o DNS. Um servidor de DNS precisa de saber qual é o nome de host que o utilizador está a tentar resolver para o poder resolver por ele!
Quando um provedor de serviços tem conhecimento sobre os sites que o utilizador está a visitar e quem ele é, deparamo-nos com um problema de privacidade. Os sites individuais não têm esta combinação arriscada de informações (exceto no caso de cookies de terceiros, que vão desaparecer em breve dos navegadores), mas os provedores de DNS têm. Felizmente, não é realmente necessário que um resolvedor de DNS conheça tanto o nome do host do serviço para onde vai e de que IP vem. Destrinçar os dois,que é o objetivo do OdoH,é bom para a privacidade.
A Internet faz parte da “nossa” Infraestrutura
As estradas devem ser bem alcatroadas, bem iluminadas, ter sinalização correta e estar idealmente interligadas. Não foram concebidas para parar um carro de acordo com quem está lá dentro. Nem devem ser! Como a infraestrutura de transporte, é da responsabilidade da infraestrutura da Internet levar os dados onde eles precisam de chegar, sem, no entanto, olhar para dentro dos pacotes e fazer julgamentos. Mas a Internet é feita de computadores e de software, e o software tem tendência a ser escrito para tomar decisões com base nos dados que lhe estão disponíveis.
Os protocolos de salvaguarda de privacidade tentam eliminar a tentação dos provedores de infraestrutura espreitarem e tomarem decisões baseadas nos dados pessoais que veem. Um protocolo que não salvaguarda a privacidade, como o HTTP, guarda dados pessoais e metadados, como palavras-chave, endereços de IP e nomes de host como partes explícitas dos dados enviados pela rede. O facto de serem explícitos significa que ficam disponíveis para qualquer observador os recolher e agir baseado neles. Um protocolo como o HTTPS melhora isto, tornando alguns dos dados (como palavras-chave e conteúdo do site) invisíveis na rede usando encriptação.
Os três protocolos que estamos a explorar hoje são uma extensão desse conceito.
- O ECH pega na maioria dos metadados não encriptados no TLS (incluindo o nome de host) e encripta-os com uma chave que foi apanhada antecipadamente.
- O ODoH (uma nova variante do DoH co-projetada pelos engenheiros da Apple e da Cloudflare) usa proxies e encriptação do tipo "cebola" para tornar a origem de uma consulta de DNS invisível aos olhos do resolvedor de DNS. Isto protege o endereço de IP do utilizador ao resolver nomes de host.
- O OPAQUE usa uma nova técnica criptográfica para manter as palavras-passe ocultas até mesmo do servidor. Ao usar uma construção chamada Oblivious Pseudo-Random Function - Função Pseudo-Aleatória Alheia - (como visto em Privacy Pass), o servidor não conhece a palavra-passe, só fica a saber se o utilizador a conhece ou não.
Ao garantir que a infraestrutura da Internet age cada vez mais como uma infraestrutura física, a privacidade do utilizador é protegida com maior facilidade. A Internet é mais privada se os dados privados só puderem ser recolhidos quando o utilizador tiver a oportunidade de consentir na sua recolha.
Fazêmo-lo juntos
Por mais que estejamos entusiasmados em trabalhar em novas formas de tornar a Internet mais privada, a inovação à escala global não acontece sozinha. Cada um destes projetos resulta do trabalho de um grupo colaborativo de indivíduos, que trabalham de forma aberta em organizações como o IETF e o IRTF. É crucial que os protocolos surjam através de um processo de consenso, envolvendo todas as partes que compõem o conjunto interligado de sistemas que alimentam a Internet. Desde construtores de navegadores, criptógrafos até operadores de DNS e administradores de sites, este é verdadeiramente um esforço de equipa global.
Também reconhecemos que mudanças técnicas abrangentes na Internet inevitavelmente terão impacto além da comunidade técnica. A adoção destes novos protocolos poderá ter implicações legais e políticas. Estamos a trabalhar ativamente com governos e grupos da sociedade civil para ajudar a educá-los sobre o impacto dessas possíveis mudanças.
Estamos ansiosos por partilhar o nosso trabalho hoje, esperando que mais partes interessadas se juntem ao desenvolvimento destes protocolos. Os projetos que estamos a anunciar hoje foram concebido por especialistas académicos, da indústria e por autodidatas, tendo sido construídos por engenheiros da Cloudflare Research (incluindo o trabalho de estagiários, que destacaremos) com o apoio de todos na Cloudflare.
Se está interessado neste tipo de trabalho, estamos a contratar!