Criptografia baseada na web é sempre enrolação

Artigo original ↗ Discussão no Hacker News ↗

Argumento central: criptossistemas incoerentes e criptografia na web

  • A tese central discutida: qualquer criptossistema é “incoerente” se a mesma entidade distribui o cliente e opera o serviço do qual ele supostamente protege, especialmente com atualizações automáticas.
  • Para apps web, JavaScript e service workers controlados pelo servidor podem ser alterados a qualquer momento, então o fornecedor pode remover ou enfraquecer silenciosamente a criptografia para usuários específicos.
  • Vários observam que isso se aplica não apenas a apps web, mas também a mensageiros proprietários “E2EE” e apps móveis com atualizações automáticas.

Confiança, atualizações e modelos de ameaça

  • Muitos comentários enfatizam: você sempre precisa confiar em quem fornece seu software; não é possível se proteger totalmente contra essa parte se tornar maliciosa ou ser coagida.
  • Atualizações automáticas (incluindo clientes com data de expiração) efetivamente dão aos fornecedores execução remota de código e a capacidade de inserir backdoors seletivamente.
  • Outros destacam os modelos de ameaça: E2EE ainda pode ser valiosa contra terceiros, vazamentos massivos de dados e pessoas de dentro, mesmo que não consiga se defender contra o fornecedor mais o governo dele.

Valor de E2EE vs TLS / alegação de “enrolação”

  • Críticos do artigo dizem que chamar criptografia na web de “snake oil” é exagerado e ignora benefícios reais:
    • Protege dados em repouso contra vazamentos de banco de dados e acesso casual/de pessoas de dentro.
    • Eleva a barra contra comprometimento simples e somente leitura do banco de dados.
  • Defensores respondem que, se o fornecedor pode enviar silenciosamente um keylogger ou um uploader de texto puro, afirmações como “não podemos ler suas mensagens” são, no máximo, marketing condicional.

Aspectos legais, de negócios e do governo

  • Alguns argumentam que E2EE também é uma estratégia legal: deslocar o ônus tornando o cumprimento de ordens de interceptação “impossível” na prática.
  • Outros veem incentivos reais de engenharia (redução de responsabilidade, prevenção de abuso interno), embora céticos questionem se eles superam os incentivos comerciais para vigilância ou cooperação com o governo.
  • Ameaças de estados-nação são debatidas: alguns veem E2EE baseada nos EUA como principalmente vulnerável a agências dos EUA; outros dizem que isso é em grande parte acadêmico para usuários típicos.

Mitigações e designs alternativos

  • Mitigações sugeridas: código aberto, builds reproduzíveis, distribuição anônima, armazenamento endereçado por conteúdo, atestação de código por terceiros (por exemplo, manifests no estilo WEBCAT, serviços externos de verificação de código) e protocolos com vários clientes independentes.
  • Vários observam que essas práticas são comuns em distribuições tradicionais de software, mas raras em apps web, o que torna a E2EE baseada na web particularmente frágil hoje.