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

Question

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, de acordo com o meu conhecimento, quando se trata de comunicações de servidor de email para servidor de email, a maioria dos emails ainda é transferida em texto simples e não criptografada, tornando possível a qualquer pessoa na rede ler seus 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 deixá-lo escolher se ele deseja que seu e-mail continue sendo entregue?

    

Answer 1

However, to the best of my knowledge, when it comes to mail-server-to-mail-server communications, most emails are still transferred in plain text and not encrypted, making it possible to anybody on the network to read their content.

Correto. O SMTP, como o HTTP, é um texto simples por padrão.

Atualmente, muitos servidores de e-mail oferecem suporte a TLS (anteriormente conhecido como SSL) para SMTP. (Isso inclui o Gmail.) No entanto, ele tem os mesmos problemas que com os certificados HTTP [S]: emitidos por CAs bem conhecidos. > custam dinheiro, e os auto-assinados são inúteis para proteger contra ataques MitM . Se o seu servidor de e-mail fizer uma validação estrita do certificado do destinatário (como os navegadores da web), ele poderá falhar ao enviar mensagens para servidores que estejam usando certificados autoassinados ou CAs internas. Se não , então não pode ter certeza de que está falando com o servidor certo e não 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 a TLS, o remetente pode não estar ativado ou desativado (os administradores de sistemas são espécies com preguiça).

Are there any technologies that give the user some guarantees that his emails are sent securely from end to end ?

Dois padrões de segurança de e-mail mais comuns:

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

  Para clientes de e-mail baseados na Web, FireGPG é uma possibilidade - droga

• 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 auto-assinados não podem ser validados de forma confiável.

Em ambos os casos, criptografia requer que o destinatário já esteja usando o sistema e tenha gerado / obtido um par de chaves. (Para assinar , o par de chaves do remetente é usado. O uso normal é assinar e criptografar as mensagens.)

Why not let the user know when encryption is not supported and let him choose if he wants his email to be still delivered ?

Normalmente as mensagens enviadas são enfileiradas , 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 , na qual ponto não há maneira confiável de pedir ao usuário para confirmação. (Eles podem ser AFK, offline, dormindo ou um script / programa. Se eu enviei a mensagem, quero 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 email para outro lugar. Não é incomum que um MX de backup esteja em uma rede totalmente diferente.

Portanto. segurança end-to-end só é possível quando ambos os lados estão usando OpenPGP ou S / MIME.

    

Answer 2

O tráfego de e-mail real é geralmente criptografado (TLS), mas há vários outros problemas:

• Alguns clientes de webmail que exibem mensagens em HTML podem estar inseguros, embora usem HTTPS; por exemplo, não há separação entre o código e os dados em HTML (elementos visuais e javascript - > ataques por injeção)

  • webmail também mantém e-mail no servidor em vez de baixar e armazenar para o 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 apropriados

  • o remetente deve, pelo menos, ser capaz de especificar se aceita ou falha enviando o email usando o canal inseguro

• E-mails colocados em servidores não criptografados ou criptografados pelo servidor

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

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

• Grandes servidores de e-mail não usam vários certificados diferentes e não alterá-los com freqüência suficiente (?)

  • é talvez valioso / possível forçá-los (como EUA / UK 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)

  • darknets ocultam essas correlações

• a implementação do openssl foi / é uma bagunça

  • talvez haja bugs

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

Answer 3

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 paranoico, há PGP ou GPG.