A imposição de criptografia para SMTP é uma boa ideia (ainda)?

Question

Estou executando um servidor de e-mail que está atualmente configurado para usar o TLS, se possível, ao enviar e receber e-mails.

Quando você lê na documentação sobre isso, há também a opção de aplicar o TLS e não aceitar a transmissão de texto sem formatação de e-mails. Ele também avisa que alguns servidores de e-mail podem não oferecer suporte à criptografia e que a imposição de criptografia pode bloquear esses servidores.

Mas isso ainda é um problema que se deve pensar ou é seguro dizer que impor a criptografia não será mais um problema?

Existe algum grande provedor que já está fazendo isso ou o que você considera a melhor prática nos dias de hoje?

    

Answer 1

O problema prático é que nem todo servidor compatível com SMTP (o RFC é bem antigo) pode falar TLS com o seu servidor, então você pode deixar de receber algumas mensagens de e-mail.

O problema filosófico com isso é que é impossível dizer como o e-mail é retransmitido depois (ou antes) de chegar ao seu servidor.

Isso significa que o email já pode ter sido transmitido em texto simples por meio de uma retransmissão.

Qualquer um que tenha interesse em proteger o conteúdo do e-mail deve criptografar o corpo. Com encriptação em rota, é sempre plausível que já tenha sido transmitido em texto simples.

Portanto, para responder à sua pergunta, a imposição de criptografia na camada SMTP provavelmente é inútil, aumenta suas chances de perder e-mails e não há retorno benéfico garantido.

Editar: refere-se à imposição de SMTP para fins de retransmissão, não envio de e-mail. Em envios de mensagens, a criptografia deve ser imposta, pois a conversa SMTP (não o email real) possivelmente contém credenciais de autenticação.

    

Answer 2

Não

A RFC 821 tem 33 anos de idade. Você irá encontrar e-mails transmitidos por programas que não suportam STARTTLS. Às vezes, eles serão remetentes de e-mail de stub (por exemplo, scripts internos), às vezes, sistemas completos que são antigos, têm o TLS desabilitado / não compilado, sistemas sem entropia suficiente ...

Eu testemunhei não há muito tempo e-mails de saída falhando porque o terminal de recebimento tinha configurado para permitir somente SMTP sobre TLS. Foi um problema no remetente (não deveria ter usado essa configuração), mas mostra que isso acontece.

Eu só restringiria mensagens recebidas de endereços IP configurados manualmente. Se o seu processador de cartão de crédito não iniciar o STARTTLS, você provavelmente preferirá abortar a conexão (e paginar o administrador local para que ele possa avisá-lo!) Rathen do que receber esses dados (potencialmente sensíveis) não criptografados. Para mensagens de saída, se você se conectou a esse host usando STARTTLS anteriormente, talvez não queira fazer isso de forma insegura novamente, tratando-o como um possível comprometimento. Você também pode ter uma lista de hosts STARTTLS conhecidos para sempre, como gmail ou yahoo.

Existe um projeto link que fornece uma lista de servidores smtp para os quais você pode (deve?) aplicar o uso de starttls com confiança.

    

Answer 3

É completamente inútil, e provavelmente prejudicial, recusar emails de pares incapazes de criptografia.

Desde que seu servidor esteja configurado para fazer uma criptografia oportunista com qualquer peer que o ofereça, você obtém o melhor dos dois mundos: criptografia quando disponível e e-mail sobre texto sem formatação quando não é.

Desde que existam servidores que não suportam criptografia, exigir isso significa simplesmente que eles não podem falar com você; isso é ruim. Uma vez que todos o suportam, não há diferença entre criptografia oportunista e obrigatória.

E, como outros apontaram, a criptografia on-the-wire e a criptografia de ponta a ponta são duas coisas completamente diferentes, abordando diferentes modelos de ameaças. Não confunda os dois.

    

Answer 4

Este é um assunto político.

Geralmente, quando o TLS é imposto para inbound & saída, ele é feito para um conjunto limitado de domínios que são acordados pelas partes para atender a uma necessidade (por exemplo, parceiros de negócios podem ter um contrato para criptografar todos os e-mails entre suas empresas).

A menos que tal acordo esteja em vigor, não ative o modo de cumprimento.

    

Answer 5

Não, é uma péssima ideia.

