A aplicação da criptografia para SMTP é uma boa idéia (ainda)?

Estou executando um servidor de email que está configurado para usar o TLS, se possível, ao enviar e receber emails.

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

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

Existe algum grande fornecedor que já esteja fazendo isso ou o que você considera a melhor prática atualmente?

O problema prático é que nem todos os servidores compatíveis com SMTP (a RFC é bastante antiga) podem falar TLS com o servidor, portanto, você pode deixar de receber algumas mensagens de email.

O problema filosófico disso é que é impossível dizer como o email é retransmitido depois (ou antes) do seu servidor.

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

Qualquer pessoa séria sobre a proteção do conteúdo de seus emails deve realmente criptografar o corpo. Com a criptografia em rota, é sempre plausível já ter sido transmitida em texto sem formatação.

Portanto, para responder à sua pergunta, aplicar a criptografia na camada SMTP provavelmente não faz sentido, aumenta a chance de perda de e-mails e não há recompensa garantida.

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

Não

A RFC 821 tem 33 anos. Você vai encontrar e-mails retransmitidas por programas notsupporting STARTTLS. Às vezes, eles são remetentes de e-mail stub (por exemplo, scripts internos), às vezes sistemas completos antigos, TLS desativado / não compilado, sistemas sem entropia suficiente…

Testemunhei há pouco tempo os e-mails enviados falharem porque o terminal de recebimento o configurou para permitir apenas SMTP por TLS. Foi um problema no remetente (não deveria estar usando essa configuração), mas mostra que isso acontece.

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

Existe o projeto https://www.eff.org/starttls-everywhere , que fornece uma lista de servidores smtp para os quais você pode (deve?) Impor com segurança o uso de starttls.

É completamente inútil, e provavelmente prejudicial, recusar email de colegas incapazes de criptografia.

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

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

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

Este é um assunto de política.

Geralmente, quando o TLS é imposto para entrada e saída, isso é 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 acordo para criptografar todas as mensagens entre suas empresas).

A menos que tal contrato esteja em vigor, não ative o modo de imposição.

Não, é uma péssima ideia.

De fato, como se vê, a maioria dos servidores / clientes STARTTLS não implementa nenhum tipo de algoritmo de nova tentativa sem o StartTLS, caso uma conexão TLS falhe na negociação.

Como tal, mesmo a publicidade do STARTTLS como opção já reduz suas chances de receber (e enviar) emails!

Basta pesquisar e você encontrará muitas pessoas que não conseguem enviar QUALQUER email para domínios do Microsoft Outlook manipulados pelo cluster * .protection.outlook.com:

Mensagens do Sendmail rejeitadas pela Microsoft ao usar TLS

motivo: falha no handshake 403 4.7.0 TLS

Para resumir os problemas apresentados nas duas postagens acima:

• pode enviar emails para qualquer host que não seja tratado pelo Outlook, com ou sem STARTTLS,
• pode enviar e-mail sem um certificado de cliente e sem o STARTTLS para o Outlook,
• ou com um certificado de cliente de tamanho zero,
• mas não com um certificado que a Microsoft não goste e, em caso de falha, os clientes (bem, servidores atuando 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 servidor, uma situação semelhante pode ocorrer fora do seu controle se você decidir ativar o STARTTLS - quando um servidor cliente vê que seu servidor no modo servidor oferece STARTTLS, eles tentam negociar o TLS, mas se a negociação falhar , eles simplesmente esperam e repetem as mesmas etapas novamente, continuam falhando até que a mensagem seja devolvida ao remetente!

E isso acontece com bastante frequência com vários domínios na terra do STARTTLS!

Infelizmente, por mais que eu fosse um defensor do STARTTLS no passado, agora estou muito desprovido de liberdade por ter sido enganado pelo anúncio sem risco do que eu pensava ser criptografia oportunista.

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

Eu tenho que concordar com a idéia de usar TLS oportunista. Embora eu tenha alguns a acrescentar à ideia também. Alguns provavelmente ficarão perturbados com as sugestões, no entanto, como minhas sugestões aqui não são feitas de ânimo leve e sem a devida consideração, antes de julgar, peço que leia a discussão completa no link em anexo.

Usar TLS oportunista é de longe a melhor solução. O ângulo do MITM como argumento contra ele é um arenque vermelho. Afinal, como o 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 ser mais sábio, porque a grande maioria dos clientes de email não se preocupa em validar certificados juntamente com a grande maioria. dos MTAs que usam TLS estão usando certificados autoassinados (pelo menos se você não usa DNSSEC e TLSA / DANE.) Como resultado desse e de outros fatores, é possível argumentar que até você e o resto do mundo implementou o DANE / TLSA e o DNSSEC, que, ao executar o TLS oportunista, é melhor não ter também diffie-hellman anônimo (ao usar o PFS) também. Devido, pelo menos em parte, se não principalmente, ao fato de ainda criptografar o tráfego que protege contra o observador casual. Para dar suporte a essa configuração (com uma explicação muito mais elaborada que a minha), consulte os comentários de Viktor Dukhovni neste post em um fórum postfix:http://postfix.1071664.n5.nabble.com/Disabling-Anonymous-Diffie-Hellman-td67965.html

Quanto ao motivo pelo qual alguém pode aceitar as sugestões de Viktor sobre as demais, ele escreveu o código TLS e o código DNSSEC, TLSA / DANE para o Postfix MTA, além de ter sido quem escreveu os rascunhos da IETF nos dois DNSSEC e TLSA / DANE. Como tal, eu diria que suas palavras sobre o assunto têm muito peso, provavelmente mais do que as da maioria.

Espero que isto ajude.

Da perspectiva do marketing por email, o uso do TLS é uma boa prática e segura quando você sabe que ele é implementado em toda a cadeia de entrega. No entanto, se a segurança é seu principal requisito, criptografar o próprio email antes de enviá-lo é a opção mais segura (por exemplo, com PGP).