Conjuntos de cifrado TLS para MTA

Incluso con cifrados que utilizan 3DES o RC4, un atacante no puede descifrar el cifrado con costos moderados. E incluso los servicios secretos probablemente preferirían la falsificación de DNS MX o simplemente eliminar las STARTTLS de las características del MTA receptor, ya que esto es mucho más barato que intentar descifrar dichos cifrados.

Por lo tanto, le recomiendo que acepte cifrados con RC4 y 3DES en caso de que el MTA homólogo no tenga mejores cifrados, porque el mal cifrado es definitivamente mejor que el texto sin formato y, en muchos casos, también es mejor que no entregar el correo en absoluto. Por supuesto, debe poner estos cifrados débiles solo al final de su lista y preferir los fuertes. Y no debe utilizar el modo de cifrado débil como el cifrado EXPORT.

Pero, si se encuentra en un entorno con mayores requisitos de seguridad, debe configurar su MTA para que solo utilice cifrados sólidos y para que sea obligatorio el TLS, es decir, que no exista un retroceso, incluso si el par no parece admitir el TLS. Y debe protegerse contra la falsificación de MX también, es decir, hacer cumplir DNSSec. Aparte de eso, es mejor que utilice el cifrado de extremo a extremo (PGP, S / MIME) en ese entorno de todos modos.

Esa es una buena pregunta y no estoy seguro de que haya una buena respuesta.

Entonces hay dos tipos de ataques: activo y pasivo. Para un atacante pasivo, los protocolos rotos podrían estar bien siempre que el ataque requiera algún tipo de modificación / inyección de tráfico. No pueden hacer cosas como generar certificados falsos y firmarlos con una firma md5 colisionada porque, como atacante pasivo, no pueden inyectarlos en el flujo.

Los atacantes activos pueden hacer cosas con la conexión, como hacer que parezca que el servidor de correo en el otro extremo no es compatible con TLS.

Por lo general, a menos que desee forzar TLS y rechazar las conexiones simples, creo que debería averiguar qué protocolos son seguros contra los atacantes pasivos. O al menos ataques que están por debajo de su nivel de riesgo: por ejemplo, si cuesta $ 2 millones descifrar un cifrado (por ejemplo, RSA con claves de 1024 bits) y los estados nacionales no son un adversario que le preocupa, eso podría ser aceptable.

Lo siento, no tengo tiempo para averiguar qué versiones de TLS y sistemas de cifrado son adecuados para usar contra atacantes pasivos, pero espero que esto haya ayudado.

Personalmente, habilitaría cifrados sólidos (por ejemplo, utilizando las sugerencias de enlace ).

RC4 está efectivamente dañado ( enlace ), por lo que se habilita es, en el mejor de los casos, de dudoso valor (puede proteger contra un observador casual).

Dicho esto: ¿qué parte del correo electrónico que recibe se verá afectado? Desde mi propia experiencia, el argumento es similar al hecho con respecto a los navegadores web; ocasionalmente, existen algunas razones convincentes para desviarse del enfoque criptográfico de alto grado, pero el enfoque predeterminado es no hacerlo. En mi caso, resulta que una cantidad muy pequeña del correo que me importa se vería afectado.

Sé que los MTA no son navegadores, y la imagen no es tan atractiva, pero también sospecho que la imagen no es tan mala como muchos pensarían (ayuda de los proveedores de correo gestionados).

Así que en general, me gustaría aterrizar en el enfoque HTTPS, en lugar de apoyar criptografía de baja calidad (que en algunos casos no está a la altura de proteger los datos en primer lugar).