stringtranslate.com

TLS oportunista

El TLS oportunista (Transport Layer Security) hace referencia a extensiones de los protocolos de comunicación de texto sin formato que ofrecen una forma de actualizar una conexión de texto sin formato a una conexión cifrada ( TLS o SSL ) en lugar de utilizar un puerto independiente para la comunicación cifrada. Varios protocolos utilizan un comando denominado " STARTTLS " para este fin. Es una forma de cifrado oportunista y está pensado principalmente como una contramedida al monitoreo pasivo .

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 IRCv3 definió una extensión STARTTLS, aunque luego quedó obsoleta. [1] FTP utiliza el comando "AUTH TLS" definido en RFC  4217 y LDAP define un OID de extensión de protocolo en RFC  2830. HTTP utiliza un encabezado de actualización .

Capas

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 manera transparente. Sin embargo, el estándar TLS no especifica cómo los protocolos agregan seguridad con TLS; las decisiones sobre cómo iniciar el protocolo de enlace TLS y cómo interpretar los certificados de autenticación intercambiados se dejan al criterio de los diseñadores e implementadores de protocolos que se ejecutan sobre TLS. [2]

El estilo utilizado para especificar cómo utilizar 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: cliente EHLO.ejemplo.org S: 250-mail.example.org le ofrece un cálido abrazo de bienvenida S: 250 STARTTLS C: STARTTLS S: 220 Adelante C: <inicia negociación TLS> C&S: <negociar una sesión TLS> C&S: <verificar resultado de negociación> C: cliente EHLO.ejemplo.org [4] . . .

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

Puertos SSL

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 antiguo protocolo sin cifrar. Los puertos SSL separados tienen la ventaja de que se realizan menos viajes de ida y vuelta ; también se transmiten menos metadatos en forma no cifrada. [5] Algunos ejemplos incluyen:

Al menos para los protocolos relacionados con el correo electrónico, RFC  8314 favorece puertos SSL separados en lugar de STARTTLS.

Debilidades y mitigaciones

El TLS oportunista es un mecanismo de cifrado oportunista . Debido a que el protocolo de enlace inicial se realiza en texto sin formato, un atacante que controle la red puede modificar los mensajes del servidor mediante un ataque de intermediario para que parezca que el TLS no está disponible (denominado ataque STRIPTLS ). La mayoría de los clientes SMTP enviarán entonces el correo electrónico y posiblemente las contraseñas en texto sin formato, a menudo sin notificación al usuario. [ cita requerida ] 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 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. Esta conducta comenzó ya en septiembre de 2013 por parte de Aio Wireless , que luego se fusionó con Cricket, donde la práctica continuó. [8] [6]

Los ataques STRIPTLS se pueden bloquear 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 resulta 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 se puede solucionar mediante la autenticación basada en DNS de entidades nombradas (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 forma similar. Sin embargo, DNSSEC, debido a las complejidades de la implementación y a las peculiares [ aclaración necesaria ] críticas, [11] enfrentó una baja tasa de adopción y un nuevo protocolo llamado SMTP MTA Strict Transport Security o MTA-STS ha sido redactado [12] por un grupo de los principales proveedores de servicios de correo electrónico, incluidos Microsoft, Google y Yahoo. MTA-STS no requiere el uso de DNSSEC para autenticar los registros TLSA de DANE, 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 intercepciones. El modelo TOFU reduce la complejidad, pero sin las garantías en el primer uso que ofrece DNSSEC. Además, MTA-STS introduce un mecanismo para informar errores y un modo de solo informes, lo que permite una implementación progresiva y una auditoría para el cumplimiento.

Popularidad

Tras las revelaciones realizadas por Edward Snowden a la luz del escándalo de vigilancia masiva global , los proveedores de correo electrónico populares han mejorado su seguridad de correo electrónico al habilitar STARTTLS. [13] Facebook informó que después de habilitar STARTTLS y alentar a otros proveedores [ ambiguo ] a hacer lo mismo, hasta que Facebook suspendió su servicio de correo electrónico en febrero de 2014, el 95% del correo electrónico saliente estaba cifrado con Perfect Forward Secrecy y una estricta validación de certificados. [14]

Referencias

  1. ^ "Extensión tls". Grupo de trabajo IRCv3. 2012. Consultado el 6 de abril de 2024 .
  2. ^ Tim Dierks; Eric Rescorla (agosto de 2008). "El protocolo de seguridad de la capa de transporte (TLS)". Editor de RFC . Consultado el 8 de octubre de 2009 .
  3. ^ Paul Hoffman (febrero de 2002). "Extensión del servicio SMTP para SMTP seguro sobre seguridad de la capa de transporte". Editor de RFC . Consultado el 8 de octubre de 2009 .
  4. ^ Se agregó la última línea del ejemplo para mayor claridad. Véase, por ejemplo, el hilo iniciado por Paul Smith (26 de enero de 2009). "STARTTLS & EHLO". Lista de correo ietf-smtp . Internet Mail Consortium . Consultado el 16 de septiembre de 2015 .
  5. ^ Documentación de Dovecot SSL: http://wiki2.dovecot.org/SSL
  6. ^ ab Hoffman-Andrews, Jacob (11 de noviembre de 2014). «Los ISP eliminan el cifrado de correo electrónico de sus clientes». Electronic Frontier Foundation . Consultado el 19 de enero de 2019 .
  7. ^ "Servidores de correo electrónico SMTP de Google y Yahoo atacados en Tailandia". 12 de septiembre de 2014. Consultado el 31 de julio de 2015 .
  8. ^ "La FCC debe impedir que los ISP bloqueen el cifrado". 4 de noviembre de 2014. Consultado el 31 de julio de 2015 .
  9. ^ "Exim Internet Mailer - El transporte SMTP". exim.org . hosts_require_tls - Exim insistirá en utilizar una sesión TLS al realizar entregas a cualquier host que coincida con esta lista.
  10. ^ "¿Quién llama a mi puerta? Entender la vigilancia en Tailandia" (PDF) . Privacy International : 21 de enero de 2017. Consultado el 7 de febrero de 2020 .
  11. ^ Thomas Ptacek (18 de marzo de 2016). "Contra DNSSEC".
  12. ^ Ramakrishnan, Binu; Brotman, Alexander; Jones, Janet; Margolis, Daniel; Risher, Mark. "Seguridad de transporte estricta de MTA SMTP (MTA-STS)". tools.ietf.org . Consultado el 22 de febrero de 2019 .
  13. ^ Peterson, Andrea (12 de agosto de 2014). "El jefe de seguridad de Facebook habla del efecto Snowden, la reacción negativa a la aplicación Messenger y el optimismo". The Washington Post . Consultado el 2 de noviembre de 2014 .
  14. ^ Cohen, David (19 de agosto de 2014). "Facebook: el 95 % de los correos electrónicos de notificación están cifrados gracias a la implementación de STARTTLS por parte de los proveedores". allfacebook.com . Archivado desde el original el 22 de septiembre de 2014.

Enlaces externos