ProtonMail reescreve o e-mail

 (jfloren.net)
1 pontos por GN⁺ 2023-07-09 | 1 comentários | Compartilhar no WhatsApp
  • Após o app Android do ProtonMail passar a enviar apenas parte de alguns e-mails quando eles eram enviados logo após a escrita, o usuário contornou o problema conectando outros clientes de e-mail via Proton Bridge
  • Executando o Bridge em uma VM no NAS e abrindo acesso IMAP/SMTP com rinetd e Tailscale, ele passou a usar a mesma conta no FairEmail no Android e no Claws no Linux
  • Ele configurou assinaturas PGP/MIME no FairEmail+OpenKeyring e no Claws, mas os e-mails de teste não foram reconhecidos como assinados em nenhum dos dois clientes
  • O mantenedor do Claws avaliou que a estrutura MIME estava quebrada, e issues antigas do Proton Bridge também apontam conflito entre o processamento automático de PGP do Proton e assinaturas feitas pelo usuário
  • O ponto central do problema é que o Proton modifica silenciosamente a mensagem, mas não oferece uma opção para preservar multipart/signed ou multipart/encrypted como estão

Problema no app Android e contorno com Proton Bridge

  • Depois de ficar insatisfeito com o Google e migrar para o ProtonMail alguns anos atrás, o serviço era em geral utilizável, mas há alguns meses o cliente Android começou a corromper o conteúdo dos e-mails
    • Se apertasse send rápido demais após terminar de digitar, apenas parte do conteúdo escrito era enviada
    • Para garantir o envio correto, era preciso esperar cerca de 10 segundos após digitar
  • O usuário então passou a usar outros clientes em vez do app do Proton, configurando o Proton Bridge em uma VM no NAS
    • O Proton Bridge escuta apenas em 127.0.0.1
    • Com o rinetd, ele encaminhou as conexões de entrada das portas IMAP e SMTP para o Bridge
    • Também configurou o Tailscale nessa máquina e no celular para conectar o cliente de e-mail Android à conta Proton
  • No Android, ele usou o FairEmail; no Linux, acessou com o Claws

Como a assinatura PGP/MIME quebra

  • Depois disso, ele adicionou configurações no cliente para anexar uma assinatura PGP às mensagens enviadas
    • Exportou para o dispositivo Android uma subchave dedicada apenas à assinatura
    • Configurou FairEmail+OpenKeyring
    • Também configurou o Claws no Linux para PGP/MIME
  • As mensagens de teste enviadas para si mesmo não foram reconhecidas como assinadas nem no Claws nem no FairEmail
    • Ao mudar para PGP inline, funcionava
    • O mantenedor do Claws respondeu que a estrutura MIME estava quebrada
    • Um e-mail assinado enviado pelo mantenedor foi verificado normalmente no Claws
  • Como casos relacionados mostrando que o Proton vem quebrando assinaturas PGP de saída desde o início, foram citados proton-bridge issue #26 e issue #320
  • O comportamento do Proton, resumidamente, é o seguinte
    • Quando um e-mail comum é enviado por meio do Proton para outro cliente Proton, o Proton executa automaticamente assinatura e criptografia PGP
    • Essa assinatura e criptografia automáticas não conseguem coexistir com assinaturas aplicadas manualmente pelo usuário
    • Como resultado, a assinatura aplicada pelo usuário é quebrada
  • O usuário considera que a principal falha é o fato de o Proton não oferecer uma opção para instruí-lo a deixar mensagens multipart/signed ou multipart/encrypted intactas
  • Embora reconheça que PGP não é amplamente usado, ele vê o Proton como um serviço que modifica silenciosamente os e-mails e responde às reclamações dos usuários com uma postura de “nós sabemos melhor”, e por isso está considerando outros provedores de e-mail

Leituras relacionadas

