SMTP STS: SMTP Strict Transport Security

El correo electrónico es uno de los servicios más antiguos y arraigados en Internet. De hecho, el protocolo SMTP disfruta de tener como Well-Known Port el número 25, dejando claro que cuando nació este servicio no había muchos otros alrededor de él. Está muy arraigado, pero su larga historia ha hecho que casi se convierta en un collage de cabeceras que se adjuntan en cada mensaje a modo de remiendo para lograr hacer de él un servicio seguro, ya que no se pensó en la seguridad cuando se concibió. 

Figura 1: SMTP STS (SMTP Strict Transport Security)

Para ir solucionando problemas de seguridad hemos visto como se han añadido cabeceras "X-" fuera de estándar para atacar un determinado problema, o como se expandía el uso de soluciones como SPF, Sender ID, Identified Mail, DKIM, etcétera, para evitar problemas de suplantación, manipulación del mensaje, reducir el Spam mediante cabeceras calificaciones SCL (Spam Confidence Level). Hemos añadido RBLs, filtros bayesianos, búsquedas inversas de PTR, etcétera. Todo para intentar hacer que el correo electrónico pudiera ir superando los ataques a los que se iba enfrentando.

Desde el punto de vista de privacidad, uno de los problemas  que tiene el correo electrónico es el del reenvío de mensajes entre servidores SMTP para conseguir que ningún hombre en medio pueda acceder al contenido de los mensajes. Este problema no existiría si en la industria hubiéramos conseguido que el cifrado end-to-end entre destinatarios utilizando PGP o S/MIME se hubiera hecho lo suficientemente usable como para que todos los usuarios del mundo lo usasen por defecto, pero por desgracia no ha sido así.

Figura : WebPG, un intento de hacer PGP más usable en Gmail

Asumiendo que no hay cifrado end-to-end, lo que se busca es conseguir al menos que, la parte que no depende del usuario vaya cifrada. Es decir, que la conexión entre el cliente de correo electrónico y servidor de correo saliente vaya con SMTP-s o IMAP y que la conexión de SMTP Relay que va entre el servidor de correo saliente del emisor y el servidor de correo entrante del destinatario - o cualquier otro salto de enrutamiento que pudiera estar configurado - vaya cifrada con un túnel TLS. 

Para conseguir este cifrado hemos visto diferentes soluciones que van desde poner rutas de reenvío fijadas con TLS para que no sea opcional o el uso de Mutual TLS en los servidores de las organizaciones. Pero hay que conseguir que esto se utilice. Hay que conseguir que el cliente configure su cuenta como SMTP-s o IMAP, hay que configurar el Mutual TLS en las organizaciones o hay que hacer que los SMTP Relays vayan con TLS siempre y no es fácil conseguir vencer una tendencia.

Figura: El candado rojo de Gmail para avisar del NO uso de cifrado

Una iniciativa para apoyar esto ha sido el uso del candadito rojo en los mensajes de Gmail, donde se informa al usuario de si el correo electrónico que se recibe ha llegado vía túnel TLS cifrado o en claro en algún tramo, lo que haría que pudiera haber sido interceptado por cualquiera. 

Figura: Draft que describe SMTP STS

Ahora, un grupo de ingenieros ha propuesto migrar el uso de las cabeceras STS (Strict Transport Security) que se utilizan en HTTP bajo el protocolo HSTS (HTTP Strict Transport Security) al entorno SMTP. Para ello han publicado en Internet un documento de 19 páginas en el que abogan por la implantación de un sistema de Certificate Pinning similar al que se utiliza en la web, reduciendo las posibilidades de los ataques de downgrade que se pueden hacer al protocolo SMTP con las cabeceras STARTTLS.

Figura: Cabeceras STS para SMTP descritas en el draft

La idea es conseguir desplegar SMTP STS y lograr que las conexiones a un servidor SMTP se hagan utilizando un certificado digital validado para ese servidor y que esa validación se pueda hacer vía DANE (DNS-Based Authentication of Name Entities) y como complemento utilizando STS con una confianza en el primer intercambio o en el primer uso. Al final, lo que propone el draft es incrementar el uso de los túneles TLS mediante la automatización de un sistema de confianza en los certificados digitales usando STS, que en HTTP hay que reconocer que ha funcionado razonablemente bien y, a pesar de tener aún limitaciones, ha reducido sustancialmente los ataques de Hijacking y Tampering en las webs en las que se hace uso de HSTS.

Saludos Malignos!