← RFC Reference

RFC 3207 – Extensión SMTP STARTTLS

Por qué existe esta RFC

Cuando SMTP fue diseñado en 1982, el cifrado no era una consideración. Los mensajes viajaban por internet en texto plano, y cualquiera con acceso a la ruta de red podía leerlos. A medida que internet se volvió más hostil, el cifrado de correo en tránsito se convirtió en esencial.

RFC 3207 define la extensión STARTTLS para SMTP, permitiendo que una conexión SMTP de texto plano se actualice a una conexión TLS cifrada. Publicada en 2002, reemplazó RFC 2487 con aclaraciones sobre consideraciones de seguridad y comportamiento del servidor.

STARTTLS es el mecanismo dominante para cifrar el tráfico de correo servidor a servidor (MTA a MTA) en el puerto 25. Para la presentación cliente-servidor, RFC 8314 ahora recomienda TLS implícito en el puerto 465, pero STARTTLS en el puerto 587 sigue siendo ampliamente utilizado.

Cómo funciona

STARTTLS funciona como una extensión SMTP, negociada durante el intercambio EHLO:

1. El cliente se conecta al servidor en el puerto 25 (o 587) en texto plano.
2. El cliente envía EHLO. El servidor responde con sus capacidades, incluido 250-STARTTLS si admite cifrado.
3. El cliente envía STARTTLS.
4. El servidor responde con 220 Ready to start TLS.
5. Ambos lados realizan un protocolo de enlace TLS, estableciendo un canal cifrado.
6. El cliente envía un nuevo EHLO sobre la conexión cifrada. La lista de capacidades del servidor puede cambiar (por ejemplo, AUTH ahora se anuncia).
7. La sesión SMTP continúa normalmente, pero todo el tráfico ahora está cifrado.

Ejemplo SMTP

Negociación STARTTLS durante una transferencia servidor a servidor:

Detalles técnicos clave

TLS oportunista frente a obligatorio

La limitación crítica de STARTTLS tal como se define en RFC 3207 es que es oportunista por defecto:

• TLS oportunista: El cliente intenta STARTTLS si el servidor lo anuncia, pero vuelve a texto plano si no está disponible o si el protocolo de enlace TLS falla. Este es el comportamiento predeterminado para conexiones MTA a MTA.
• TLS obligatorio: El cliente se niega a enviar el mensaje a menos que se pueda establecer TLS. Esto se puede configurar por dominio o aplicar mediante MTA-STS (RFC 8461) o DANE (RFC 7672).

TLS oportunista es vulnerable a ataques de degradación: un atacante de red puede eliminar la capacidad STARTTLS de la respuesta EHLO, forzando la conexión a permanecer en texto plano. El cliente no tiene forma de saber que el servidor admite TLS porque la negociación inicial ocurre en texto plano.

Verificación de certificado

RFC 3207 no requiere verificación estricta de certificado para conexiones MTA a MTA. En la práctica, muchos servidores utilizan certificados autofirmados o certificados que no coinciden con el nombre de host MX. La razón: el cifrado oportunista sin verificación sigue siendo mejor que sin cifrado. Protege contra la vigilancia pasiva incluso si no previene ataques activos de intermediario.

Para garantías más fuertes, use:

• DANE (RFC 7672) — publica el certificado TLS del servidor en DNS mediante registros TLSA, asegurado por DNSSEC.
• MTA-STS (RFC 8461) — publica una política que requiere TLS con validación de certificado, almacenada en caché por servidores de envío.

Re-EHLO después de STARTTLS

Después de completar el protocolo de enlace TLS, el cliente DEBE emitir un nuevo comando EHLO. La lista de capacidades del servidor anterior a TLS debe descartarse. Esto es importante porque:

• El servidor puede anunciar diferentes capacidades después de que se establezca el cifrado (por ejemplo, AUTH).
• El servidor no debe anunciar más STARTTLS ya que el cifrado ya está activo.
• Un atacante podría haber modificado la respuesta EHLO anterior a TLS.

STARTTLS en diferentes puertos

Informe de TLS

RFC 8460 define Informe de TLS SMTP (TLSRPT), que permite a los propietarios de dominios recibir informes sobre fallos de conexión TLS. Este es el equivalente STARTTLS de informes agregados DMARC — le dice cuándo las conexiones a sus servidores están fallando la negociación TLS.

Errores comunes

• Asumir que STARTTLS significa que el mensaje está cifrado de extremo a extremo. STARTTLS solo cifra la conexión entre dos servidores adyacentes. Si un mensaje pasa por múltiples saltos, cada salto negocia TLS de forma independiente. Un mensaje podría estar cifrado en un salto y en texto plano en el siguiente.
• No reenviar EHLO después de STARTTLS. No enviar un nuevo EHLO después del protocolo de enlace TLS es una violación del protocolo. Estará trabajando con datos de capacidad obsoletos y puede perder características recién disponibles como AUTH.
• Tratar el fallo de STARTTLS como un error permanente. Si la negociación STARTTLS falla, la conexión está en un estado indefinido. Cierre la conexión e inicie una nueva. No intente continuar con texto plano en la misma conexión.
• Anunciar STARTTLS pero usar un certificado expirado o mal configurado. Si bien muchos clientes procederán a pesar de errores de certificado, algunos clientes cada vez más estrictos (y políticas MTA-STS/DANE) se negarán. Mantenga sus certificados TLS válidos y configurados correctamente.
• Confiar únicamente en STARTTLS para la seguridad. Porque STARTTLS es oportunista y vulnerable a ataques de degradación, debe complementarse con MTA-STS o DANE para dominios donde el cifrado es crítico.
• Olvidar STARTTLS en el puerto 587. Para presentación, los clientes siempre deben STARTTLS antes de autenticarse. Enviar credenciales AUTH en texto plano expone su contraseña SMTP a cualquiera que monitoree la conexión.

Impacto en la entrega

• Google y proveedores principales marcan correo sin cifrar. Gmail muestra un icono de candado abierto rojo para mensajes recibidos sin cifrado TLS. Esto señala a los destinatarios que el mensaje pudo haber sido interceptado en tránsito, reduciendo la confianza.
• La adopción de TLS es casi universal. A partir de 2025, más del 95% del correo enviado a Gmail está cifrado con TLS. No admitir STARTTLS en su infraestructura de envío lo convierte en un caso atípico y puede afectar negativamente su reputación como remitente.
• La aplicación de MTA-STS está creciendo. Los proveedores principales publican políticas MTA-STS que requieren TLS con validación de certificado. Si su servidor de envío no puede negociar TLS exitosamente con un certificado válido, la entrega a estos dominios fallará.
• El informe de TLS expone problemas. Si publica un registro TLSRPT y su servidor tiene problemas de TLS, recibirá informes. Si no publica TLSRPT, no sabe nada sobre fallos de conexión.
• Requisitos de cumplimiento. HIPAA, GDPR, PCI-DSS y otras regulaciones cada vez más requieren cifrado en tránsito para correo. STARTTLS es el mecanismo de base que satisface este requisito para correo servidor a servidor.

Related RFCs