1 comentários

 
GN⁺ 2023-07-09
Comentários do Hacker News

  • Se você leu só o título e está pensando em largar o ProtonMail, o ponto de “reescrever e-mails” aqui é mais que o ProtonMail não oferece suporte a assinaturas PGP aplicadas pelo usuário por causa da forma como ele projetou o sistema de assinatura automática/criptografia
    Não quer dizer que ele sai reescrevendo arbitrariamente o corpo dos e-mails enviados no sentido que um usuário comum imaginaria
    Se você faz parte dos 99,9% que não assinam e-mails nem verificam assinaturas, provavelmente isso não é um grande problema na prática, mas ainda assim a resposta da Proton a essa questão parece uma piada
    https://github.com/ProtonMail/proton-bridge/issues/26

    • O ponto principal é que isso abala a confiança
      Se nem algo básico como PGP eles conseguem tratar direito, como confiar no resto do software, ainda mais quando a própria empresa se vende como “Privacy-first”
      Hoje em dia, “Privacy” parece estar virando só um termo de marketing
    • No fim, por mais que se escreva, a mensagem é a mesma: você vai acabar subindo sua chave privada para o servidor, e parece que esperam que você aceite isso

  • “Parece estar relacionado ao comportamento do ProtonMail de descartar todos os e-mails em texto puro se houver uma parte codificada em mime”
    https://github.com/ProtonMail/proton-bridge/issues/26#issuec...
    Na verdade, é ainda mais chocante que, se houver uma parte mime codificada como HTML, eles descartem a parte em texto puro
    Fui verificar e os e-mails importados do GMail e os e-mails novos recebidos no ProtonMail agora só mantêm a parte HTML, enquanto na visualização da mensagem original no GMail aparecem tanto a parte HTML quanto a de texto puro
    Isso significa que depois não dá mais para ler com um cliente somente texto, e nem é como se isso economizasse espaço de armazenamento; não entendo como acharam aceitável estragar isso
    O armazenamento é pago por mim

    • O Office365 faz exatamente a mesma coisa
      Do ponto de vista desses grandes fornecedores, no momento em que o e-mail entra no sistema deles ele deixa de ser e-mail no sentido original e vira o objeto deles
      Talvez hoje eles só façam alguma reconstrução por gentileza
    • É só um palpite, mas isso tem cheiro de enshittification
      Parece que estão piorando o produto enquanto economizam custos em algum lugar, torcendo para que clientes em número suficiente não percebam

  • Fico feliz que alguém tenha apontado especificamente como as pessoas odeiam essa atitude escorregadia de “nós sabemos melhor” quando reclamam
    Em vez de explicar que eu estou segurando errado, no mínimo é preciso admitir que eu não consigo fazer o que quero por causa de uma limitação do produto e então pensar se isso pode ser mudado

    • Passei a evitar ferramentas de software que se orgulham de ser “opinionated”
      Normalmente isso quer dizer use do nosso jeito ou vá embora
    • Onde exatamente estão explicando que “eu estou segurando errado”?
    • Já faz 5 anos que reportaram busca e envio automáticos via WKD no mobile, e até hoje isso não é suportado
      É bem absurdo

  • O ProtonMail é realmente péssimo
    Sempre que aparece uma thread dessas, acabo compartilhando o que passei quando tentei usar o ProtonMail para negócios
    O ProtonMail cobrava por conta, estivesse o e-mail ativo ou não, e quando um funcionário saía eu queria desativar o endereço mas manter o histórico de e-mails
    Só que exportar e-mails do ProtonMail é difícil a ponto de precisar de um engenheiro
    Então perguntei se eles poderiam adicionar um recurso para desativar permanentemente um endereço de e-mail e parar de cobrar por ele, e recebi a típica resposta evasiva estilo ProtonMail
    Eu já estava bastante insatisfeito porque a busca era pior do que uma simples busca por substring, e depois de alguns anos usando profissionalmente chega uma hora em que você precisa encontrar conversas antigas
    No fim cancelei a conta e fechei o cartão da privacy.com
    Um ano depois, ao ver que ainda havia cobrança mensal naquele cartão já encerrado, tentei entrar na minha conta antiga, mas a senha salva no gerenciador de senhas não funcionava
    Mandei um e-mail dizendo que parecia haver um bug, e depois de muita discussão o atendente do suporte exigiu informações do cartão de crédito para parar as cobranças
    Como era um cartão que eu já tinha encerrado um ano antes, eu não tinha essas informações, e naquele ponto parei de responder
    Para mim é um grande sinal de alerta confiar dados pessoais a gente que trata com hostilidade clientes pagantes que fazem perguntas razoáveis

    • Entendo a frustração, mas esse caso de uso empresarial parece não combinar com o propósito para o qual a Proton foi criada
      A Proton parece mais um serviço voltado a manter conversas totalmente privadas entre os destinatários, e o mais surpreendente para mim é que ainda fosse possível acessar os e-mails de um funcionário desligado
    • Uso o Proton VPN há bastante tempo e estava pensando em migrar do Gmail para o Proton Mail, mas talvez não seja uma ideia tão boa
      Para uso pessoal, o que você recomendaria?
    • Não quero soar arrogante, mas software não é imutável
      Como está isso hoje? Você chegou a usar o app de Import-Export do ProtonMail e a testar novamente a busca atual?

  • Fico chocado em saber que eu não era o único a passar pelo bug em que, ao tocar em “enviar” rápido demais no cliente Android, só parte do que foi escrito era enviada
    Vários e-mails que enviei para meu médico e meu consultor financeiro foram truncados desse jeito, e eu lembrava claramente de ter digitado tudo, então cheguei a suspeitar seriamente que o remédio que tomo por causa do tratamento contra o câncer estivesse causando algum tipo de alucinação breve

    • Sou líder de produto de e-mail e conhecemos esse problema específico que afeta alguns usuários; estamos trabalhando na correção
      Na verdade, estamos reescrevendo todo o app Android, então ele deve ficar mais estável e mais fácil de usar, e deve sair no fim deste ano
      Até lá, se você tiver problemas recorrentes de envio no app Android do Proton Mail, pode usar o web app (https://mail.proton.me) em qualquer dispositivo
    • É triste que isso ainda não tenha sido corrigido
      Qual é o sentido de um serviço de e-mail se ele não consegue enviar e-mails direito?
      Passei por esse bug em um momento importante, e isso me faz pensar no que teria acontecido se o destinatário tivesse simplesmente ignorado o e-mail vazio sem me avisar
    • É um pouco assustador o quanto dependemos de tecnologia a ponto de questionarmos nossa saúde mental quando a tecnologia falha
    • Eu também passei por muita coisa ruim por causa desse problema
      Agora estou procurando um provedor mais confiável, onde eu possa usar um cliente de e-mail de verdade, que faça IMAP/SMTP corretamente e lide com GPG
    • Já aconteceu de eu apertar enviar explicitamente e, ainda assim, o e-mail não ser enviado
      Isso é regressão e bug de desenvolvimento de aplicativo; talvez fazer um ótimo produto seja pouco interessante demais para a Proton

  • Ainda me surpreende que a Apple ainda não tenha tentado tornar o processo de PGP mais fluido
    Eu imaginava algo como gerar as chaves no dispositivo, sincronizar pelo iCloud e depois publicar a chave pública
    Como a Apple faz tanta questão de privacidade, eu esperava que isso levasse Gmail, Outlook e outros a adotarem PGP nativo, mas pelo visto era só desejo meu

    • Há problemas demais de caso de uso em PGP e e-mail, a ponto de a maioria dos profissionais de segurança realmente sérios nem se dar ao trabalho de usar PGP
      Isso foi empurrado para o nicho dos usuários de nicho e dos entusiastas, e há tantos problemas que é melhor usar plataformas alternativas de mensagens, como o Signal, que foram criadas desde o início com criptografia em mente
      Por exemplo, se você envia um e-mail criptografado e o destinatário o encaminha, o que acontece?
      Quando o destinatário responde, o e-mail original será incluído ainda criptografado ou já descriptografado? Normalmente é o segundo caso, então o mesmo texto em claro passa a existir em duas mensagens
      Se você envia um e-mail para várias pessoas, quem faz a criptografia separada para cada destinatário?
      Se só alguns destinatários suportam criptografia, qual é o sentido da criptografia se parte da mensagem vai em texto puro de qualquer forma?
      Como fazer ao enviar para uma mailing list em que você não sabe quem são os participantes?
      O que deve ser criptografado por padrão? Só o corpo? O cabeçalho do e-mail, como o assunto? E os outros cabeçalhos?
      Mesmo que você queira apenas assinatura, o que exatamente deve ser assinado por padrão? O texto da conversa passa por várias transformações; como essa assinatura sobreviveria?
    • No caso da Apple, talvez ela criasse um protocolo de e-mail totalmente novo para tentar fazer e-mail criptografado funcionar
      O usuário escreveria o endereço do destinatário, o servidor verificaria esse endereço, pediria a chave de criptografia ao host de e-mail, o host enviaria a chave, e o usuário continuaria escrevendo o e-mail
      Algo com uma sensação parecida com HTTPS sobre UDP
    • A Apple leva privacidade e segurança bem a sério, e o PGP, nesse espectro, está muito mais próximo de segurança de vitrine do que de “seriedade”
    • Acho que ninguém vai fazer isso
      E-mail criptografado não funciona direito
      https://latacora.micro.blog/2020/02/19/stop-using-encrypted....
    • O Google oferece criptografia do lado do cliente para empresas, mas usa S/MIME, não PGP
      https://support.google.com/a/answer/10741897
      https://security.googleblog.com/2023/06/gmail-client-side-en...

  • Se a empresa de e-mail tem a chave privada, qual é o sentido do PGP?
    O que sobra é só a segurança durante o transporte do e-mail pela rede e algo de verificação de assinatura?
    Compartilhar a chave privada parece uma forma estranha de manter segredos

    • Um amigo estava em um local remoto e, como não tinha os arquivos diretamente, pediu que eu enviasse arquivos .gpg criptografados
      Só que houve casos em que ele não conseguia baixar alguns deles
      Depois de testar e enviar um bug report, a ProtonMail respondeu que tenta descriptografar os anexos presumindo que eles foram criptografados com a chave do endereço do usuário
      Disseram que, ao restaurar e recriar o nome original do arquivo, a extensão .gpg é removida
      O mais surpreendente foi a ProtonMail ter sugerido, como solução alternativa, que ele importasse a chave privada correspondente à chave pública do anexo, e meu amigo não concordou com isso
    • A Proton não tem a chave privada em texto puro
      Ela armazena a chave privada criptografada com a senha do usuário, e nós também não sabemos essa senha

  • Há também uma issue de 2 anos atrás
    https://github.com/ProtonMail/proton-bridge/issues/180
    A Proton dificulta para desenvolvedores de software open source enviarem patches, e não parece se importar
    https://git-send-email.io/#step-2
    Lá até aparece a frase: “O Protonmail é amplamente conhecido como um host de e-mail bem ruim. Ele pode quebrar e-mails enviados e fazer com que patches não sejam aplicados do outro lado. Sem falar no tratamento injusto ao open source e nas promessas falsas sobre segurança. Você deveria considerar outro provedor de e-mail”
    Ainda bem que consegui mudar de barco em uma semana e receber reembolso total

  • Há uma ironia em eu ter percebido que enviei um link http ao postar um texto reclamando de segurança

    • Pior ainda: jfloren.net não está na lista de preload de HSTS
    • É um post de blog que permite acesso anônimo; que diferença faz qual protocolo ele usa?

  • A configuração de subir o Proton Bridge em uma máquina virtual no NAS, encaminhar com rinetd as conexões de entrada das portas IMAP/SMTP para um bridge escutando apenas em 127.0.0.1, e configurar tailscale nessa máquina e no celular para acessar a conta Proton com um cliente de e-mail no Android (preferência pelo FairEmail) e com o Claws no Linux, soa bastante parecida com boa parte da complexidade de auto-hospedagem

    • Sempre que e-mail é discutido aqui, pessoas acostumadas com auto-hospedagem dizem que é quase impossível fazer o Gmail não marcar seus e-mails como spam
      Não sei por experiência própria, mas é um tema que reaparece com frequência