Existem vários problemas com o transporte de e-mail de uma maneira segura e essas perguntas podem ser feitas com mais facilidade em security.stackexchange.com. O correio pode ser interceptado em vários estágios:
- TLS explícito (STARTTLS) e TLS implícito (SMTPS) fornecem salto a salto e não segurança de ponta a ponta, ou seja, cada servidor de correio entre tem acesso ao correio não criptografado.
- O próximo salto para um email é determinado pela pesquisa do registro MX via DNS. Isso pode ser falsificado, a menos que o DNSSec seja usado, o que não é o caso. Se for falsificado, mesmo a verificação adequada dos certificados no handshake TLS não ajudará, porque verificará se a conexão com o MTA errado é a correta.
- O MX é definido apenas para usar o servidor na porta 25, ou seja, com o TLS explícito (STARTTLS). Como não há como o MTA transmissor saber se o MTA receptor suporta até STARTTLS, a conexão pode ser reduzida a um invasor man-in-the-middle, modificando a lista de extensões suportadas na resposta ao comando EHLO ou negando o comando STARTTLS. E mesmo hackers sem meios de interceptar a conexão diretamente podem injetar pacotes TCP RST no início do handshake TLS, de modo que o cliente pense que há problemas ao usar o TLS e voltará ao texto simples. Como existem problemas reais reais com o handshake TLS, o cliente pode não suspeitar.
- E, no handshake TLS, muitas vezes não é feita uma validação adequada. Às vezes, nenhum certificado é verificado, às vezes apenas a cadeia, mas não se o nome do host corresponder, etc. Mas, novamente, se o MX já estiver falsificado, a validação pode ser feita contra o servidor errado: (
O que significa que, para fazer com que pelo menos a criptografia hop-by-hop seja segura o suficiente, você precisa adicionar correções não-triviais a vários locais e a maioria deles não está no controle de um MTA de envio.
Para entrar em detalhes nas perguntas dos comentários:
1.) Is STARTTLS normally implemented between servers or does it start from client-server and proceed from hop to hop?
STARTTLS deve ser implementado em cada salto (MTA). Ele pode ser usado somente se o MTA de recebimento suportar STARTTLS e o MTA de envio puder fazê-lo. Não depende de como o email foi entregue ao salto inicial (MTA) do cliente. Geralmente, o TLS com SMTP criptografa apenas a conexão entre os saltos, para que ele possa ser lido em clareza em cada salto, se não for criptografado de ponta a ponta (com PGP ou S / MIME).
2.) Can mail encrypted by PGP or S/ MIME still be redirected by MX spoofing?
Sim, ainda pode ser redirecionado. Mas o correio em si só pode ser descriptografado pelo destinatário real, ou seja, o proprietário da chave de destino.
3.) Does DNSSEC have to be adopted on a wide scale to be useful or is it something an individual can benefit from by configuring on his own email server?
Cada bit ajuda, mas só um pouco. E observe que ele não precisa apenas dos registros DNSSec, mas o MTA de encaminhamento deve realmente usar o DNSSec. A maioria dos MTA provavelmente faz apenas DNS e não percebe se eles obtêm um registro MX falsificado.
4.) Do you have to worry about TCP RST injection for implicit tls or just explicit?
O TLS implícito é usado apenas do cliente para o MTA, ou seja, para o salto inicial. Essa é a etapa mais segura, porque ela está realmente no controle do cliente e o cliente usa normalmente um servidor SMTP fixo com configurações de TLS fixas, portanto, nenhum problema com o spoofing MX e os downgrades de conexão. Se o cliente estiver configurado para usar o TLS somente se disponível, o ataque também poderá funcionar contra o TLS implícito.
5.) Can't you configure the server/MTA to drop connection (bounce email) if other MTA isn't TLS compatible i.e. switch from opportunistic to required, or is that something you can only do on the client (like Thunderbird) for client-server connection?
A maioria dos servidores pode ser configurada dessa maneira, mas a maioria dos servidores precisa conversar com vários servidores e eles não sabem de antemão se o servidor suportará o TLS. Mas o sendmail, por exemplo, pode ser configurado para falar apenas com o TLS para servidores específicos ou para não conversar com o TLS em outros servidores específicos. Portanto, essa configuração pode ser reforçada para bons servidores conhecidos, mas isso deve ser feito manualmente.
6.) If #5 is possible and email bounces, will sender receive a 'failed to send' notice?
Sim, geralmente é esse o caso, como acontece com todos os erros de entrega. Mas, como a maioria dos outros erros de entrega, somente pessoas tecnicamente adequadas podem entender essas mensagens de erro.
7.) As far as certificates not getting checked, is that something that can be fixed with proper configuration/implementation. I read that one of the issues was that a lot of certificates are self signed and most MTA's accept them by default so they can stay compatible with more MTA's. Is that part of what you were referring to?
Depende do servidor. Lat tempo eu olhei o postfix estava bem, mas o sendmail não pôde verificar corretamente o nome do host contra o certificado. E sim, autoassinado é um problema e o outro problema principal está faltando certificados intermediários. Mas, como a entrega de mensagens funciona de qualquer maneira (como os erros de certificado são ignorados pelo remetente), a maioria dos administradores não percebe a configuração incorreta ou não se importa.
8.) Lastly, say all non-trivial fixes were put in place, and i understand the other MTA/client is out of my control. Can these MITM and injection attacks target specific connections going to and from my email address? In this situation they haven't broken into my server and they have no previous experience with my contacts.
Mais uma vez, trata-se apenas de criptografia hop-by-hop e o correio está disponível para leitura e modificação em cada um dos saltos. Assim, um invasor em qualquer um dos saltos envolvidos na transferência (geralmente pelo menos dois, um no remetente e outro no site do destinatário) pode interceptar e também modificar os e-mails e pode, é claro, restringir-se a lidar apenas com e-mails selecionados. A única proteção é a criptografia end-to-end usando PGP ou S / MIME.