MTA-STS para Postfix

MTA-STS es el estándar RFC8461 propuesto que dejó de ser borrador y se publicó oficialmente el 26 de septiembre de 2018. Este estándar ofrece un mecanismo para detectar la posibilidad de utilizar TLS completo entre servidores de correo, con cifrado de datos y autenticación de servidor. Es decir, este estándar protege casi por completo contra la interferencia con el tráfico de correo entre servidores.

Simplificado, la esencia del estándar es la siguiente:

1. Los servicios de correo compatibles publican una política (1 registro TXT y 1 recurso HTTPS para cada dominio).
2. Los servicios de correo al enviar correo a otros dominios detectan la política de dominio del destinatario.
3. Los servicios de correo se conectan al servidor de correo del dominio del destinatario, aplicando restricciones TLS establecidas por la política detectada, si existe.

Hay buenos artículos ( por ejemplo ) que hablan sobre el estándar en sí y por qué es necesario, comparando MTA-STS con otras iniciativas similares e incluso mostrando cómo escribir y publicar una política. Pero encontrar cómo ir más allá del primer paso no fue tan simple.

Empezar de nuevo

Antes de implementar MTA-STS, debe ordenar los certificados del servidor de correo. De lo contrario, los servidores de correo que tengan en cuenta su política STS rechazarán la conexión a su servidor. Deben cumplirse las siguientes condiciones:

