Por que o SMTP sobre SSL entre servidores de email não é tão popular? [fechadas]

No meu entendimento, a maioria dos servidores de email usa SMTP / POP / IMAP sobre SSL para criptografar o email.
Ele suporta criptografia quando o cliente (UA) envia um email para o servidor (MTA) e o UA recebe um email do MTA. No entanto, muitos MTAs não podem criptografar quando enviam email entre o MTA e o MTA.
(meu entendimento está correto?)

por exemplo, alice@somewhere.com envie um email para bob@anywhere.org
[PC de Alice] --- criptografado (SMTPS) ---> [servidor de algures.com ] --- NÃO CRIPTOGADO (SMTP) ---> [em qualquer lugar. servidor organizacional] --- criptografado (POPS ou IMAPS) ---> [PC de Bob]

Se meu entendimento está correto, por que a maioria dos servidores de email não suporta SMTP sobre SSL entre servidores de email?

Desenvolvo uma interface melhor (menos complexa) para habilitar a criptografia de email com PGP / GPG, mas hoje em dia acho que pode ser melhor usar SMTPS porque o PGP / GPG precisa de assinatura manual de chaves para manter a confiabilidade.

— Jumpei Ogawa
fonte

O que isso tem a ver com criptografia de email? enviar e-mail através de criptografia-me que o e-mail é criptografado em seu próprio ...

— Uwe Plonus

?? Desculpe, não entendi o que você quer dizer ... Como "o email é criptografado por si só"? No meu entendimento, o email pode ser facilmente interceptado se você enviar email como texto sem formatação (sem criptografia).

— Jumpei Ogawa

Sim, mas o envio de um email criptografado não tem nada a ver com a criptografia SSL / TLS do servidor SMTP.

— Uwe Plonus

Para garantir que você receba apenas emails em um canal criptografado no servidor SMTP, será necessário forçar o uso do TLS. Portanto, se a outra parte não entender / suportar o TLS, você não receberá seu e-mail. Se você permitir um fallback para comunicação não criptografada, não conseguirá nada. É por isso que as pessoas preferem criptografar o próprio correio e enviá-lo por um canal não criptografado.

— Der Hochstapler

Para esclarecer: "email criptografado" refere-se a criptografar o conteúdo usando algo como PGP antes mesmo de enviá-lo ao servidor de email de saída. Isso tem a vantagem de mantê-lo em segredo de quem executa seu MTA. Não se refere à criptografia do email entre MTAs; a criptografia normalmente é aplicada apenas nas extremidades, não no meio. Observe também que a comunicação entre o UA e o MTA geralmente envolve a transmissão de algum tipo de senha, que deve ser criptografada de qualquer maneira.

— cpast

Boa pergunta, eu realmente não vi números para isso. Não tenho certeza, mas acho que muitas empresas grandes agora oferecem suporte a SSL / TLS para SMTP de entrada e saída (entrega de correio "MX"). Normalmente, isso é opcional e pode ser negociado via StartTLS na porta 25. No entanto, a maioria dos servidores SMTP não exige TLS de servidor para servidor, pois isso significa que muitos não poderão receber email de um MTA que não suporta ou não está configurado para TLS.

Muitos clientes de email suportam TLS entre o UA e o MTA - SMTP / IMAP sobre SSL ou POP3 sobre SSL. Eu acho que o Gmail, por exemplo, requer SSL / TLS para IMAP e POP3.

Em relação à criptografia de ponta a ponta real, isso normalmente é alcançado usando S / MIME ou PGP. No entanto, devido às complexidades de configurá-lo e gerenciá-lo, não houve adoção em larga escala.

— woollybrain
fonte

Obrigado. Então, meu entendimento do estado atual da criptografia de email. Você quer dizer que o SMTPS de servidor para servidor não é suportado em muitos servidores porque um software de servidor como o postfix não o suporta? Se a maioria dos servidores de correio suportar, o problema será resolvido? (Talvez eu não entendo sua resposta corretamente ...)

— Jumpei Ogawa

Mesmo quando a criptografia é negociada, geralmente nenhuma verificação rigorosa dos certificados é feita, pois isso bloquearia todos esses servidores com certificados autoassinados. Mas sem rigorosa verificação de um man-in-the-middle ataque é fácil (para não mencionar que um MITM pode evitar STARTTLS, intervindo a fase cleartext)

— Hagen von Eitzen

O RFC 2487 proíbe que servidores de correio público exijam TLS: "Um servidor SMTP publicamente referenciado NÃO DEVE exigir o uso da extensão STARTTLS para entregar correio localmente. Esta regra impede que a extensão STARTTLS danifique a interoperabilidade da infraestrutura SMTP da Internet".

— ARX