¿Qué es STARTTLS?
El STARTTLS es el comando que hace que dos servidores de correo acuerden, en medio de una conversación que empezó abierta, pasar a intercambiar mensajes de forma cifrada. Es la razón por la cual hoy la mayor parte del correo viaja protegida, y también el origen de un malentendido caro: la protección es oportunista, ocurre cuando ambos lados pueden, y un atacante en el medio la derriba entera borrando una sola línea de la conversación. Estandarizado en 1999 y definido hoy por el RFC 3207, de 2002.
Cómo funciona el STARTTLS
La entrega de correo entre servidores ocurre por el protocolo SMTP y siempre empieza en texto abierto. El STARTTLS es una invitación hecha dentro de esa conversación abierta, y por eso depende de que la invitación llegue.
El servidor anuncia que acepta
Abierta la conexión, el remitente se presenta y el servidor de destino responde enumerando lo que sabe hacer. Si sabe cifrar, incluye en esa lista la línea 250 STARTTLS.
El remitente pide cambiar de canal
Al ver el anuncio, el servidor que envía responde pidiendo el cambio. Si el anuncio no está, no lo pide, y la conversación sigue abierta.
Los dos negocian la protección
Servidor y cliente acuerdan la versión y el cifrado que van a usar, y el canal pasa a estar cifrado a partir de ese punto.
El mensaje viaja protegido en ese tramo
Solo entonces se envía el contenido. La protección vale para ese salto entre dos servidores, no para el camino entero ni para el mensaje guardado en el buzón.
Fuente: RFC 3207, la especificación oficial vigente del STARTTLS, publicada por el IETF en 2002, que define la extensión del SMTP para uso de TLS (Transport Layer Security) y advierte, en sus Consideraciones de Seguridad, sobre el ataque de supresión del anuncio.
El punto ciego que la propia norma denuncia
- La protección es opcional por naturaleza. El STARTTLS solo entra en acción si el destino anuncia que sabe y el remitente decide pedirlo. Nada en el flujo estándar obliga a ninguno de los dos.
- Borrar una línea derriba el cifrado. El texto de la norma es explícito: un ataque en el medio del camino puede hacerse quitando la respuesta 250 STARTTLS del servidor, lo que hace que el remitente sencillamente no intente proteger la conversación.
- La caída es silenciosa. Cuando la invitación desaparece, nada falla y nadie recibe aviso: el mensaje se entrega con normalidad, en texto abierto, y ambos lados siguen creyendo que todo está bien.
- Cifrar no es identificar. La propia norma dice que creer o no en la autenticidad del otro lado es una decisión local de cada servidor, y en el uso oportunista el remitente suele aceptar el certificado que aparezca, así que el canal queda cerrado sin que nadie haya probado con quién está hablando.
Los tres estados posibles de una entrega
- Sin ningún cifrado Uno de los lados no supo o no quiso. El mensaje atraviesa internet legible en cualquier punto por el que pase. Sigue ocurriendo todos los días, en volumen.
- Cifrado oportunista El caso más común. Funciona bien cuando nadie interfiere, y es exactamente lo que el ataque de supresión desarma, porque el remitente acepta volver al texto abierto sin reclamar.
- Cifrado exigido El remitente se niega a entregar si el canal no puede protegerse y validarse. La propia norma prevé esa configuración, y es la que cierra el agujero. Lo que faltaba era una forma de que el destinatario anunciara esa exigencia, y eso llegó después, con el MTA-STS.
Qué está en juego mientras la protección es opcional
La cuenta de este diseño nunca aparece como un incidente, aparece como la ausencia de uno. Cuando el cifrado se derriba suprimiendo el anuncio, nada se rompe: el mensaje llega, el remitente no recibe error, el destinatario no recibe aviso, y el contenido viajó legible por donde haya pasado. Es la diferencia entre una puerta forzada, que se nota, y una puerta que nunca llegó a cerrarse con llave, que no se nota. Para una empresa eso importa porque el correo entre servidores lleva justamente lo que nadie quiere expuesto: la propuesta comercial con precio, datos de clientes, el adjunto de la nómina, la discusión de un contrato, el código de recuperación de contraseña. Y la exposición no depende del tamaño de la empresa, sino del tramo de internet por el que pasó el mensaje en ese salto.
Cómo salir del cifrado opcional
El STARTTLS resuelve la mitad del problema y no puede resolver la otra mitad por sí solo. El camino es agregar exigencia y medición a su alrededor:
- Asegúrese de que sus servidores lo anuncian y lo aceptanEs el piso, y todavía hay entornos que no lo cumplen. Sin el anuncio de su lado, ningún remitente del mundo puede proteger la entrega hacia usted.
- Mantenga el certificado válido y con el nombre correctoUn certificado vencido, o emitido para otro nombre, rompe la validación. Como en modo oportunista mucha gente lo acepta igual, el defecto pasa inadvertido hasta el día en que alguien empieza a exigir.
- Publique una exigencia de canal protegidoEs lo que hace el MTA-STS: declara al mundo que su entrada solo acepta una conversación cifrada y validada, sacando la decisión del calor del momento.
- Active los informes antes de exigirEl TLS-RPT devuelve todos los días lo que funcionó y lo que falló en la entrada de su dominio, y es lo que permite endurecer sin derribar remitentes legítimos.
- Trate esto como capa de transporte, no de contenidoProteger el salto entre servidores no protege el mensaje una vez entregado, ni prueba quién lo escribió. La autenticación del remitente y la protección del buzón son capas distintas que trabajan juntas.
En la práctica
El STARTTLS es una invitación a conversar en privado, y un tercero derriba esa invitación con solo fingir que nunca se hizo. Por eso la pregunta correcta nunca es si su correo usa cifrado, sino si alguien puede hacer que su correo deje de usarlo sin que nadie lo note. Mientras la respuesta sea sí, lo que existe es la posibilidad de protección, no la protección.
Cómo Zamak trata el cifrado de transporte
Zamak Technologies trata el canal de correo como algo que se mide, no como algo que se supone: verifica si el destino anuncia y acepta el cambio a canal protegido, si el certificado está válido y con el nombre correcto, y enciende el informe antes de proponer cualquier exigencia, junto al equipo que ya administra el entorno. En la práctica eso significa cerrar el agujero de esta página con las dos piezas que vienen después: el MTA-STS, que publica la exigencia de canal protegido, y el TLS-RPT, que mide si se está cumpliendo. La verificación de suplantación de correo da el primer retrato de lo que su dominio declara hoy. El seguimiento continuo de esa capa forma parte de la Seguridad de Correo Gestionada y de la Ciberseguridad gestionada del Método Zamak.