¿Qué nombre de host debe contener el certificado SSL para un servidor SMTP?

Tengo un servidor foo.example.com en 192.0.2.1

Se ejecuta exim para recibir correo electrónico de varios de mis dominios.

Cada uno de mis dominios tiene un registro MX que apunta a mx.example.com, que se resuelve en 192.0.2.1

Si deseo que Exim ofrezca encriptación TLS para las conexiones de correo electrónico entrantes, ¿qué nombre de host debo poner en el certificado SSL?

• foo.example.com porque eso es lo que dirá el servidor en HELO?
• mx.example.com porque ese es el nombre de host al que se habrán conectado los clientes?

http://www.checktls.com sugiere que esto último es correcto, pero no puedo encontrar una respuesta definitiva.

En realidad, esto no se define explícitamente en ninguna parte, y si el servidor debe ser "confiable" o no depende del cliente (que podría ser otro servidor de correo) conectado a él; citando del RFC relevante ( RFC 2487 ):

Si el cliente SMTP decide que el nivel de autenticación o
privacidad no es lo suficientemente alto como para continuar, DEBE emitir un
comando SMTP QUIT inmediatamente después de que se complete la negociación TLS.
Si el servidor SMTP decide que el nivel de autenticación o
privacidad no es lo suficientemente alto como para continuar, DEBE responder a
cada comando SMTP del cliente (que no sea un comando QUIT) con
el código de respuesta 554 (con una posible cadena de texto como como "Comando
rechazado por falta de seguridad").

La decisión de si creer o no la autenticidad de la
otra parte en una negociación de TLS es un asunto local. Sin embargo, algunas
reglas generales para las decisiones son:

- A SMTP client would probably only want to authenticate an SMTP
  server whose server certificate has a domain name that is the
  domain name that the client thought it was connecting to.

Lo que esto básicamente significa es que, cuando el servidor ofrece cifrado TLS utilizando un certificado dado, la decisión de aceptarlo o rechazarlo depende completamente de la otra parte, que probablemente querrá que el nombre en el certificado sea el mismo al que está conectado, pero podría muy bien aceptarlo incluso si no coincide.

Pero espera hay mas. Citando nuevamente desde el mismo RFC:

Al completar el protocolo de enlace TLS, el protocolo SMTP se restablece al
estado inicial (el estado en SMTP después de que un servidor emite un
saludo de servicio listo para 220 ). El servidor DEBE descartar cualquier conocimiento
obtenido del cliente, como el argumento del comando EHLO,
que no se obtuvo de la negociación TLS en sí. El cliente
DEBE descartar cualquier conocimiento obtenido del servidor, como la lista
de extensiones de servicio SMTP, que no se obtuvo de la
negociación TLS en sí. El cliente DEBE enviar un comando EHLO como
primer comando después de una negociación TLS exitosa.

Entonces, lo que dice el servidor en respuesta a HELO / EHLO antes del apretón de manos TLS no parece importar en absoluto.

En mi experiencia, los certificados autofirmados funcionan bastante bien en los servidores de correo con conexión a Internet, lo que significa que los otros servidores de correo ni siquiera se molestan en validarlos, simplemente aceptarán cualquier cosa que pueda proporcionar cifrado TLS, independientemente de la emisión autoridad o nombre del sujeto.

Un MTA que envía correo a su dominio buscará el registro MX (que generará un nombre de host) y luego buscará un registro A para ese nombre de host. El nombre de host al que se está conectando es, por lo tanto, el nombre de host MX, y eso es lo que se verificará con el nombre común del certificado SSL. Verificar el nombre de host HELO no tiene sentido porque el servidor puede proporcionar cualquier nombre de host HELO que desee, no proporciona seguridad adicional.

Dicho esto, verificar estrictamente los certificados SSL al entregar el correo no es particularmente útil en este momento, ya que los MTA (casi siempre) recurrirán a la entrega no SSL, ya que así es como SMTP funciona en este momento. Por lo tanto, la configuración sensata es usar SSL si el servidor MX lo ofrece, independientemente de si el certificado SSL lo verifica o no (ya que el cifrado sin autenticación es mejor que sin cifrado y sin autenticación). Por lo tanto, también podría usar un certificado autofirmado para este propósito.

La tarea de verificar el certificado del servidor y de que coincida con el nombre de host del servidor es puramente la función del cliente, para cualquier protocolo que use SSL / TLS.

Como tal, el nombre de host en el certificado debe coincidir con el nombre al que el cliente está intentando acceder.

Cuando la conexión SSL / TLS se inicia por adelantado (SMTPS), el servidor no tiene forma de ver lo que dice el mensaje HELO antes de que se establezca la conexión, por lo que debe usar el que hizo la solicitud.

Cuando se usa SSL / TLS después STARTTLS, el cliente todavía tiene la intención de hablar con el servidor con el que se configuró, por lo que eso es lo que debe verificar. De lo contrario, los ataques MITM serían posibles:

• C-> S: Hola, soy Alice, quiero hablar con Bob.
• S-> C: Hola, soy Chuck, aquí está mi certificado para Chuck.
• C-> S: Oh, sí, su certificado es válido para Chuck. Vamos a proceder
• ... Hay una falla allí, por supuesto, ya que Alice quería una comunicación segura con Bob.

En ambos casos, se debe usar la dirección MX.

Las reglas de coincidencia de nombres de host se han recopilado recientemente en todos los protocolos en RFC 6125 , pero pocos clientes lo implementan completamente (es más una RFC de mejores prácticas que un cambio completo, y aún es bastante reciente).

En su apéndice , resume lo que existía antes sobre SMTP (tomado de RFC 3207 y RFC 4954 ). En particular, " el cliente NO DEBE utilizar ninguna forma del nombre de host del servidor derivado de una fuente remota insegura (por ejemplo, búsqueda de DNS insegura) " (que se aplica al banner del servidor, por supuesto). Aparte de esto, las reglas heredadas SMTP eran un poco más relajado que en relación con HTTPS (nombres alternativos del sujeto debe en lugar de debe ser utilizado).

La forma moderna es definitivamente poner el nombre del host en una entrada DNS de Nombre alternativo del sujeto. El uso de comodines también se desaconseja .

Creo que lo mejor sería copiar lo que se hace en la práctica. Verifiqué una dirección de correo electrónico de yahoo.com usando http://checktls.com. Con suerte, en yahoo, usaron un dominio diferente para su nombre de host y para su dominio mx. Entonces, su nombre de host es yahoo.com y su dominio mx termina con yahoodns.net

dig mx yahoo.com gives mta6.am0.yahoodns.net. among others

Resultado de las comprobaciones: el certificado SSL CN = dominio MX (* .yahoodns.net)

Hice lo mismo con Cisco y obtuve el mismo resultado.

En el cifrado SSL / TLS, el cliente siempre verifica la correspondencia entre el nombre de host "real" / "declarado" en la máquina remota y la información contenida en el certificado.

Por lo tanto, probablemente debería configurar foo.example.com o generar un certificado comodín ;-)