A encriptação ponta a ponta é uma camada adicional, não uma licença para ignorar avisos TLS ou confiar em código adulterado.
O TLS e a encriptação ponta a ponta estabelecem duas fronteiras diferentes. Essas fronteiras também importam na avaliação de VPNs e proxies. O TLS normalmente protege a ligação entre o seu dispositivo e o serviço; a encriptação ponta a ponta correta e autenticada protege o conteúdo da conversa até ao dispositivo do destinatário. Ler a camada TLS não significa necessariamente ler o conteúdo encriptado ponta a ponta, mas isso não permite concluir que a segurança do TLS deixou de importar.
Se um intermediário conseguir terminar a ligação segura, poderá não só observar os dados transmitidos, mas também alterar respostas ou o código da aplicação web. Por isso, “contornar o TLS com LVR1” não é uma descrição adequada da segurança de uma aplicação de mensagens.
Como permite um certificado raiz fazer inspeção?
Numa ligação HTTPS, o dispositivo verifica a cadeia de certificados do servidor e o nome do anfitrião. Se um intermediário apresentar um certificado que a aplicação considere válido, poderá criar duas ligações separadas: uma com o utilizador e outra com o servidor real. Nesse caso, o intermediário é a extremidade de uma das ligações TLS, não alguém que quebrou a encriptação simplesmente observando os pacotes.
Instalar um certificado arbitrário não basta; a aplicação tem de confiar nele e as verificações da ligação também têm de ser aprovadas. A documentação de configuração de segurança de rede do Android explica que a política de confiança pode variar de aplicação para aplicação. As aplicações que têm como alvo o Android 7.0 ou superior não confiam, por predefinição, em certificados adicionados pelo utilizador, salvo se tiverem outra configuração.
Este é um mecanismo técnico geral. Sem provas, não permite tirar conclusões sobre um operador, país ou incidente específico. Uma interrupção ou filtragem, por si só, não prova uma inspeção TLS bem-sucedida.
O que se vê quando o TLS é aberto?
| Tipo de dados ou situação | Possível consequência da inspeção TLS |
|---|---|
| Conteúdo protegido apenas por HTTPS | O intermediário de confiança poderá ver o texto em claro |
| Mensagem já encriptada com a chave válida do destinatário | O intermediário normalmente vê texto cifrado, não o texto da mensagem |
| Dados de encaminhamento, sessão ou pedidos auxiliares | O grau de exposição depende do formato e da conceção do serviço |
| Código da versão web entregue pelo mesmo caminho | Alterar o código pode ameaçar a segurança do dispositivo terminal |
| Serviço indisponível ou tráfego bloqueado | A encriptação, por si só, não estabelece a ligação |
A proteção de conteúdo proporcionada pela E2EE também depende da autenticidade da chave do destinatário e da integridade do software de ambas as partes. Se um atacante substituir a chave inicial ou adulterar a aplicação que vê a mensagem antes da encriptação, a simples presença de AES ou ML-KEM não basta.
Porque precisa a versão web de TLS seguro?
Uma aplicação web normalmente recebe código executável do servidor. Se esse código for malicioso, pode aceder ao conteúdo antes da encriptação ou depois da desencriptação. Não se pode avaliar a encriptação ponta a ponta independentemente da forma como o código é entregue e executado.
Na versão instalada, também importam a autenticidade do pacote, as atualizações e a integridade do sistema operativo. A assinatura do pacote e a verificação do hash são úteis, mas não constituem um teste completo da segurança da aplicação. O modelo de ameaças da Livara também afirma que, se um atacante alterar tanto o ficheiro como o hash apresentado, a correspondência do hash, por si só, não prova a autenticidade.
O que afirma a Livara?
Segundo a documentação de segurança da Livara, as mensagens diretas usam LVR1 e os grupos privados compatíveis usam LGS1. A documentação descreve a combinação de P-256 e ML-KEM-768 e a encriptação do conteúdo das mensagens. Estas descrições são afirmações sobre o produto, não resultados de uma auditoria independente neste artigo.
A mesma página também refere a conservação de metadados de encaminhamento e o caráter público dos canais de publicação. Assim, a conclusão correta não é que “todas as informações ficam ocultas” ou que “não é necessária qualquer confiança na rede”. A conclusão é que a proteção de conteúdo privado deve ser analisada separadamente da ligação, da entrega das chaves, do código da aplicação e dos metadados.
O que fazer perante um aviso de certificado?
- Não ignore um aviso do navegador ou da aplicação para continuar uma conversa sensível.
- Verifique a data do dispositivo e o endereço exato do serviço; nem todos os erros de certificado são ataques.
- Se o dispositivo pertencer a uma organização, pergunte ao administrador autorizado sobre a política de gestão e os certificados instalados; não altere por iniciativa própria as definições geridas.
- Não instale um certificado ou perfil apenas porque uma mensagem desconhecida o pede.
- Em conversas sensíveis, compare a impressão digital da chave com o interlocutor através de um canal independente; verificar a chave não substitui a resolução do aviso TLS.
Perguntas frequentes
Uma VPN resolve todos estes problemas?
Não. Uma VPN pode alterar o percurso de observação do tráfego, mas não corrige automaticamente um dispositivo infetado, um certificado de confiança malicioso ou código web adulterado.
Basta autenticar sem enviar uma palavra-passe?
Não. O protocolo de autenticação, a gestão de sessões e a encriptação de mensagens têm funções diferentes. Uma página de início de sessão falsa ou código malicioso pode captar a própria entrada do utilizador antes de o protocolo ser executado.
Princípio prático: A E2EE é uma camada valiosa; não a encare como autorização para ignorar certificados, a autenticidade da aplicação ou a verificação das chaves.
