Por que as transferências de email entre servidores de email geralmente não são criptografadas?

Os usuários geralmente podem escolher se desejam acessar seu provedor de e-mail (como o Gmail) usando um canal seguro (por exemplo, usando HTTPS).

No entanto, tanto quanto sei, quando se trata de comunicações de servidor de email para servidor de email, a maioria dos emails ainda é transferida em texto sem formatação e não criptografada, possibilitando a qualquer pessoa na rede a leitura de seu conteúdo.

Existem tecnologias que dão ao usuário algumas garantias de que seus e-mails são enviados com segurança de ponta a ponta? Por que não informar ao usuário quando a criptografia não é suportada e escolher se deseja que seu email ainda seja entregue?

No entanto, tanto quanto sei, quando se trata de comunicações de servidor de email para servidor de email, a maioria dos emails ainda é transferida em texto sem formatação e não criptografada, possibilitando a qualquer pessoa na rede a leitura de seu conteúdo.

Corrigir. SMTP, como HTTP, é texto sem formatação por padrão.

Atualmente, muitos servidores de correio suportam TLS (anteriormente conhecido como SSL) para SMTP. (Isso inclui o Gmail.) No entanto, ele tem os mesmos problemas do HTTP [S]: os certificados emitidos por CAs conhecidas custam dinheiro, e os autoassinados são inúteis ¹ para proteção contra ataques do MitM . Se o seu servidor de email fizer uma validação estrita do certificado do destinatário (como os navegadores da Web), poderá falhar na entrega de mensagens aos servidores que estão usando certificados autoassinados ou CAs internas. Caso contrário , não é possível ter certeza de que está falando com o servidor certo e não com um impostor .

Além disso, o TLS é uma adição relativamente recente ao SMTP, portanto, mesmo quando o servidor de email do destinatário oferece suporte ao TLS, o remetente pode não, ou pode estar desativado por padrão.

¹ (A menos que o servidor de envio ofereça suporte ao DANE (TLSA) e o administrador do servidor de recebimento se preocupe em publicar os registros TLSA no DNS. Isso raramente é feito e é um pouco tedioso.)

Existem tecnologias que dão ao usuário algumas garantias de que seus e-mails são enviados com segurança de ponta a ponta?

Dois padrões de segurança de email mais comuns:

• OpenPGP , baseado em rede de confiança e livre para usar. A implementação de código aberto é o GnuPG ( para Windows , para Thunderbird ) e o PGP original evoluiu para o PGP Desktop comercial .

  Para clientes de email baseados na Web, o FireGPG é uma possibilidade - caramba

• S / MIME , com base na infraestrutura X.509. Implementado pela maioria dos clientes de desktop (incluindo Outlook, Thunderbird, Mail.app). No entanto, relativamente impopular devido à mesma estrutura baseada em autoridade que o TLS / SSL: os certificados assinados custam dinheiro, e os autoassinados não podem ser validados com segurança.

Nos dois casos, a criptografia exige que o destinatário já esteja usando o sistema e tenha gerado / obtido um par de chaves. (Para assinar , é usado o par de chaves do remetente . A prática normal é assinar e criptografar mensagens.)

Por que não informar ao usuário quando a criptografia não é suportada e escolher se deseja que seu email ainda seja entregue?

Normalmente, as mensagens enviadas são colocadas na fila e nem o usuário nem o MTA podem saber se o próximo salto suporta TLS ou não - até que a mensagem seja enviada , momento em que não há uma maneira confiável de solicitar confirmação ao usuário. (Eles podem ser AFK, offline, adormecidos ou um script / programa. Se eu enviei a mensagem, desejo que ela seja entregue o mais rápido possível.)

Além disso, com o SMTP, você nunca sabe se o próximo salto é final ou se apenas retransmitirá o correio em outro lugar. Não é incomum que um MX de backup esteja em uma rede totalmente diferente.

Portanto. a segurança de ponta a ponta só é possível quando os dois lados estão usando OpenPGP ou S / MIME.

O tráfego de email real geralmente é criptografado (TLS), mas existem vários outros problemas:

• Alguns clientes de webmail que mostram mensagens HTML podem ser inseguros, embora usem HTTPS, não há uma separação rígida entre código e dados em HTML, por exemplo (elementos visuais e ataques javascript -> injeção)

  • O webmail também mantém o email no servidor em vez de fazer o download e armazená-lo no computador local

• Você não tem como saber se o TLS / SSL foi usado entre todas as etapas, servidores muito pequenos NÃO TÊM certificados adequados

  • o remetente deve pelo menos ser capaz de especificar se aceita ou falha o envio do email usando um canal não seguro

• Os emails estão em servidores não criptografados ou criptografados pelo servidor

  • você terá que confiar em CADA servidor entre você e o destinatário

• Talvez os e-mails sejam transferidos usando qualquer rota, você não pode especificar em quais servidores confia (intervalos de endereços IP, ASes, países, domínios ..)

• Servidores de email grandes não usam vários certificados diferentes e não os alteram com frequência suficiente (?)

  • talvez valha a pena / possível forçá-los a força bruta (como EUA / Reino Unido, etc, tentaram?)

• seguindo o tráfego, eles sabem quando o email foi enviado e algo sobre o destinatário (quais servidores se comunicam entre si)

  • redes escuras escondem essas correlações

• A implementação do openssl foi / está uma bagunça

  • talvez haja erros

• você precisa confiar nas autoridades de certificação que assinam os certificados

Eles são. Ou muitas vezes são.

Através de SSL ou TLS .

--- 220 mail.ovalpowered.com ESMTP Exim 4.72 Sun, 20 Mar 2011 17:09:56 +0000
+++ EHLO test
--- 250-mail.ovalpowered.com Hello vpnhub.sqsol.co.uk [213.229.101.173]
--- 250-SIZE 52428800
--- -PIPELINING
--- -AUTH PLAIN LOGIN
--- -STARTTLS
--- HELP
+++ STARTTLS
--- 220 TLS go ahead

Ou, se você é realmente paranóico, há PGP ou GPG.