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 1 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.
1 (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.