• El certificado del servidor es emitido por una autoridad de certificación reconocida (Let's Encrypt es bueno).
• La cadena de certificados enviada por el servidor incluye todos los certificados necesarios de las autoridades de certificación intermedias.
• El certificado tiene un campo Nombre alternativo del sujeto con el nombre DNS de su servidor MX.

Puede verificar el servidor configurado con el certificado con el siguiente comando:

[ "$(LANG=C openssl s_client -connect MX.EXAMPLE.COM:25 -starttls smtp -verify_hostname MX.EXAMPLE.COM < /dev/null 2>&1 | fgrep 'error')" = "" ] && echo OK || echo FAIL 

donde MX.EXAMPLE.COM es el nombre de dominio de su servidor MX. Para el pleno cumplimiento de la norma, es aconsejable verificar que el nombre de dominio deseado esté presente no solo en el Nombre común del certificado, sino al menos en el Nombre alternativo del sujeto.

Publicación de políticas

Para designar su dominio como compatible con una conexión segura con él, debe publicar la política MTA-STS. Para hacer esto, realice los siguientes pasos simples en el orden especificado (se dan ejemplos para el dominio example.com).

1. Colocar en

  https://mta-sts.example.com/.well-known/mta-sts.txt 

archivo de texto del formulario:

 versión: STSv1
 modo: hacer cumplir
 mx: mail.example.com
 mx: * .example.net
 mx: backupmx.example.com
 max_age: 604800

El archivo debe entregarse con Content-Type: text / plain. Los redireccionamientos no están permitidos. Los avances de línea deben ser LF o CRLF. No se permiten líneas vacías. La última línea puede terminar con un avance de línea, o no puede terminar con ella; ambas opciones están permitidas. No se permite el espacio vacío antes de los dos puntos y al comienzo de la línea. El espacio vacío después de los dos puntos está permitido en cualquier cantidad. Se ignora el espacio en blanco (espacios, tabulaciones, etc.) al final de cada línea.

Valores de campo:

versión : versión de formato. Siempre debe ser igual a "STSv1".
modo : modo de política. Posibles opciones: ninguna, prueba, imposición. El modo de cumplimiento corresponde al funcionamiento normal del estándar: requerir el certificado correcto y una conexión TLS estable cuando se conecta al servidor. El modo de prueba requiere que intente utilizar una conexión segura, pero en caso de error, envíe un correo con notificación de administrador a través del mecanismo TLSRPT. El modo Ninguno corresponde a la situación como si la política no se hubiera publicado en absoluto. Este modo es útil para deshabilitar correctamente una política.
mx : uno o más campos que contienen los nombres de todos los servidores de dominio MX permitidos. Como puede ver en el ejemplo, las plantillas están permitidas, pero solo como un dominio de nivel inferior.
max_age : el tiempo en segundos que la política puede almacenarse en caché y durante el cual los remitentes pueden continuar usándola si la política ya no está disponible. Debido a esta característica del estándar, deshabilitar STS es más rápido al publicar una nueva política sin modo ninguno.

2. Cree un registro TXT _mta-sts.example.com con el contenido del formulario:

  v = STSv1;  id = 20160831085700Z; 

Los espacios en blanco alrededor de un punto y coma se pueden organizar arbitrariamente en cualquier cantidad. En otros lugares, el espacio en blanco no está permitido. El último punto y coma puede estar presente o ausente.

Valores de campo:

v : versión de formato. Siempre debe ser el primer campo, siempre debe ser igual a STSv1.
id : identificador único de la política publicada. Puede ser una cadena con una longitud de 1 a 32 caracteres, que consta de letras de registros y números. Cambiar el valor de identificación es una señal para los remitentes de que la política se ha actualizado. Por lo tanto, primero debe actualizar la política y publicar un nuevo archivo de política, y luego cambiar la identificación en el registro TXT.

A partir de ahora, los servidores de correo que admiten MTA-STS solo enviarán correo a su dominio a través de una conexión segura autenticada por certificado. Ahí es donde terminan la mayoría de los manuales, pero la parte más interesante es obtener la política MTA-STS de su propio servidor al enviar correo.

Mas interesante

La principal dificultad es que este estándar no es compatible con los servidores de correo, incluido Postfix. Sin embargo, esta bagatela desagradable no debería detenernos.

Encontrar una solución me llevó al archivo de la lista de correo de usuarios de postfix discutiendo el momento de este estándar. En una publicación, Witsa Venema, autora de Postfix, señala la dirección preferida para implementar esta funcionalidad: utilizar un servidor externo para buscar políticas TLS. Se propone utilizar la directiva de configuración del formulario:

  smtp_policy_maps = socketmap: inet: host: puerto: nombre 

Implementé dicho servidor para obtener la política MTA-STS.

→ Código fuente
→ Paquete en PyPI

La aplicación carece de algunas de las funciones que prescribe RFC8461, tales como: recuperación proactiva de políticas, informes y limitación de la frecuencia de las solicitudes de políticas. Sin embargo, la función principal, detectar la política TLS y almacenarla en caché, funciona.

La aplicación requiere Python 3.5.3+. La instalación y configuración de este demonio se puede realizar mediante los siguientes pasos.

Instalación del paquete

Es suficiente ejecutar el comando:

 pip3 install postfix-mta-sts-resolver 

Aquí se escriben métodos de instalación alternativos.

Crear un archivo de configuración

Si está satisfecho con la configuración predeterminada, entonces el comando es suficiente

 touch /etc/postfix/mta-sts-daemon.yml 

De lo contrario, la configuración puede tomarse del ejemplo y adaptarse a sus necesidades.

El parámetro más importante, en mi opinión, es el parámetro estricto_prueba. Si se establece en verdadero (falso por defecto), la aplicación devolverá una política segura incluso para dominios con una política en modo de prueba. Este comportamiento es contrario al estándar, pero es aconsejable por razones prácticas: si el propietario del dominio ha publicado la política STS incluso en modo de prueba, entonces probablemente esté listo para ello. Es decir, hoy el correo de gmail.com se enviará a través de una conexión confiable.

Organización de inicio

En el caso de systemd, es suficiente colocar un archivo de unidad simple en /etc/systemd/system/mta-sts-daemon.service

Después de eso, queda por releer la configuración de systemd, habilitar la ejecución automática del demonio e iniciarla:

 systemctl daemon-reload systemctl enable mta-sts-daemon.service systemctl start mta-sts-daemon.service 

Control de salud

Suponiendo que se usa el puerto predeterminado, el comando

 /usr/sbin/postmap -q dismail.de socketmap:inet:127.0.0.1:8461:postfix 

debería traer

  partido seguro = mx1.dismail.de 

Conectarse a Postfix

Agregue una línea a main.cf:

 smtp_policy_maps = socketmap:inet:127.0.0.1:8461:postfix 

Reiniciar Postfix:

 systemctl reload postfix.service 

Si todo se hace correctamente, para las conexiones STS en el registro /var/log/mail.info en su lugar

  Conexión TLS confiable establecida 

los registros comienzan a aparecer

  Conexión TLS verificada establecida 

Conclusión

Si llegas a este lugar, lo más probable es que signifique:

• Lees el artículo sin una sola imagen.
• Día a día, la probabilidad de intercepción de correo en su dominio disminuirá, ya que otros servicios de correo implementan el nuevo estándar.