RFC 8314: Texto sin cifrar considerado obsoleto

Standards Track Transport Security Published March 2026

ELI5: Durante años, los clientes de correo se conectaban a servidores en un puerto de texto plano y luego pedían "actualizar" al cifrado (STARTTLS). Es como iniciar una llamada telefónica en altavoz en una sala llena de gente y luego susurrar "cambiemos a una línea privada". RFC 8314 dice: simplemente comienza en la línea privada. Conéctate con TLS desde el primer byte — sin paso de actualización, sin ventana para la interceptación.

Por qué existe esto

El correo electrónico ha utilizado históricamente tres puertos de texto sin cifrar para la comunicación cliente-servidor:

Puerto	Protocolo	Propósito
25	SMTP	Retransmisión servidor a servidor
143	IMAP	Acceso al buzón
110	POP3	Acceso al buzón
587	Envío	Envío de mensajes del cliente

Los cuatro comienzan como conexiones de texto sin cifrar. STARTTLS se agregó para actualizar estas conexiones a TLS a mitad de camino. Pero STARTTLS tiene debilidades sistémicas:

Ataques de degradación. Un atacante puede eliminar la capacidad STARTTLS de la respuesta del servidor, y muchos clientes recurren silenciosamente al texto sin cifrar.
Inyección de comandos previos a TLS. La fase de texto sin cifrar antes de que se complete STARTTLS permite que un atacante inyecte comandos SMTP que el servidor procesa después del protocolo de enlace TLS.
Exposición de credenciales. Si STARTTLS falla o se elimina, el cliente puede enviar credenciales de AUTH (nombre de usuario y contraseña) en texto sin cifrar.

RFC 8314 declara estas conexiones de texto sin cifrar obsoletas para el envío de correo electrónico y el acceso al buzón, e impone TLS implícito como reemplazo.

Cómo funciona

TLS implícito vs. STARTTLS

STARTTLS (la forma antigua): Conectarse a un puerto de texto sin cifrar, intercambiar saludos en texto sin cifrar, enviar un comando STARTTLS, negociar TLS, luego proceder con la sesión cifrada.

-- STARTTLS en puerto 587 (envío) --
220 mail.example.com ESMTP          ← saludo de texto sin cifrar
EHLO client.example.com             ← texto sin cifrar
250-mail.example.com                ← texto sin cifrar
250-STARTTLS                        ← el atacante puede eliminar esta línea
250 OK
STARTTLS                            ← texto sin cifrar
220 Go ahead                        ← texto sin cifrar
-- El protocolo de enlace TLS ocurre aquí --
EHLO client.example.com             ← ahora cifrado
AUTH PLAIN dXNlcjpwYXNz            ← cifrado (seguro)

TLS implícito (la forma RFC 8314): Conectarse a un puerto TLS dedicado. El protocolo de enlace TLS es lo primero que sucede. Sin fase de texto sin cifrar en absoluto.

-- TLS implícito en puerto 465 (envío de presentación) --
-- El protocolo de enlace TLS ocurre inmediatamente al conectarse --
220 mail.example.com ESMTP          ← cifrado desde el primer byte
EHLO client.example.com             ← cifrado
AUTH PLAIN dXNlcjpwYXNz            ← cifrado

Las asignaciones de puerto nuevas

Servicio	Antiguo (STARTTLS)	Nuevo (TLS implícito)	Nombre IANA
Envío de mensajes	587	465	`submissions`
IMAP	143	993	`imaps`
POP3	110	995	`pop3s`

El puerto 465 tiene un historial complicado. Se asignó originalmente para "SMTPS" a finales de los años noventa, luego se revocó a favor de STARTTLS en 587. RFC 8314 lo reasigna como submissions (nota la 's') para envío de TLS implícito. Esta vez es oficial y permanente.

¿Qué hay con el puerto 25?

El puerto 25 es para retransmisión servidor a servidor, no para envío de cliente. RFC 8314 no cambia el comportamiento del puerto 25. El SMTP servidor a servidor aún utiliza STARTTLS oportunista, con MTA-STS o DANE proporcionando cumplimiento. La distinción es importante: los clientes se autentican con credenciales (que deben protegerse), mientras que los servidores se autentican mediante DNS, DKIM y SPF.

