¿Es una buena idea aplicar el cifrado para SMTP (todavía)?

Estoy ejecutando un servidor de correo electrónico que actualmente está configurado para usar TLS si es posible, al enviar y recibir correos electrónicos.

Cuando lea la documentación sobre esto, también existe la opción de aplicar TLS y no aceptar la transmisión de mensajes de texto sin formato. También le advierte que es posible que algunos servidores de correo aún no admitan el cifrado y que la aplicación del cifrado podría bloquear estos servidores.

Pero, ¿sigue siendo un problema en el que uno debería pensar o es seguro decir que aplicar el cifrado ya no será un problema?

¿Hay algún proveedor importante que ya esté haciendo esto o qué consideras mejor práctica en estos días?

El problema práctico es que no todos los servidores compatibles con SMTP (el RFC es bastante antiguo) pueden hablar TLS a su servidor, por lo que es posible que no reciba algunos mensajes de correo electrónico.

El problema filosófico con esto es que es imposible saber cómo se retransmite el correo electrónico después (o antes) de que llegó a su servidor.

Esto significa que es posible que el correo electrónico ya se haya transmitido en texto sin formato a través de un relé.

Cualquier persona seria sobre la protección del contenido de su correo electrónico debería encriptar el cuerpo. Con el cifrado en ruta siempre es plausible, ya se ha transmitido en texto plano.

Por lo tanto, para responder a su pregunta, hacer cumplir la encriptación en la capa SMTP probablemente no tenga sentido, aumenta sus posibilidades de perder el correo electrónico y no se garantiza una recompensa beneficiosa.

Editar: Esto se refiere a la aplicación de SMTP para fines de retransmisión, no para envío de correo electrónico. En el envío de correos, el cifrado debe aplicarse ya que la conversación SMTP (no el correo electrónico real) posiblemente contenga credenciales de autenticación.

No

RFC 821 tiene 33 años. Usted va a encontrar mensajes transmitidos por los programas notsupporting STARTTLS. A veces serán remitentes de correos electrónicos (por ejemplo, scripts internos), a veces sistemas completos que son viejos, tienen TLS deshabilitado / no compilado, sistemas sin suficiente entropía ...

Fui testigo de que no hace mucho tiempo los correos electrónicos salientes fallaban porque el extremo receptor lo tenía configurado para permitir solo SMTP a través de TLS. Fue un problema en el remitente (no debería haber estado usando esa configuración), pero muestra que sucede.

Solo restringiría los mensajes entrantes de direcciones IP configuradas manualmente. Si el procesador de su tarjeta de crédito no puede iniciar STARTTLS, probablemente prefiera cancelar la conexión (¡y avisar al administrador local para que pueda advertirles!) Antes que recibir esos datos (potencialmente confidenciales) sin cifrar. Para los mensajes salientes, si se conectó a ese host utilizando STARTTLS anteriormente, es posible que no quiera volver a hacerlo de forma insegura, considerándolo como un posible compromiso. También puede tener una lista de hosts STARTTLS conocidos por usar siempre, como gmail o yahoo.

Hay un proyecto https://www.eff.org/starttls-everywhere que proporciona una lista de servidores smtp para los que puede (¿debería?) Aplicar con confianza el uso de starttls.

Es completamente inútil, y probablemente activamente dañino, rechazar el correo electrónico de pares incapaces de cifrar.

Siempre que su servidor esté configurado para realizar cifrado oportunista con cualquier par que lo ofrezca, obtendrá lo mejor de ambos mundos: cifrado cuando esté disponible y correo electrónico sobre texto sin formato cuando no lo sea.

Mientras haya servidores que no admitan el cifrado, exigirlo simplemente significa que no pueden hablar con usted; eso es malo. Una vez que todos lo admiten, no hay diferencia entre el cifrado oportunista y obligatorio.

Y como otros han señalado, el cifrado en el cable y el cifrado de extremo a extremo son dos cosas completamente diferentes, que abordan diferentes modelos de amenazas. No confundas los dos.

Este es un asunto de política.

En general, cuando se aplica TLS para entrada y salida, se hace para un conjunto limitado de dominios que las partes acuerdan para satisfacer una necesidad (por ejemplo, los socios comerciales pueden tener un acuerdo para cifrar todo el correo entre sus empresas).

A menos que se establezca dicho acuerdo, no active el modo de imposición.

