TLS vs Encriptação Ponto-a-Ponto: O Que Saber

O TLS (Transport Layer Security) encripta dados enquanto viajam entre o seu dispositivo e um servidor, desencriptando-os na chegada — o que significa que o operador do servidor pode ler os seus ficheiros em texto simples. A encriptação ponta-a-ponto (E2EE) encripta o conteúdo no dispositivo do remetente com uma chave que apenas o destinatário possui, pelo que os servidores nunca veem os dados não encriptados. O ícone de cadeado no browser não indica qual das duas está realmente em uso — e essa distinção tem implicações diretas ao abrigo do RGPD, Artigo 32.

O que o TLS realmente protege

O TLS 1.3, normalizado na RFC 8446, é o protocolo que alimenta todas as ligações HTTPS. Negoceia uma chave de sessão usando ECDHE com curvas como X25519, autentica o servidor com um certificado X.509, e envolve o tráfego HTTP em AES-128-GCM ou ChaCha20-Poly1305. Trata-se de uma proteção excelente contra o atacante do Wi-Fi de uma cafetaria ou um ISP que tenta ler os seus pedidos.

O que o TLS não faz: termina no balanceador de carga. Quando faz o upload de um vídeo de 3 GB para um serviço típico de partilha de ficheiros, o TLS desencripta na borda e o ficheiro em texto simples vai parar a um bucket S3, a um pipeline de transcodificação, talvez a uma tarefa de análise de conteúdo por ML, e finalmente ao fluxo de download do destinatário — que é re-encriptado com uma nova sessão TLS. O serviço tem acesso completo de leitura em cada etapa.

Onde começa e acaba a encriptação ponta-a-ponto

A verdadeira E2EE move a fronteira da encriptação do servidor para os endpoints. No browser ou cliente do remetente, uma chave simétrica (tipicamente AES-256-GCM) é gerada em memória. O ficheiro é encriptado fragmento a fragmento antes de um único byte sair do dispositivo. O texto cifrado é carregado via TLS para o servidor, que armazena blobs opacos. O destinatário recebe a chave de desencriptação através de um canal separado — mais frequentemente como um fragmento de URL após o símbolo #, que os browsers nunca transmitem aos servidores.

O servidor, neste modelo, é uma camada de armazenamento burra. Mesmo um mandato judicial completo, um funcionário desonesto com acesso à base de dados, ou um fornecedor de nuvem a ler snapshots do disco, apenas produziria bytes encriptados. Esta é a arquitetura que o HexaTransfer usa: AES-256-GCM com uma chave por transferência derivada do lado do cliente e nunca transmitida à origem.

Comparação: TLS exclusivo vs Encriptação Ponta-a-Ponto

| Propriedade | Transferência apenas TLS | Encriptação ponta-a-ponto | |---|---|---| | Cifra em trânsito | AES-128/256-GCM | AES-256-GCM (mais TLS) | | Servidor vê texto simples | Sim | Não | | Localização da chave | Gerida pelo servidor | Dispositivo do remetente | | Proteção contra mandato judicial | Nenhuma | Forte | | Análise de conteúdo pelo fornecedor | Possível | Impossível | | Recuperação se perder a chave | Fornecedor pode ajudar | Dados irrecuperáveis | | Serviços típicos | Google Drive, Dropbox | HexaTransfer, SwissTransfer modo E2EE |

Como a troca de chaves realmente funciona

A parte difícil da E2EE não é a cifra — o AES é sólido há 25 anos. A parte difícil é levar a chave do remetente ao destinatário sem que o servidor a veja. Os serviços de transferência de ficheiros usam tipicamente um de três padrões.

O primeiro é o truque do fragmento de URL: a ligação tem o aspeto https://hexatransfer.com/d/abc123#key=xyz, onde tudo depois de # fica no browser. O JavaScript lê-o localmente e desencripta. O segundo é a encriptação baseada em palavra-passe, em que o remetente escolhe uma frase-passe, executa-a através de PBKDF2 (RFC 8018) ou Argon2id com 600.000+ iterações, e partilha a palavra-passe fora de banda via Signal ou uma chamada telefónica. O terceiro é a troca de chave pública usando bibliotecas como crypto_box da libsodium, em que o destinatário publica uma chave pública X25519.

Quando o TLS exclusivo é suficiente

Nem todos os ficheiros precisam de E2EE. Se está a partilhar um comunicado de imprensa com um jornalista, um meme com o grupo de conversa, ou um PDF de marketing público, os serviços apenas com TLS são perfeitamente adequados. Os dados não eram sensíveis para começar, e o facto de o fornecedor os ler não cria nenhum risco. Está a otimizar para conveniência — pré-visualizações, miniaturas, edição no browser — e essas funcionalidades requerem fundamentalmente acesso ao texto simples do lado do servidor.

O cálculo muda com imagens médicas (ficheiros DICOM cobertos ao abrigo do RGPD), extratos financeiros sob o PCI DSS 4.0 Requisito 3.5.1, materiais de descoberta legal, documentos de fusões e aquisições, ou qualquer coisa que contenha dados pessoais de cidadãos da UE ao abrigo do Artigo 32 do RGPD. Aqui, "o fornecedor pode tecnicamente ler isto" é um problema de conformidade, não apenas uma questão de preferência de privacidade.

O fosso de metadados de que ninguém fala

Mesmo com E2EE perfeita, o servidor ainda vê metadados: carimbo de tempo do upload, tamanho do ficheiro, endereços IP do remetente e do destinatário, strings de user-agent, duração da transferência. Se o modelo de ameaça inclui análise de tráfego — um jornalista a comunicar com uma fonte, por exemplo — isto é relevante. Um ficheiro de 147 MB carregado às 3h14 de um escritório da Reuters para um número Signal em Lisboa conta uma história mesmo que o conteúdo seja texto cifrado.

Os bons serviços de E2EE minimizam a retenção de metadados. Procure janelas de retenção de registos curtas (7 dias ou menos), sem necessidade de conta de utilizador para transferências básicas, sem análises de terceiros nas páginas de transferência, e idealmente políticas favoráveis ao encaminhamento onion ou VPN. A suite de cifras importa menos do que a higiene operacional à sua volta.

Como verificar a afirmação

"Encriptação ponta-a-ponto" é texto de marketing até que possa prová-la. Três testes separam a E2EE real da de fachada. Primeiro, abra as DevTools e observe o separador de rede durante um upload — se o corpo do ficheiro sair como multipart/form-data em texto simples, está a olhar apenas para TLS. Segundo, verifique se o URL de desencriptação contém um fragmento (#). Sem fragmento, sem chave do lado do cliente. Terceiro, leia a política de resposta a mandatos judiciais do serviço: se puderem produzir o conteúdo de ficheiros para as autoridades, os ficheiros não têm E2EE. Os serviços que publicam canários de mandatos e disponibilizam o seu código de encriptação em open source (repositórios GitHub que mostram o uso da WebCrypto API) oferecem a garantia mais forte.

Para envios quotidianos de ficheiros grandes em que a confidencialidade é importante, escolha um serviço que seja explícito quanto ao seu modelo. Experimente em hexatransfer.com — gratuito, sem conta, máximo de 10 GB.