¿El uso de un certificado SSL autofirmado en un servidor de correo dificultará la comunicación?

Estás bien con un certificado autofirmado.

En mi experiencia de varios años, nunca tuve problemas con un certificado autofirmado en mi servidor de correo. Finalmente, cambié a uno firmado por StartSSL y no hubo una diferencia perceptible en la interoperabilidad.

Vea también esta publicación en ServerFault .

La conclusión es que STARTTLS trata del cifrado, no de la autenticación. Si bien se puede bloquear para realizar la autenticación, el valor predeterminado de la mayoría de los servidores SMTP (si no todos) es cifrado oportunista . SMTP es texto sin formato de forma predeterminada, y necesitaba cifrado más de lo que necesitaba autenticación, por lo tanto, el énfasis.

Es posible bloquear conexiones; por ejemplo, he visto un Ironport configurado para requerir un certificado válido firmado por una CA conocida que le gustó (en este caso, le gustó Entrust pero no Comodo, por lo que terminamos cambiando el certificado porque era más fácil que depurar el Ironport de otra persona). Pero eso es para bloquear dominios específicos que quieren asegurar el cifrado asociado, nunca he visto a alguien hacer eso con un cifrado oportunista.

El cifrado con SSL consta de los siguientes pasos:

1. Identifique el par utilizando un certificado.
2. Cree e intercambie claves para la siguiente comunicación.
3. Intercambie datos, cifrados con las claves intercambiadas previamente.

Por lo general, utiliza el cifrado porque cree que cualquiera puede escuchar la conexión. Un pequeño paso de esta escucha pasiva es la manipulación activa de la conexión que SSL también puede detectar. Pero para esto necesita identificar correctamente a su compañero, de lo contrario, cualquier persona en el medio podría decir que es el servidor correcto.

Con un certificado autofirmado, la identificación adecuada no es posible, ya que cualquiera podría crear dicho certificado con las mismas credenciales que usted. Esto significa que nadie debe confiar en un certificado autofirmado por sí mismo. Solo debe confiar en un certificado autofirmado si puede verificarlo de otra manera. Esta otra forma podría ser una configuración manual en el lado del servidor (por lo general no es el caso a menos que el remitente conozca al destinatario directamente) o la verificación del certificado a través de DANE , donde el propietario del dominio proporciona su certificado o huella digital dentro de un registro DNS confiable (necesita DNSSec ).

Lo que realmente hacen los servidores cuando detectan que un certificado que no es de confianza difiere: algunos aceptarán el certificado y escribirán verify=NO en el encabezado del correo recibido, mientras que otros podrían rehusarse a conectarse con SSL porque consideran que la conexión es insegura y desciende. Texto o no conectar en absoluto. Depende de la configuración del servidor de envío.

Actualmente, probablemente la mayoría de los servidores de correo se conectarán con éxito a otros servidores, incluso si no pueden verificar su certificado. Pero, cada vez más están utilizando certificados "reales" (verificables). Si compara los informes de Facebook de mayo de 2014 a August 2014 puede ver el uso de certificados verificables pasar del 30% al 95% en solo 4 mes. Esto significa que el uso de certificados reales probablemente será requerido por más servidores en el futuro cercano.

Esto significa que usar un certificado firmado por una CA conocida es definitivamente mejor que usar un certificado autofirmado. Pero incluso eso podría no proporcionar la seguridad que está tratando de lograr. Cualquiera de la centésima parte de la CA en la que confía el sistema operativo puede emitir dicho certificado, por lo que un atacante podría intentar obtener un certificado para su dominio también. Pero esto es al menos mucho más difícil que simplemente crear otro certificado autofirmado, porque el atacante debe piratear la CA o controlar su dominio de correo de alguna manera para capturar los correos que la CA usa dentro del proceso de identificación.

Otro ataque de un hombre activo en el medio es reencaminar el correo atacando el DNS: para enrutar un correo desde el servidor de correo de envío al servidor responsable de su dominio, el servidor de envío debe: una búsqueda de DNS para el registro MX de su dominio, que contiene los nombres de sus servidores de correo. Un atacante activo cerca del servidor de envío podría atacar esta búsqueda de DNS y proporcionar un registro MX falso que apunte a sus propios servidores. TLS no ayudará más aquí. En su lugar, debe usar DNSSec para asegurar sus registros DNS y el remitente debe verificar este registro.

Aparte de eso, TLS no proporciona seguridad de extremo a extremo para el correo, solo paso a paso. Cualquier servidor de correo intermedio tiene acceso al correo normal y, por lo tanto, debe ser completamente confiable. Para obtener un cifrado de extremo a extremo, debe usar S / MIME o PGP. Y debido a esto, a algunos administradores de servidores no les importa el TLS adecuado, porque TLS no ofrecerá seguridad real (de extremo a extremo) para los correos, incluso si se implementa correctamente.

La autenticidad de un certificado se verifica mediante la clave pública de la parte de confianza. Un spoofer certificado puede ingresar cualquier información que desee en cualquier certificado que haga, pero no puede firmar el certificado con la clave privada (firma) de la parte de confianza, ya que no la tiene. Cuando el pub de la parte de confianza o si te gusta la clave de verificación se usa en la clave privada (firma) incorrecta, la firma se verá como falsificada.

Hasta ahora esto no es diferente para un certificado firmado por la CA o autofirmado.

Sin embargo, surgen problemas en la distribución de la clave pública. Aquí es donde las "autoridades" de certificados sobresalen en la medida en que pueden, al parecer, distribuyen de manera más segura sus claves públicas a un mayor número de personas simplemente enviándolas de manera segura a un número relativamente pequeño de proveedores de aplicaciones clave que deseen instalarlo en su aplicación, por ejemplo: 'proveedores de navegadores', proveedores de servidores de correo, etc. que saben con seguridad que son ellos los que lo envían. Por lo tanto, sus claves públicas, utilizadas para verificar sus propias firmas, son "seguras" suyas y pueden usarse de manera segura para verificar si de hecho firmaron algo. Es decir, un certificado.

Si un autofirmante puede distribuir de forma segura su clave pública, es decir, distribuirla de manera tal que sean los usuarios. sepa con seguridad que es de ellos, entonces su firma, y por lo tanto su certificado autofirmado, es tan bueno si no mejor, considerando que su idenidad está mejor asegurada a través de la distribución de claves que la verificación del ID del solicitante del certificado de CA, como la de cualquier CA.

En este sentido, la pregunta es qué tan segura y costosa (o tiempo) se puede distribuir e instalar su clave de pub en los otros servidores de correo y, si hay algo que lo impulsa a hacerlo, sea mejor seguridad, CA $ upport aversion o algún otro vale la pena.

Esto ya no es cierto. Algunos servidores de correo electrónico comenzaron a verificar la cadena de confianza del certificado ofrecido y rechazan la conexión si no se pasa. Esto puede evitar el envío y la recepción de correos electrónicos.

En nuestro caso, estamos utilizando mailgun y hay un pequeño interruptor en su interfaz de configuración que, de forma predeterminada, requiere que el servidor de recepción tenga un certificado adecuado.