No, es una muy mala idea.

De hecho, resulta que la mayoría de los servidores / clientes STARTTLS no implementan ningún tipo de algoritmo de reintento sin StartTLS en caso de que una conexión TLS no se negocie.

Como tal, ¡incluso anunciar STARTTLS como una opción ya reduce sus posibilidades de recibir (y enviar) correos electrónicos!

Simplemente busque y encontrará que muchas personas no pueden enviar CUALQUIER correo electrónico a los dominios de Microsoft Outlook manejados por el clúster * .protection.outlook.com:

Mensajes de Sendmail rechazados por Microsoft cuando usa TLS

motivo: 403 4.7.0 TLS apretón de manos falló

Para resumir los problemas presentados en las dos publicaciones anteriores:

• puede enviar cualquier correo a cualquier host que no sean los manejados por Outlook, con o sin STARTTLS,
• puede enviar correo sin un certificado de cliente y sin STARTTLS a Outlook,
• o con un certificado de cliente de longitud cero,
• pero no con un certificado que a Microsoft no le guste, y si falla, los clientes (bueno, los servidores que actúan en modo cliente) no intentan reenviar el mensaje sin STARTTLS si el servidor del destinatario anuncia STARTTLS.

Del mismo modo, cuando su host actúa como servidor, puede ocurrir una situación similar fuera de su control si decide habilitar STARTTLS: cuando un servidor cliente ve que su servidor en modo de servidor ofrece STARTTLS, intentan negociar TLS, pero si la negociación falla , simplemente esperan y vuelven a intentar los mismos pasos, siguen fallando hasta que el mensaje tenga que ser devuelto al remitente.

¡Y esto sucede con bastante frecuencia con varios dominios en la tierra STARTTLS!

Lamentablemente, por mucho que solía ser un partidario de STARTTLS en el pasado, ahora estoy muy privado de que me engañó la publicidad sin riesgos de lo que pensé que se suponía que era un cifrado oportunista.

No solo no debe requerir STARTTLS, sino que incluso puede ser prudente desactivarlo por completo, si desea garantizar la interoperabilidad.

Tengo que estar de acuerdo con la idea de usar TLS oportunista. Aunque, tengo algo que agregar a la idea también. Sin embargo, algunos se verán perturbados por las sugerencias, ya que mis sugerencias aquí no se hacen a la ligera y sin la debida consideración, antes de emitir un juicio, le pido que lea la discusión completa desde el enlace adjunto.

El uso de TLS oportunista es, con mucho, la mejor solución. El ángulo MITM como argumento en su contra es una pista falsa. Después de todo, como MH mencionó en un comentario, incluso un SMTP "legítimo" con conexión TLS puede ser MITM'd y el usuario final no es más sabio debido a que la gran mayoría de los clientes de correo no se molestan en validar los certificados junto con la gran mayoría de los MTA que están haciendo TLS están usando certificados autofirmados (al menos si no están usando DNSSEC y TLSA / DANE). Como resultado de esto y posiblemente otros factores, es incluso discutible que hasta usted y el resto del mundo ha implementado DANE / TLSA y DNSSEC, que mientras se ejecuta TLS oportunista, es mejor que no se habilite también el diffie-hellman anónimo (mientras se usa PFS). Debido al menos en parte, si no principalmente, al hecho de que todavía cifrará el tráfico que protege contra el observador casual. Para un mayor soporte de esta configuración (con una explicación mucho más elaborada que la mía), vea los comentarios de Viktor Dukhovni en esta publicación en un foro de postfix:http://postfix.1071664.n5.nabble.com/Disabling-Anonymous-Diffie-Hellman-td67965.html

En cuanto a por qué uno podría tomar las sugerencias de Viktor sobre las de los demás, bueno, escribió el código TLS, así como el código DNSSEC, TLSA / DANE para el Postfix MTA, además de haber sido el que escribió los borradores de IETF en ambos DNSSEC y TLSA / DANE. Como tal, diría que sus palabras al respecto tienen mucho peso, probablemente más que las de la mayoría.

Espero que esto ayude.

Desde una perspectiva de marketing por correo electrónico, el uso de TLS es una buena práctica y seguro cuando se sabe que se implementa a través de toda la cadena de entrega. Sin embargo, si la seguridad es su requisito principal, encriptar el correo electrónico antes de enviarlo es la opción más segura (por ejemplo, con PGP).