Detalles técnicos clave

Requisitos de versión de TLS

RFC 8314 requiere TLS 1.2 o posterior. TLS 1.0 y 1.1 están deprecados por RFC 8996. En la práctica, debes requerir TLS 1.2 como mínimo y preferir TLS 1.3.

Validación de certificado

Con TLS implícito, los clientes deben validar el certificado del servidor contra el nombre de host esperado utilizando reglas estándar de PKI web. Este es un cambio significativo respecto a la era STARTTLS donde muchos clientes aceptaban cualquier certificado. El certificado debe:

Ser emitido por una entidad de certificación de confianza.
Coincidir con el nombre de host del servidor (el nombre al que se conecta el cliente, no necesariamente el nombre de host de MX).
No estar expirado ni revocado.

Registros SRV para descubrimiento de servicios

RFC 8314 funciona junto con RFC 6186 para configuración automática del cliente mediante registros SRV:

; Envío de TLS implícito (RFC 8314 + RFC 6186) _submissions._tcp.example.com. IN SRV 0 1 465 mail.example.com. ; IMAP de TLS implícito _imaps._tcp.example.com. IN SRV 0 1 993 mail.example.com. ; POP3 de TLS implícito _pop3s._tcp.example.com. IN SRV 0 1 995 mail.example.com.

Configuración del cliente

Para desarrolladores de aplicaciones que integran envío SMTP:

# Ejemplo de Python: TLS implícito en puerto 465
import smtplib

# Correcto: SMTP_SSL se conecta con TLS inmediatamente
with smtplib.SMTP_SSL('mail.example.com', 465) as smtp:
    smtp.login('user', 'password')
    smtp.send_message(msg)

# Evitar: STARTTLS en puerto 587 (heredado)
# with smtplib.SMTP('mail.example.com', 587) as smtp:
#     smtp.starttls()
#     smtp.login('user', 'password')

Errores comunes

Confundir puerto 465 con puerto 25. El puerto 465 es para envío de cliente con TLS implícito. El puerto 25 es para retransmisión servidor a servidor. Nunca uses el puerto 465 para entrega de MX.
Sigue ofreciendo texto sin cifrar en puerto 587 sin cumplimiento forzado de STARTTLS. Si debes soportar puerto 587, requiere STARTTLS antes de AUTH. Nunca permitas credenciales sobre una conexión de texto sin cifrar.
Desabilitar verificación de certificado. TLS implícito requiere validación adecuada de certificados. Establecer verify=False o equivalente anula completamente el propósito. Arregla el certificado en su lugar.
Usar TLS 1.0 o 1.1. Estos están oficialmente deprecados. Configura tu servidor para aceptar solo TLS 1.2 o posterior.
Tratar puerto 465 como "SMTPS" (la versión de los años noventa). El SMTPS antiguo fue revocado. El puerto 465 es ahora submissions según RFC 8314 — el mismo comportamiento subyacente (TLS implícito), pero oficialmente estandarizado con registro IANA apropiado.
No publicar registros SRV. Sin registros SRV _submissions._tcp, los clientes no pueden descubrir automáticamente tu punto de conexión de TLS implícito. Muchos aún usan STARTTLS predeterminado en 587.

Impacto en la entregabilidad

Protege credenciales del remitente. Para aplicaciones que usan envío SMTP (tu aplicación conectándose a un servicio de correo, por ejemplo), TLS implícito en puerto 465 asegura que tus credenciales de API nunca atraviesen la red sin cifrar — ni siquiera brevemente durante una actualización STARTTLS.
Establecimiento más rápido de conexión. TLS implícito ahorra un viaje de ida y vuelta en comparación con STARTTLS (sin intercambio EHLO + STARTTLS de texto sin cifrar). Para remitentes de alto volumen, esto se suma.
Requerido por proveedores principales. Google Workspace y Microsoft 365 ambos soportan TLS implícito en puerto 465. Es el método de envío recomendado para nuevas integraciones.
Elimina una clase de ataques. Eliminación de STARTTLS, inyección de comandos y captura de credenciales son todos imposibles con TLS implícito. Para entornos sensibles al cumplimiento, esto es importante.