Na verdade, como se vê, a maioria dos STARTTLS servidores / clientes não implementam nenhum tipo de algoritmo de nova tentativa sem o StartTLS uma conexão TLS falha ao negociar.

Assim, até mesmo anunciar STARTTLS como uma opção já reduz suas chances de receber (e enviar) e-mails!

Basta pesquisar e você descobrirá que muitas pessoas não podem enviar QUALQUER email a domínios do Microsoft Outlook gerenciados pelo cluster * .protection.outlook.com:

Mensagens do Sendmail rejeitadas pela Microsoft ao usar o TLS

razão: falha no handshake 403 4.7.0 TLS

Para resumir as questões apresentadas nos dois posts acima:

• pode enviar qualquer email para qualquer host que não seja tratado pelo Outlook, com ou sem STARTTLS,
• pode enviar e-mails sem um certificado de cliente e sem STARTTLS para o Outlook,
• ou com um certificado de cliente de comprimento zero,
• mas não com um certificado que a Microsoft não goste e, após uma falha, os clientes (bem, servidores agindo no modo cliente) não tentam reenviar a mensagem sem STARTTLS se o servidor do destinatário anunciar STARTTLS!

Da mesma forma, quando seu host atua como um servidor, uma situação semelhante pode ocorrer fora de seu controle se você decidir ativar o STARTTLS - quando um servidor cliente vê que seu servidor no modo de servidor oferece STARTTLS, ele tenta negociar o TLS, mas se a negociação falhar, eles simplesmente aguardam e repitam os mesmos passos novamente, continuem falhando até que a mensagem tenha que ser devolvida ao remetente!

E isso acontece com muita frequência em vários domínios no terreno STARTTLS!

Infelizmente, por mais que eu fosse um apoiador da STARTTLS no passado, agora estou muito desprivilegiado por ter sido enganado pelo anúncio livre de risco do que eu pensava ser uma criptografia oportunista.

Não apenas você não deve exigir STARTTLS, mas também pode ser prudente desativá-lo completamente, se quiser garantir a interoperabilidade.

    

Answer 6

Eu tenho que concordar com a idéia de usar o TLS oportunista. Embora eu tenha alguns para adicionar à ideia também. Alguns provavelmente serão perturbados pelas sugestões, no entanto, como minhas sugestões aqui não são feitas com leviandade e sem a devida consideração, antes de julgar, peço que você leia a discussão completa do link em anexo.

Usar o TLS oportunista é, de longe, a melhor solução. O ângulo MITM como um argumento contra ele é um arenque vermelho. Afinal de contas, como MH mencionou em um comentário, mesmo um SMTP “legítimo” com conexão TLS pode ser MITM e o usuário final não é o mais sábio devido à grande maioria dos clientes de e-mail não se preocuparem em validar certificados juntamente com a grande maioria de MTAs por aí fazendo TLS estão usando certificados auto-assinados (pelo menos se você não estiver usando DNSSEC e TLSA / DANE). Como resultado disso e possivelmente outros fatores, é até discutível que até você e o resto do mundo implementou o DANE / TLSA e o DNSSEC, que durante a execução de TLS oportunista é melhor do que não ter também o diffie-hellman anônimo (ao mesmo tempo que também utiliza o PFS). Devido, pelo menos em parte, se não principalmente ao fato de que ele ainda irá criptografar o tráfego de proteção contra o observador casual. Em apoio adicional a esta configuração (com uma explicação muito mais elaborada do que a minha), por favor, veja os comentários de Viktor Dukhovni neste post em um fórum postfix: link

Quanto ao porquê alguém pode tomar as sugestões de Viktor em detrimento das outras, ele escreveu o código TLS, bem como o código DNSSEC, TLSA / DANE para o Postfix MTA, além de ter sido o responsável por ter escrito os rascunhos da IETF. tanto no DNSSEC como no TLSA / DANE. Como tal, eu diria que suas palavras sobre o assunto pesam bastante, provavelmente mais do que as da maioria.

Espero que isso ajude.

    

Answer 7

Do ponto de vista do email marketing, o uso do TLS é uma boa prática e seguro quando você sabe que ele é implementado em toda a cadeia de entrega. No entanto, se a segurança for sua principal exigência, a criptografia do email em si antes de enviá-lo é a opção mais segura (por exemplo, com PGP).