Ir al contenido 
Te mostraré cómo Servidor de correo TLS en Postfix y seleccionar fuertes suites de cifrado para que las conexiones SMTP estén siempre protegidas. Basándome en parámetros probados y comprobados para TLS 1.2/1.3, DANE, MTA-STS y pares de claves modernos, le guiaré paso a paso a través de la configuración, las pruebas y la puesta a punto para que su seguridad del correo se agarra limpiamente.
Puntos centrales
- Postfix Configure de forma segura: Activar TLS, restringir protocolos, configurar el registro.
- Cifrado priorizar: ECDHE + GCM/CHACHA20, aplicar PFS, bloquear los datos heredados.
- Certificados mantener limpio: RSA+ECDSA, cadena completa, curvas fuertes.
- DANE/MTA-STS utilizar: Directrices de anclaje y reducción de los riesgos de rebaja.
- Pruebas y supervisión: compruebe regularmente OpenSSL, el escáner TLS y los registros MTA.
SMTP mediante TLS: lo que está realmente protegido
Aseguro SMTP con STARTTLS, para que el transporte del correo electrónico no se realice en texto plano. TLS oportunista mediante smtpd_tls_security_level = may garantiza que las conexiones entrantes utilicen el cifrado en cuanto la estación remota lo ofrezca. Para las salientes, utilizo smtp_tls_security_level = dane Comprobaciones de políticas compatibles con DNSSEC para dificultar los ataques de downgrade. Sin TLS, los correos electrónicos podrían ser leídos y manipulados en tránsito, lo que resulta especialmente peligroso para formularios, pedidos o datos de cuentas. Con TLS activo en todo momento, reduzco significativamente el riesgo de escuchas y MITM, y consigo mejores tasas de entrega porque los grandes proveedores valoran favorablemente las conexiones seguras.
Claves, certificados y protocolos en Postfix
Tengo dos certificados preparados: uno RSA-certificado y un certificado ECDSA para que los MTA antiguos y nuevos estén conectados de forma óptima. Configuro las rutas en Postfix claramente, por ejemplo smtpd_tls_cert_file para RSA y smtpd_tls_archivo_eccert para ECDSA, cada uno con una clave coincidente. Para una autenticación limpia, presto atención a la cadena completa, un CN/SAN que coincida exactamente con el host, y una curva como secp384r1 para la clave ECDSA. Desactivo estrictamente los protocolos más antiguos, es decir, SSLv2 y SSLv3, para evitar que se fuercen las actualizaciones. Si está sopesando el tipo de certificado, un vistazo rápido a DV, OV o EV, para que elijas el nivel de confianza adecuado.
Selección de cifrado: Prioridades para TLS 1.2/1.3
Doy prioridad a las suites de cifrado con PFS, es decir, ECDHE antes que DHE, y utilizar GCM o CHACHA20-POLY1305. Bajo TLS 1.3, la pila te libera de muchos problemas heredados, mientras que TLS 1.2 todavía requiere una lista clara. Las suites inseguras o débiles como RC4, Borro 3DES, CAMELLIA, aNULL, eNULL. Para Postfix utilizo smtpd_tls_ciphers = alto y una restrictiva tls_high_cipherlist, para que no se cuelen algoritmos obsoletos. Si se profundiza, el Guía de suites de cifrado una categorización fácil de entender y sin lastres.
| Versión TLS | Suites de cifrado favoritas | Estado | Nota |
|---|---|---|---|
| TLS 1.3 | TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256 | activo | Selección firmemente en el protocolo, no más problemas de legado. |
| TLS 1.2 | ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-CHACHA20-POLY1305 | activo | Dar prioridad al SFP, preferir GCM/CHACHA. |
| Obsoleto | RC4, 3DES, CAMELLIA, AES128-SHA, aNULL/eNULL | bloqueado | Desactivar completamente por razones de seguridad. |
Postfix: parámetros concretos para main.cf
Establezco una configuración clara para que el MTA hable con seguridad tanto de entrada como de salida. Para ECDH efímero, utilizo smtpd_tls_eecdh_grade y desactivo la compresión para evitar ataques tipo CRIME. Un archivo DH fuerte con 4096 bits evita negociaciones DHE débiles. Pongo duras restricciones a los protocolos e impongo una alta calidad de cifrado, favoreciendo TLS 1.3. Al principio, un nivel de registro moderado me ayuda a comprobar los handshakes sin inundar el diario.
# Activación y política
smtpd_tls_security_level = may
smtp_tls_security_level = dane
Certificados # (rutas de ejemplo)
smtpd_tls_cert_file = /etc/ssl/certs/mail.ejemplo.de.cer
smtpd_tls_key_file = /etc/ssl/private/mail.example.de.key
smtpd_tls_eccert_file = /etc/ssl/certs/mail.ejemplo.de_ecc.cer
smtpd_tls_eckey_file = /etc/ssl/private/mail.example.de_ecc.key
Protocolos y cifrados #
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers = alto
tls_high_cipherlist = !aNULL:!eNULL:!RC4:!3DES:!CAMELLIA:HIGH:@STRENGTH
tls_ssl_options = NO_COMPRESSION
smtpd_tls_eecdh_grade = ultra
Parámetros DH #
smtpd_tls_dh1024_param_file = /etc/postfix/dh_4096.pem
# DNSSEC/DANE (si está disponible)
smtp_dns_support_level = dnssec
# Registro
smtpd_tls_loglevel = 1
Mantengo la cadena de certificados completa, presto atención a los derechos correctos para privado y compruebo los registros después de la recarga. Si se requiere TLS 1.2 para socios heredados, me atengo estrictamente a GCM/CHACHA y bloqueo todo lo demás. Para TLS 1.3, confío en los estándares de la pila y evito las rutas especiales que dificultan el mantenimiento. El engrapado OCSP sólo desempeña un papel con SMTP si un proxy aguas arriba lo proporciona, por lo que sólo lo compruebo para las configuraciones correspondientes. Después de cada cambio, hago una validación con OpenSSL para reconocer los efectos secundarios desde el principio y asegurarme de que la versión encriptación del correo electrónico consistentemente.
Autenticidad del transporte con DANE, MTA-STS, SPF, DKIM y DMARC
Combino TLS con DANE, publicando registros TLSA firmados bajo DNSSEC. Además, configuro MTA-STS para que los pares remotos sepan que mi host requiere TLS y a qué MX deben adherirse. Para la vinculación de identidades, firmo los correos salientes con DKIM y entrega segura de dominios mediante reglas SPF. Por último, DMARC define cómo deben tratar los destinatarios las desviaciones, lo que hace mucho más difícil la suplantación de identidad. Estos componentes funcionan conjuntamente: TLS protege el transporte, mientras que la autenticación refuerza al remitente y aumenta notablemente la tasa de entrega.
Si el rendimiento es un cuello de botella, optimizo la reanudación de la sesión, las características del hardware y el propio apretón de manos. Puedes iniciarte en los trucos prácticos con El apretón de manos TLS es más rápido, para reducir la latencia al establecer una conexión. Importante: Mantengo el equilibrio entre la selección de cifrado y la reanudación, porque los compromisos débiles no compensan en términos de seguridad. La negociación rápida de TLS aporta ahorros significativos, especialmente con grandes volúmenes de correo. De este modo Rendimiento y seguridad en equilibrio.
Pruebas, control y auditorías
Compruebo los apretones de manos localmente con openssl y comprueba la versión del protocolo, el cifrado y la cadena del certificado. El comando openssl s_client -connect mail.ejemplo.de:25 -starttls smtp me muestra en directo lo que está negociando el servidor remoto. Después de los cambios de configuración, utilizo comprobación postfix y examinar específicamente smtpd_tls_loglevel, para aislar patrones de error. Los escáneres TLS externos ayudan a categorizar la visibilidad pública, especialmente tras los cambios de certificado. Un ciclo de auditoría regular protege contra el deterioro progresivo, por ejemplo si un cambio de biblioteca afecta a las prioridades de cifrado.
Frecuentes errores de configuración y soluciones rápidas
A menudo veo cifrados anticuados como AES128-SHA, que siguen activos y evitan el PFS. Aquí ayuda una cadena de cifrado estricta y el bloqueo claro de LOW/MD5/RC4/3DES. Segundo patrón: faltan certificados intermedios, lo que impide que las estaciones remotas verifiquen la cadena; añado el archivo bundle y vuelvo a probar. En dispositivos como Synology, establezco el perfil TLS en moderno y elimino las opciones heredadas para que el servidor SMTP hable en moderno. En el caso de Microsoft Exchange, compruebo específicamente las políticas TLS 1.2/1.3, la asignación de certificados por conector y cualquier anulación de cifrado en la configuración del host para que el Apretón de manos-la selección es correcta.
Vista previa: TLS 1.3, 0-RTT y Post-Quantum
Prefiero TLS 1.3 porque el apretón de manos es más corto y se omiten las opciones antiguas, lo que reduce las superficies de ataque. La selección de la cifrado No utilizo 0-RTT en el contexto SMTP, ya que los ataques de repetición conllevan riesgos innecesarios. De cara al futuro, no pierdo de vista los procedimientos híbridos poscuánticos, que podrían abrirse camino en el entorno del correo tan pronto como maduren la normalización y el soporte. Sigue siendo importante que configure las políticas y la supervisión de forma que los nuevos procedimientos puedan integrarse más adelante sin interrupciones.
Rendimiento y tasa de entrega de un vistazo
Mido el Latencia del apretón de manos TLS y optimizar las cachés para permitir su reutilización. La reanudación de sesión (tickets/IDs) reduce la carga computacional y acelera las conexiones recurrentes entre MTAs. Para la revocación de certificados, confío en la información apilable en el proxy ascendente, si está disponible, para ahorrar accesos adicionales. Los grandes destinatarios valoran favorablemente los transportes seguros, lo que aumenta la tasa de entrega, mientras que las rutas inseguras aumentan el riesgo de spam y rechazo. Con una política TLS clara, entradas DNS sólidas y una cadena de firmas limpia, creo una base fiable para Entregabilidad.
Mi programa de instalación
Empiezo obteniendo el certificado de una CA de confianza, genero ECDSA y RSA y almaceno ambos limpiamente en el host. Luego personalizo el main.cf con los parámetros TLS, establecer cifrados fuertes y desactivar protocolos antiguos. Se añade un archivo DH nuevo con 4096 bits, seguido de una recarga y las primeras comprobaciones de OpenSSL. A continuación, configuro DANE, añado MTA-STS y verifico la validez de SPF/DKIM/DMARC. Por último, ejecuto pruebas contra objetivos externos, compruebo los registros durante el funcionamiento y programo auditorías periódicas para que el Configuración sigue siendo seguro a largo plazo.
Módulos que faltan: Presentación, SMTPS y SNI
No sólo protejo el puerto 25, sino también el de envío (587) y, opcionalmente, el SMTPS (465). En el caso del envío, aplico el cifrado y la autenticación para que las contraseñas de los usuarios nunca se envíen en texto plano. En master.cf Activo los servicios y establezco anulaciones específicas:
Envío # (puerto 587) con STARTTLS y obligación de autenticación
submission inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encriptar
-o smtpd_tls_auth_only=yes
-smtpd_sasl_auth_enable=yes
-o milter_macro_daemon_name=ORIGINATING
# SMTPS (puerto 465) como modo wrapper, si es necesario
smtps inet n - y - - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o milter_macro_daemon_name=ORIGINATING
Si doy servicio a varios dominios de correo en un mismo host con mis propios certificados, utilizo SNI. Utilizo un mapa SNI para asignar la ruta de certificado adecuada para cada host de destino y garantizar que los clientes MUA también vean el certificado correcto. Así es como garantizo la separación de clientes con una identidad TLS coherente.
Políticas por dominio: control detallado
Además de la política global, también gestiono smtp_tls_policy_maps Excepciones y endurecimiento por dominio de destinatario. Esto me permite migrar gradualmente a los socios heredados o aplicar requisitos especialmente estrictos a objetivos sensibles.
# main.cf
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
# /etc/postfix/tls_policy (entradas de ejemplo)
ejemplo.org sólo-dane
legacy.example.net may
secure.ejemplo.com secure
sólo para daneses refuerza la protección DANE sin dependencia de CA, seguro requiere una cadena CA válida y rechaza la entrega de texto plano, mayo sigue siendo oportunista. Después de los cambios, construyo el mapa con postmap y recargar Postfix.
DANE y MTA-STS: aplicación concreta
Para DANE Publico registros TLSA bajo DNSSEC. Prefiero utilizar DANE-EE (3 1 1) porque permite fijar la clave pública y facilita los cambios de certificado con la misma clave. Un ejemplo de registro TLSA bajo _25._tcp.mail.example.de se ve así:
_25._tcp.mail.example.de. IN TLSA 3 1 1
Genero el hash a partir del certificado ECDSA o RSA y me aseguro de rotarlo antes de que caduque. Es importante que la zona DNS esté firmada y que la cadena de delegaciones esté validada sin lagunas.
Para MTA-STS Alojo el archivo de política a través de HTTPS y añado la entrada DNS TXT. De esta forma, especifico que los pares remotos hablan TLS y sólo se aceptan con un MX definido. Un archivo de políticas minimalista:
versión: STSv1
modo: enforce
mx: mail.ejemplo.de
max_age: 604800
Se añade una entrada TXT en el DNS bajo _mta-sts.example.de con la versión actual. Opcionalmente configuro TLS-RPT a través de TXT en _smtp._tls.ejemplo.de para recibir informes sobre infracciones de las políticas. Esta telemetría me ayuda a reconocer fallos, rebajas y certificados defectuosos en una fase temprana.
Protocolos más estrictos, cifrado específico
Refuerzo los límites de los protocolos e impongo la preferencia del servidor. TLS 1.0/1.1 son prescindibles hoy en día; sólo permito TLS 1.2 y 1.3 en profundidad y de forma saliente. Para TLS 1.2, defino una lista positiva explícita para excluir las existencias mixtas de cifrados antiguos:
# Endurecimiento adicional (main.cf)
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
# Lista explícita de cifrado TLS 1.2 (sólo PFS + AEAD)
tls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:!aNULL:!eNULL:!MD5:!RC4:!3DES:!CAMELLIA
# Utilizar preferencia de servidor
tls_preempt_cipherlist = yes
Me aseguro de que ECDHE es el preferido y DHE es sólo una alternativa. Mantengo mi archivo DH actualizado; bajo TLS 1.3 no juega ningún papel, pero sigue siendo útil para acciones DHE raras.
Reanudación de sesión y cachés
Para acelerar las cosas, activo cachés de sesión para el cliente y el servidor para que las reconexiones sean más favorables. La carga de la CPU y la latencia se reducen notablemente, sobre todo con un alto rendimiento del correo:
# Caché de sesión (main.cf)
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_connection_reuse = yes
Controlo el porcentaje de aciertos en los registros y me aseguro de que ninguno sea demasiado corto. ticket_lifetimes en la biblioteca TLS para ralentizar la reanudación. Importante: La reanudación no debe debilitar la política; me atengo a los mismos requisitos de cifrado.
Empresa certificada: Rotación y mantenimiento de la cadena
Automatizo la renovación y recarga del MTA para que ningún certificado caducado acabe en funcionamiento. Después de cada renovación, compruebo si la hoja y los certificados intermedios están completamente en el paquete. Para el funcionamiento dual ECDSA/RSA, me aseguro de que ambos pares rotan antes de que un cambio masivo cause problemas a los clientes. Compruebo la ruta SNI y el envío por separado porque los MUA pueden mostrar patrones de error diferentes a los de los MTA.
Profundizar en el registro y el diagnóstico
Aumento temporalmente la profundidad del registro cuando se produce un problema y utilizo herramientas de a bordo para comprobaciones cruzadas:
# registro específico (main.cf)
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
Con posttls-finger target.ejemplo.com Compruebo qué política espera un MTA remoto y qué cifrados/protocolos se negocian. Utilizo postconf -n | grep tls, para ver sólo los parámetros TLS configurados explícitamente; de esta forma puedo encontrar más rápidamente las desviaciones de los valores predeterminados. En los registros, busco términos como sin cifrado compartido, fallo en la verificación del certificado o versión del protocolo, que indican directamente desajuste de cifrado, problemas de cadena o límites de protocolo demasiado estrictos/demasiado laxos.
Gestionar la compatibilidad sin sacrificar la seguridad
Planifico las transiciones conscientemente: profundizo con mayo, para evitar perder correos de servidores heredados en todos los ámbitos, pero registro las entregas de texto sin formato. En cuanto al correo saliente, sigo siendo estricto (DANE/MTA-STS/seguro) y utilizo smtp_tls_policy_maps para casos individuales. Si los socios individuales sólo pueden gestionar TLS 1.2 con AES-GCM, es aceptable; yo gestiono todo lo que está por debajo de esto mediante excepciones acordadas con un tiempo de ejecución limitado, las documento y las incluyo en la planificación de la migración. Esto mantiene el nivel general alto sin bloquear las operaciones comerciales.
Los valores predeterminados TLS del sistema de un vistazo
Tenga en cuenta que Postfix utiliza la biblioteca TLS del sistema. Las actualizaciones de OpenSSL/LibreSSL pueden cambiar las prioridades de cifrado y el comportamiento de TLS 1.3. Por lo tanto, después de las actualizaciones del sistema, compruebo aleatoriamente los handshakes y comparo la salida de postconf -n con mis valores objetivo. Un conjunto nivel_compatibilidad en Postfix ayuda a mantener valores por defecto estables, pero yo no confío ciegamente en él y documento desviaciones explícitas en main.cf/master.cf.
Resumen breve para administradores
Me gustaría hacer hincapié en que los cifrados fuertes con PFS, los certificados limpios y las políticas claras son esenciales para SMTP crucial. TLS 1.3 le libera de los problemas heredados, mientras que TLS 1.2 requiere una lista de cifrado disciplinada. DANE y MTA-STS endurecen la ruta de transporte, SPF/DKIM/DMARC aseguran la identidad y los informes. Las pruebas periódicas y los análisis de registros muestran desde el principio si un cambio tiene efectos secundarios no deseados. Con esta guía, podrá configurar su servidor de correo para que sea seguro, eficaz y preparado para el futuro, sin necesidad de Riesgos.
