TLS oportunista

El TLS oportunista (Transport Layer Security) se refiere a extensiones en protocolos de comunicación de texto plano que permiten actualizar una conexión de texto plano a una conexión cifrada ( TLS o SSL ) en lugar de utilizar un puerto independiente para la comunicación cifrada. Varios protocolos utilizan el comando " STARTTLS " o " TLS explícito " para este fin. Se trata de una forma de cifrado oportunista y su principal objetivo es contrarrestar la monitorización pasiva .

El comando STARTTLS para IMAP y POP3 está definido en RFC 2595 , para SMTP en RFC 3207 , para XMPP en RFC 6120 y para NNTP en RFC 4642. Para IRC , el Grupo de Trabajo de IRCv3 definió una extensión STARTTLS, aunque posteriormente fue descontinuada. ^{[ 1 ]} FTP utiliza el comando "AUTH TLS" definido en RFC 4217 y LDAP define una extensión de protocolo OID en RFC 2830. HTTP utiliza un encabezado upgrade .      

TLS es independiente de la aplicación; en palabras de RFC 5246 : 

Una ventaja de TLS es que es independiente del protocolo de aplicación. Los protocolos de nivel superior pueden superponerse al protocolo TLS de forma transparente. Sin embargo, el estándar TLS no especifica cómo los protocolos añaden seguridad con TLS; las decisiones sobre cómo iniciar el establecimiento de la conexión TLS y cómo interpretar los certificados de autenticación intercambiados quedan a criterio de los diseñadores e implementadores de los protocolos que se ejecutan sobre TLS. ^{[ 2 ]}

El estilo utilizado para especificar cómo usar TLS coincide con la misma distinción de capas que también es compatible con varias implementaciones de bibliotecas de TLS. Por ejemplo, la extensión SMTP RFC 3207 ilustra con el siguiente diálogo cómo un cliente y un servidor pueden iniciar una sesión segura: ^{[ 3 ]} 

 S: < espera conexión en el puerto TCP 25 > C: < abre conexión > S: 220 mail.example.org Servicio ESMTP listo C: EHLO client.example.org S: 250-mail.example.org ofrece una cálida bienvenida. S: 250 STARTTLS C: STARTTLS S: 220 Adelante C: < inicia la negociación TLS > C & S: < negocia una sesión TLS > C & S: < comprueba el resultado de la negociación > C: EHLO client.example.org [ 4 ] . . .

El último comando EHLO mencionado anteriormente se emite a través de un canal seguro. Tenga en cuenta que la autenticación es opcional en SMTP, y la respuesta del servidor omitida ahora puede anunciar de forma segura una extensión SMTP AUTH PLAIN , que no está presente en la respuesta en texto plano.

Además del uso de TLS oportunista, se definieron varios puertos TCP para versiones protegidas con SSL de protocolos conocidos. Estos establecen comunicaciones seguras y luego presentan un flujo de comunicación idéntico al del antiguo protocolo sin cifrar. Los puertos SSL separados tienen la ventaja de requerir menos viajes de ida y vuelta ; además, se transmite menos metadatos sin cifrar. ^{[ 5 ]} Algunos ejemplos incluyen:

Al menos en lo que respecta a los protocolos relacionados con el correo electrónico, el RFC 8314 favorece el TLS implícito (que utiliza puertos SSL separados) en lugar de STARTTLS. 

TLS oportunista es un mecanismo de cifrado oportunista . Dado que el intercambio inicial de claves se realiza en texto plano, un atacante que controle la red puede modificar los mensajes del servidor mediante un ataque de intermediario (man-in-the-middle) para simular que TLS no está disponible ( ataque STRIPTLS ). La mayoría de los clientes SMTP enviarán entonces el correo electrónico y, posiblemente, las contraseñas en texto plano, a menudo sin notificar al usuario. En particular, muchas conexiones SMTP se producen entre servidores de correo, donde la notificación al usuario no es práctica.

En septiembre de 2014, se descubrió que dos proveedores de servicios de Internet (ISP) en Tailandia estaban haciendo esto a sus propios clientes. ^{[ 6 ] [ 7 ]} En octubre de 2014, se reveló que Cricket Wireless , una subsidiaria de AT&T , estaba haciendo esto a sus clientes. Este comportamiento comenzó ya en septiembre de 2013 con Aio Wireless , que luego se fusionó con Cricket, donde la práctica continuó. ^{[ 8 ] [ 6 ]}

Los ataques STRIPTLS pueden bloquearse configurando los clientes SMTP para que requieran TLS para las conexiones salientes (por ejemplo, el agente de transferencia de mensajes Exim puede requerir TLS mediante la directiva "hosts_require_tls" ^{[ 9 ]} ). Sin embargo, dado que no todos los servidores de correo admiten TLS, no es práctico simplemente requerir TLS para todas las conexiones.

Un ejemplo de un ataque STRIPTLS del tipo utilizado en la tecnología de vigilancia masiva tailandesa : ^{[ 10 ]}

Suponiendo que el lado del cliente lo admita (resolución de nombres del cliente y servidor DNS ascendente del cliente), este problema puede abordarse mediante la Autenticación de Entidades Nombradas basada en DNS (DANE), una parte de DNSSEC , y en particular mediante RFC 7672 para SMTP. DANE permite anunciar la compatibilidad con SMTP seguro a través de un registro TLSA. Esto indica a los clientes que se conectan que deben requerir TLS, evitando así los ataques STRIPTLS. El proyecto STARTTLS Everywhere de la Electronic Frontier Foundation funciona de manera similar. Sin embargo, DNSSEC, debido a las complejidades de implementación y a críticas particulares, ^{[ 11 ]} tuvo una baja tasa de adopción y un nuevo protocolo llamado SMTP MTA Strict Transport Security o MTA-STS ha sido elaborado ^{[ 12 ]} por un grupo de importantes proveedores de servicios de correo electrónico, incluidos Microsoft, Google y Yahoo. MTA-STS no requiere el uso de DNSSEC para autenticar los registros DANE TLSA, sino que se basa en el sistema de autoridad de certificación (CA) y en un enfoque de confianza en el primer uso (TOFU) para evitar interceptaciones. El modelo TOFU reduce la complejidad, pero no ofrece las garantías de primer uso que proporciona DNSSEC. Además, MTA-STS introduce un mecanismo para la notificación de fallos y un modo de solo informe, lo que permite una implementación progresiva y la auditoría del cumplimiento. 

Tras las revelaciones de Edward Snowden a raíz del escándalo de vigilancia masiva global , los proveedores de correo electrónico más populares mejoraron la seguridad de sus correos electrónicos mediante la activación de STARTTLS. ^{[ 13 ]} Facebook informó que, tras activar STARTTLS y animar a otros proveedores a hacer lo mismo, hasta que Facebook suspendió su servicio de correo electrónico en febrero de 2014, el 95 % de los correos electrónicos salientes estaban cifrados con confidencialidad directa perfecta y validación estricta de certificados. ^{[ 14 ]}

• Las pruebas y herramientas de correo electrónico seguro verifican STARTTLS en un diálogo en tiempo real como el ejemplo anterior.
• Verifique si un dominio receptor tiene STARTTLS habilitado para correo electrónico y con qué nivel de seguridad.
• Margolis, Daniel; Risher, Mark; Ramakrishnan, Binu; Brotman, Alexander; Jones, Janet. "SMTP MTA Strict Transport Security (MTA-STS)" . IETF.Un mecanismo que permite a los proveedores de servicios de correo declarar su capacidad para recibir conexiones SMTP seguras mediante el protocolo TLS (Transport Layer Security).