TLS oportunista (seguridad de la capa de transporte) se refiere a extensiones en 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 separado para la comunicación cifrada. Varios protocolos utilizan un comando llamado " STARTTLS " para este propósito. Está pensado principalmente como una contramedida al monitoreo pasivo .
El comando STARTTLS para IMAP y POP3 se define 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 ha definido la extensión STARTTLS. FTP utiliza el comando "AUTH TLS" definido en RFC 4217 y LDAP define una extensión de protocolo OID en RFC 2830 . HTTP usa el encabezado de actualización .
Capas
TLS es una aplicación neutra; en las 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 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 a criterio de los diseñadores e implementadores de los protocolos que se ejecutan sobre TLS. [1]
El estilo utilizado para especificar cómo usar TLS coincide con la misma distinción de capa que también es convenientemente compatible con varias implementaciones de biblioteca de TLS. Por ejemplo, el La extensión RFC 3207 SMTP ilustra con el siguiente cuadro de diálogo cómo un cliente y un servidor pueden iniciar una sesión segura: [2]
S:C: S: 220 mail.example.org Servicio ESMTP listo C: EHLO client.example.org S: 250-mail.example.org ofrece un cálido abrazo de bienvenida S: 250 STARTTLS C: STARTTLS S: 220 Adelante C: C & S: C & S: C: EHLO client.example.org [3] . . .
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 la respuesta del servidor omitida ahora puede anunciar de forma segura una extensión AUTH PLAIN SMTP, 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 por SSL de protocolos conocidos. Estos establecen comunicaciones seguras y luego presentan un flujo de comunicación idéntico al antiguo protocolo no cifrado. Los puertos SSL separados tienen la ventaja de menos viajes de ida y vuelta ; también se transmiten menos metadatos en forma no cifrada. [4] Algunos ejemplos incluyen:
Protocolo | Propósito | Puerto normal | Variante SSL | Puerto SSL |
---|---|---|---|---|
SMTP | Enviar correo electrónico | 25/587 | SMTPS | 465 |
POP3 | Recuperar correo electrónico | 110 | POP3S | 995 |
IMAP | Leer el correo electrónico | 143 | IMAPS | 993 |
NNTP | Lector de noticias | 119/433 | NNTPS | 563 |
LDAP | Acceso al directorio | 389 | LDAPS | 636 |
FTP | Transferencia de archivos | 21 | FTPS | 990 |
Al menos para los protocolos relacionados con el correo electrónico, RFC 8314 favorece puertos SSL separados en lugar de STARTTLS.
Debilidades y mitigaciones
TLS oportunista es un mecanismo de cifrado oportunista . Debido a que el protocolo de enlace inicial tiene lugar en texto sin formato, un atacante que tenga el control de la red puede modificar los mensajes del servidor mediante un ataque de intermediario para que parezca que TLS no está disponible (lo que se denomina ataque STRIPTLS ). La mayoría de los clientes SMTP enviarán 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 ocurren entre servidores de correo, donde la notificación al usuario no es práctica.
En septiembre de 2014, se descubrió que dos ISP de Tailandia estaban haciendo esto con sus propios clientes. [5] [6] En octubre de 2014 , se reveló que Cricket Wireless , una subsidiaria de AT&T , estaba haciendo esto con sus clientes. Este comportamiento comenzó en septiembre de 2013 por Aio Wireless , quien luego se fusionó con Cricket donde continuó la práctica. [7] [5]
Los ataques STRIPTLS se pueden bloquear configurando clientes SMTP para que requieran TLS para conexiones salientes (por ejemplo, el agente de transferencia de mensajes Exim puede requerir TLS a través de la directiva "hosts_require_tls" [8] ). 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 : [9]
220 smtp.gmail.com ESMTP mail.redacted.com - gsmtp ehlo a 250-smtp.gmail.com a su servicio, [SERVICIO CENSURADO] TAMAÑO 250 35882577 250-8BITMIME # El comando STARTTLS se elimina aquí 250-CÓDIGOS DE ESTADO MEJORADOS 250-TUBERÍAS 250 SMTPUTF8
| 220 smtp.gmail.com ESMTP - gsmtp ehlo a 250-smtp.gmail.com a su servicio TAMAÑO 250 35882577 250-8BITMIME 250-STARTTLS 250-CÓDIGOS DE ESTADO MEJORADOS 250-TUBERÍAS 250 SMTPUTF8
|
Este problema se resuelve mediante la autenticación de entidades nombradas (DANE) basada en DNS , una parte de DNSSEC y, en particular, mediante RFC 7672 para SMTP. DANE permite anunciar soporte para SMTP seguro a través de un registro TLSA. Esto le dice a los clientes que se conectan que deben requerir TLS, evitando así los ataques STRIPTLS. El proyecto STARTTLS Everywhere de Electronic Frontier Foundation funciona de manera similar. Sin embargo, DNSSEC, debido a las complejidades de la implementación y las críticas peculiares [ aclaraciones necesarias ] , [10] enfrentó una baja tasa de adopción y un nuevo protocolo llamado SMTP MTA Strict Transport Security o MTA-STS ha sido redactado [11] por un grupo de correo electrónico importante proveedores de servicios, incluidos Microsoft, Google y Yahoo. MTA-STS no requiere el uso de DNSSEC para autenticar los registros DANE TLSA, pero 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 permite un grado de seguridad similar al de HPKP , reduciendo la complejidad pero sin las garantías de primer uso que ofrece DNSSEC. Además, MTA-STS introduce un mecanismo para la notificación de fallas y un modo de solo informe, lo que permite la implementación progresiva y la auditoría de cumplimiento.
Popularidad
Tras las revelaciones hechas por Edward Snowden a la luz del escándalo de vigilancia masiva global , los proveedores de correo electrónico populares han mejorado la seguridad de su correo electrónico al habilitar STARTTLS. [12] Facebook informó que después de habilitar STARTTLS y alentar a otros proveedores [ ambiguos ] a hacer lo mismo, hasta que Facebook descontinuó su servicio de correo electrónico en febrero de 2014, el 95% del correo electrónico saliente estaba encriptado tanto con Perfect Forward Secrecy como con una estricta validación de certificados. [13]
Referencias
- ^ 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 .
- ^ Paul Hoffman (febrero de 2002). "Extensión del servicio SMTP para SMTP seguro sobre la seguridad de la capa de transporte" . Editor de RFC . Consultado el 8 de octubre de 2009 .
- ^ Se agregó la última línea del ejemplo para mayor claridad. Ver, por ejemplo, el hilo iniciado por Paul Smith (26 de enero de 2009). "STARTTLS & EHLO" . lista de correo ietf-smtp . Consorcio de correo de Internet . Consultado el 16 de septiembre de 2015 .
- ^ Documentación de Dovecot SSL: http://wiki2.dovecot.org/SSL
- ^ a b Hoffman-Andrews, Jacob (11 de noviembre de 2014). "ISP quitando el cifrado de correo electrónico de sus clientes" . Fundación Frontera Electrónica . Consultado el 19 de enero de 2019 .
- ^ "Google, servidores de correo electrónico SMTP de Yahoo golpeados en Tailandia" . 12 de septiembre de 2014 . Consultado el 31 de julio de 2015 .
- ^ "La FCC debe evitar que los ISP bloqueen el cifrado" . 4 de noviembre de 2014 . Consultado el 31 de julio de 2015 .
- ^ "Exim Internet Mailer - El transporte smtp" . exim.org .
hosts_require_tls: Exim insistirá en usar una sesión TLS cuando entregue a cualquier host que coincida con esta lista.
- ^ "¿Quién llama a mi puerta? Comprender la vigilancia en Tailandia" (PDF) . Privacy International : 21 de enero de 2017 . Consultado el 7 de febrero de 2020 .
- ^ Thomas Ptacek (18 de marzo de 2016). "Contra DNSSEC" .
- ^ Ramakrishnan, Binu; Brotman, Alexander; Jones, Janet; Margolis, Daniel; Risher, Mark. "Seguridad de transporte estricta SMTP MTA (MTA-STS)" . tools.ietf.org . Consultado el 22 de febrero de 2019 .
- ^ Peterson, Andrea (12 de agosto de 2014). "El jefe de seguridad de Facebook sobre el efecto Snowden, la reacción de la aplicación Messenger y mantenerse optimista" . The Washington Post . Consultado el 2 de noviembre de 2014 .
- ^ Cohen, David (19 de agosto de 2014). "Facebook: 95% de los correos electrónicos de notificación encriptados gracias a la implementación de STARTTLS de los proveedores" . allfacebook.com . Archivado desde el original el 22 de septiembre de 2014.
enlaces externos
- Las pruebas y herramientas de correo electrónico seguro verifican STARTTLS en un cuadro de 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. "Seguridad de transporte estricta SMTP MTA (MTA-STS)" . IETF. Mecanismo que permite a los proveedores de servicios de correo declarar su capacidad para recibir conexiones SMTP seguras de Transport Layer Security (TLS).