En 2013, documentos filtrados por Edward Snowden revelaron que agencias de inteligencia estaban interceptando tráfico de correo entre los centros de datos de los principales proveedores. Las conexiones no estaban cifradas: el correo fluía en texto plano a través de cables de fibra óptica, fácilmente legible por cualquiera que pudiera intervenirlos.
La respuesta fue rápida. Google, Microsoft, Yahoo y otros desplegaron cifrado entre sus servidores. La tecnología que usaron fue STARTTLS, un mecanismo que existía desde hacía años pero no estaba implementado de forma universal. En cuestión de meses, la mayoría del tráfico de correo entre grandes proveedores estaba cifrado.
STARTTLS no es perfecto, pero es la base del cifrado del correo en tránsito. Entender cómo funciona te ayuda a comprender tanto su protección como sus limitaciones.
Cómo funciona STARTTLS
STARTTLS es una extensión de SMTP que actualiza una conexión en texto plano a una cifrada. El nombre describe literalmente lo que sucede: inicias TLS.
Así es la secuencia. Un cliente se conecta a un servidor en un puerto SMTP estándar. La conexión empieza sin cifrado: ambos lados pueden verlo todo en texto plano. El cliente envía un comando EHLO y el servidor responde con sus capacidades, incluyendo "250-STARTTLS" si soporta cifrado.
Si el cliente quiere cifrado (y debería), envía el comando STARTTLS. El servidor responde con "220 Ready to start TLS." En este punto, ambos realizan un handshake TLS —el mismo proceso que asegura las conexiones HTTPS. Una vez que el handshake termina, todo lo que sigue está cifrado.
El cliente entonces reinicia la conversación SMTP, pero ahora cifrada. Envía otro EHLO, se autentica si es necesario y procede a enviar el correo. Cualquiera que observe la red solo ve datos cifrados ininteligibles.
Este enfoque de "upgrade" se llama cifrado oportunista. La conexión empieza sin cifrado y se añade cifrado si ambos lados lo soportan. Esto difiere de TLS implícito (usado en el puerto 465), donde la conexión está cifrada desde el primer byte.
Por qué el enfoque de actualización
Puede que te preguntes por qué el correo no empieza cifrado, como hace HTTPS. La respuesta es la compatibilidad histórica.
SMTP se diseñó en 1982, mucho antes de que el cifrado fuera una preocupación. Se desplegaron millones de servidores de correo hablando SMTP sin cifrado. Cuando el cifrado pasó a ser importante, el protocolo necesitaba evolucionar sin romper la infraestructura existente.
STARTTLS lo resolvió haciendo que el cifrado fuera opcional y negociado. Los servidores antiguos que no lo soportan simplemente no anuncian la capacidad, y las conexiones continúan sin cifrado. Los servidores nuevos pueden actualizarse a cifrado cuando hablan con otros servidores nuevos. El ecosistema pudo migrar gradualmente.
Esta compatibilidad retroactiva vino con compromisos. El mecanismo de actualización crea una ventana de vulnerabilidad, y su naturaleza opcional significa que el cifrado no está garantizado. Pero permitió que el cifrado se extendiera por el ecosistema del correo sin requerir un 'flag day' en el que todo cambiara de una vez.
Limitaciones de seguridad
STARTTLS proporciona protección real, pero tiene debilidades conocidas.
El mayor problema es el ataque de downgrade. Como la negociación de STARTTLS ocurre en texto plano, un atacante que pueda interceptar el tráfico puede suprimir el anuncio de la capacidad STARTTLS. El cliente cree que el servidor no soporta cifrado y continúa sin cifrar. Ninguna de las partes sabe que ocurrió el ataque.
No es teórico. Investigadores han documentado ISPs y estados nación realizando ataques de stripping de STARTTLS. Tu correo puede estar cifrado cuando sale de tu servidor y cifrado cuando llega al destino, pero en algún punto intermedio alguien pudo haber eliminado el cifrado y leído todo.
La validación de certificados es otra debilidad. Muchos servidores de correo no validan estrictamente los certificados durante STARTTLS. Aceptarán certificados autofirmados, certificados caducados o certificados para un nombre de host incorrecto. Esto facilita el despliegue, pero significa que un atacante man-in-the-middle podría presentar un certificado falso e interceptar el tráfico.
Estas limitaciones son la razón por la que existen MTA-STS y DANE: proporcionan mecanismos para exigir cifrado y validar certificados, cerrando las brechas que STARTTLS deja abiertas.
STARTTLS vs TLS implícito
El correo electrónico soporta dos enfoques de cifrado: STARTTLS (TLS explícito) y TLS implícito.
Con STARTTLS, la conexión comienza sin cifrar y se actualiza. Se usa en el puerto 587 para submission y puede usarse en el puerto 25 para transferencia entre servidores.
Con TLS implícito, la conexión está cifrada desde el primer byte. No hay fase en texto plano, ni negociación de actualización. Se usa en el puerto 465 para submission.
TLS implícito es probablemente más seguro porque no hay oportunidad de ataques de downgrade durante el establecimiento de la conexión. El handshake TLS ocurre inmediatamente; si falla, la conexión falla. No hay retroceso a texto plano.
Sin embargo, STARTTLS está más extendido, especialmente para comunicación entre servidores. El puerto 25 con STARTTLS es cómo fluye la mayor parte del correo entre servidores. TLS implícito en el puerto 465 se utiliza principalmente para submission de clientes.
Para tu propio envío de correo, cualquiera de los enfoques está bien si se implementa correctamente. Para correo entre servidores, STARTTLS en el puerto 25 es el estándar, complementado por MTA-STS o DANE para garantías más fuertes.
Verificar soporte de STARTTLS
Puedes verificar si un servidor soporta STARTTLS usando herramientas de línea de comandos.
Conéctate con telnet o netcat al puerto SMTP y emite un comando EHLO. La respuesta del servidor lista sus capacidades. Si aparece "250-STARTTLS" en la lista, el servidor soporta actualizaciones de cifrado.
Para probar la conexión TLS real, usa OpenSSL: "openssl s_client -starttls smtp -connect mail.example.com:25". Esto se conecta, emite STARTTLS, realiza el handshake TLS y te muestra el certificado y los detalles de la conexión.
Herramientas en línea como CheckTLS y MXToolbox pueden probar el soporte de STARTTLS para los servidores de correo de cualquier dominio. Informarán si el cifrado está disponible y proporcionarán detalles sobre los certificados en uso.
Supervisar STARTTLS en todo tu tráfico de correo ayuda a identificar servidores que no soportan cifrado. Si estás enviando correo sensible a un dominio que no soporta STARTTLS, ese correo viaja en texto plano.
STARTTLS en la práctica
La mayoría de la infraestructura de correo moderna soporta STARTTLS, pero la calidad de la implementación varía.
Los principales proveedores de correo (Gmail, Microsoft, Yahoo) soportan STARTTLS y lo usan para la gran mayoría de su tráfico. Google publica informes de transparencia que muestran qué porcentaje del correo hacia y desde Gmail usa cifrado —para la mayor parte del tráfico supera el 90%.
Los servidores de correo corporativos varían ampliamente. Implementaciones bien mantenidas de Exchange y Google Workspace soportan STARTTLS. Servidores más antiguos o mal mantenidos puede que no. Al enviar a dominios corporativos, el cifrado no está garantizado.
Los servidores de correo autoalojados deberían habilitar siempre STARTTLS. La configuración es directa en el software MTA moderno. No hay una buena razón para operar un servidor de correo sin cifrado en 2024.
Los servicios de correo (SendGrid, Mailgun, etc.) soportan STARTTLS tanto para conexiones entrantes como salientes. Cuando envías a través de estos servicios, usarán cifrado cuando el destino lo soporte.
Más allá de STARTTLS
STARTTLS proporciona cifrado en tránsito, pero no es cifrado de extremo a extremo. El correo se descifra en cada servidor a lo largo del camino. Si necesitas cifrado de extremo a extremo verdadero—donde solo el remitente y el destinatario pueden leer el mensaje—necesitas S/MIME o PGP.
Para una seguridad de transporte más sólida, MTA-STS y DANE abordan las debilidades de STARTTLS. MTA-STS publica una política que requiere cifrado y especifica certificados válidos. DANE usa DNSSEC para autenticar certificados. Ambos evitan los ataques de downgrade que STARTTLS por sí solo no puede detener.
El ecosistema del correo se está moviendo gradualmente hacia el cifrado obligatorio. Google y Microsoft penalizan cada vez más las conexiones sin cifrar en su puntuación de spam. Es posible que futuros estándares exijan cifrado en lugar de hacerlo opcional.
Frequently asked questions
¿STARTTLS cifra mi correo de extremo a extremo?
No. STARTTLS cifra el correo en tránsito entre servidores, pero el correo se descifra en cada servidor. Los administradores del servidor y cualquiera con acceso al servidor pueden leer el contenido. Para cifrado de extremo a extremo, usa S/MIME o PGP.
¿STARTTLS es lo mismo que TLS?
STARTTLS es un comando que inicia el cifrado TLS en una conexión existente. TLS es el protocolo de cifrado en sí. STARTTLS es el mecanismo; TLS es lo que activa.
¿Por qué algunos correos siguen yendo sin cifrado?
STARTTLS es opcional. Si el servidor receptor no lo soporta, o si un intermediario elimina la capacidad, el correo vuelve a texto plano. MTA-STS y DANE ayudan a evitar esto, pero la adopción no es universal.
¿Debería exigir STARTTLS para todo el correo?
Para envío, puedes preferir cifrado pero puede que necesites permitir volver a texto plano para servidores que no lo soportan. Para recepción, exigir STARTTLS podría rechazar correo legítimo de remitentes mal configurados. MTA-STS te permite exigir cifrado con más matices.