Resumen

  • STARTTLS introdujo TLS dentro de una conexión SMTP ya abierta, pero no heredó la autoridad del diálogo inicial: después del apretón de manos se borraba el conocimiento previo y el cliente enviaba un nuevo EHLO.
  • El reinicio impedía que afirmaciones modificables en claro gobernaran el canal protegido. No hacía obligatorio el cifrado ni autenticaba toda la ruta; DANE y MTA-STS añadieron después pruebas externas capaces de impedir el retroceso silencioso.

Una conexión, dos comienzos

SMTP empezaba con el saludo 220 del servidor. El cliente se presentaba mediante EHLO y recibía una lista de extensiones. STARTTLS, publicado inicialmente en 1999, añadió una sola palabra sin parámetros a esa lista. El cliente podía responder STARTTLS; otro 220 cerraba la fase en claro y daba paso a TLS.

La solución conservaba el puerto y el sistema MX existentes. Los clientes antiguos seguían funcionando y los nuevos descubrían seguridad en la conexión que ya habían establecido. No era necesario partir el correo público en dos redes incompatibles.

Pero el descubrimiento sucedía antes de la protección. Un adversario en el camino podía cambiar el primer EHLO, borrar una extensión o retirar la línea STARTTLS. Los bytes iniciales servían para llegar a la frontera criptográfica, no para tomar decisiones autorizadas después de cruzarla.

El cifrado exigió amnesia

Por eso el protocolo vuelve a su estado inicial cuando termina TLS. El servidor descarta el nombre que recibió en el primer EHLO; el cliente descarta la primera lista de capacidades. A continuación, el cliente se presenta otra vez.

El segundo EHLO pertenece a un contexto distinto. El servidor puede anunciar un método de autenticación solo después de recibir un certificado cliente adecuado. El cliente puede evaluar el nombre del servidor y aceptar funciones bajo la política que corresponda al canal protegido. Nada aprendido en claro adquiere autoridad retroactiva.

La frontera también ordena los bytes. Tras recibir 220, el cliente debe comenzar TLS antes de cualquier otro comando SMTP. En una agrupación PIPELINING, STARTTLS ocupa el último lugar. Así se evita confundir un comando en claro con el inicio del apretón de manos o trasladar una decisión del estado viejo al nuevo.

Un canal cifrado todavía necesitaba un juicio

TLS puede aportar secreto, integridad y autenticación, pero una negociación terminada no define por sí sola si el resultado es suficiente. El nombre esperado, las autoridades de certificación, los algoritmos y las credenciales del cliente son materia de política local. Cualquiera de las partes puede abandonar la sesión.

Esta separación contiene el significado del cifrado. Proteger un salto contra escucha pasiva no siempre autentica al MX previsto. Autenticar un relé no autentica al autor humano. Un salto TLS no demuestra cómo viajaron el mensaje anterior ni el siguiente.

La respuesta 454 hace visible el dilema operativo. Si TLS no está disponible temporalmente, el emisor decide entre enviar en claro, esperar o fallar. STARTTLS ofrece el mecanismo; no concede al software permiso automático para revelar el contenido.

La interoperabilidad limitó el mandato inicial

Un MX público debía recibir correo de sistemas que aún no entendían la extensión. RFC 3207 prohibió exigir STARTTLS como condición general para entrega local en un servidor públicamente referenciado del puerto 25. Un servicio privado o una política de retransmisión sí podía exigirlo.

Esa compatibilidad facilitó la adopción gradual, pero dejó la oferta sin memoria obligatoria. Si un atacante eliminaba STARTTLS, un cliente oportunista podía interpretar la ausencia como incapacidad normal y continuar en claro.

El problema no era una rotura de TLS. Era que la obligación de usar TLS aparecía dentro del mismo intercambio sin protección que un atacante podía editar.

La política salió del diálogo

DANE para SMTP publicó mediante DNSSEC registros TLSA asociados al destino. Una respuesta TLSA segura comunicaba tanto la exigencia del canal como material para autenticarlo. Cuando esa prueba existía, perder la línea STARTTLS ya no autorizaba la entrega: el mensaje debía esperar.

MTA-STS eligió otra dependencia. El receptor señalaba una política, la servía por HTTPS y el emisor guardaba durante un plazo los MX aceptables y la validación PKIX requerida. En modo de aplicación, la falta de STARTTLS o un certificado inválido producía aplazamiento. El primer descubrimiento conservaba un riesgo diferente porque no contaba con la negación autenticada de DNSSEC, pero la caché reducía las oportunidades posteriores.

Ambos mecanismos conservaron STARTTLS como transición dentro de SMTP. Lo que trasladaron fue la autoridad para responder a su ausencia.

La segunda presentación fue la innovación duradera

Recordar STARTTLS solo como un cambio de texto a cifrado oculta la lección. El protocolo puso fecha de caducidad al estado anterior. Las afirmaciones recibidas antes del canal no quedaban bendecidas por él. Las capacidades se descubrían otra vez, la identidad se juzgaba mediante reglas explícitas y el retroceso podía distinguirse de una simple avería.

Cada protocolo antiguo que incorpora seguridad afronta la misma deuda. Una capa criptográfica nueva no limpia las decisiones ya tomadas con entradas controlables por un atacante. Hay que nombrar qué estado sobrevive, qué estado se elimina y quién puede autorizar una protección menor.

Fuentes y límites

El diseño inicial y la advertencia sobre el borrado de la oferta están en RFC 2487. Las reglas revisadas, el reinicio y el límite de interoperabilidad aparecen en RFC 3207. RFC 7672 define DANE para SMTP y RFC 8461 define MTA-STS. Ninguna de estas normas mide el despliegue actual ni el volumen global de ataques.