Q1. ¿Puede contarnos brevemente la historia de origen de Session y qué lo motivó a construir una red de mensajería descentralizada?
Session es la creación conjunta de cientos de contribuyentes de todo el mundo; esa es la belleza del software de código abierto; cualquiera puede escribir y contribuir con código a la base de código de Session. Sin embargo, cada producto tiene una historia fundacional más central. Para Session, los fundadores originales querían construir una aplicación de prueba de concepto sobre una red descentralizada recién establecida. Pensamos que la mejor aplicación de prueba de concepto era construir una aplicación de mensajería que almacenara y dirigiera mensajes a través de esta red descentralizada, porque una vez que tenías un mensajero básico, podías generalizar este concepto a muchas otras aplicaciones que a menudo se reducen a pasar mensajes de un dispositivo a otro. Session se lanzó bajo un nombre diferente y creció inmediatamente. Quedó claro que la atención debería centrarse en Session, y lo que originalmente se diseñó como una prueba de concepto se convirtió en una de las aplicaciones de mensajería privada más grandes disponibles hoy en día.
Q2. La reciente directiva de emergencia de CISA identificó dos fallos críticos en TM SGNL. Desde tu perspectiva, ¿qué salió mal en el diseño o la implementación que permitió a los atacantes recopilar registros de chat y metadatos?
Este es un caso clásico de problemas de diseño e implementación en cascada que, por sí mismos, pueden no ser explotables, pero cuando se combinan pueden causar una falla catastrófica en la seguridad de una red.
El primer fallo fue en el diseño, TeleMessage tomó Signal, una aplicación de mensajería segura de gran renombre, y agregó lo que equivale a una puerta trasera intencionada en la aplicación con el propósito de crear un registro de auditoría. La forma en que funcionaba este registro de auditoría era enviando una copia de cada mensaje que un usuario enviaba, antes de que fuera cifrado de extremo a extremo, a un único servidor central, que luego almacenaría una copia de todos estos mensajes en un estado no cifrado. Esto creó la trampa para atacantes de datos extremadamente sensibles, un tesoro de información de seguridad nacional irresistible para los hackers.
El segundo fallo fue una mala configuración de un servicio (Spring Boot Actuator) que se ejecutaba en el servidor de archivos TM SGNL. Este es un problema de mala configuración muy básico, donde una URL que normalmente utilizan los desarrolladores para diagnosticar errores quedó abierta para que cualquiera pudiera usarla sin autenticación. Esto permitió a los atacantes volcar la memoria del servidor, en ese volcado se podían ver mensajes sin cifrar e información de autenticación de los usuarios en texto plano, lo que permitió a los hackers recuperar mensajes e información de cuentas.
Es importante señalar que ambas fallas necesitaban coexistir para que ocurriera un hackeo de esta magnitud. Este es a menudo el caso en las brechas de ciberseguridad, donde los atacantes encuentran un único defecto de diseño o implementación y luego utilizan ese defecto para encontrar otras vulnerabilidades que explotar.
Q3. ¿Qué tan común es que los clientes E2EE—incluso los compatibles con Signal—introduzcan tales debilidades, y por qué no se detectan antes?
Las aplicaciones de mensajería de consumo comunes como WhatsApp, Signal y Telegram suelen tener una seguridad mucho mejor alrededor de sus servidores que la que tenían los servidores de TeleMessage. Sin embargo, cuando se trata de aplicaciones de mensajería desarrolladas y modificadas explícitamente para crear un registro de auditoría de conversiones, es más común ver este tipo de configuraciones incorrectas. Especialmente cuando esas aplicaciones tienen código cerrado, los investigadores de seguridad de la comunidad no tienen la misma capacidad para analizar el código en busca de debilidades, por lo que las configuraciones incorrectas comunes pueden permanecer sin descubrir durante mucho tiempo o ser mantenidas en secreto por hackers a nivel estatal para mantener puertas traseras en los sistemas que no se corrigen.
Q4. Has argumentado que mientras un único proveedor controle partes clave de la pila, hay un riesgo inherente. ¿Cómo se traduce la centralización de proveedores en fallos de privacidad en el mundo real?
La centralización del proveedor suele combinarse con código de fuente cerrada y servidores centralizados. Cuando un servicio de mensajería almacena todos los mensajes de los usuarios en una única ubicación central, crea un objetivo para los atacantes; saben que al vulnerar un solo servidor obtienen acceso a todos los mensajes enviados a través del servicio. Cuando se combina con código de fuente cerrada que no puede ser revisado por investigadores y auditores de seguridad de código abierto, el incentivo para los atacantes aumenta, y los errores que podrían haber sido descubiertos pasan desapercibidos para todos menos para los atacantes más sofisticados que mantienen estos errores en privado para poder persistir su acceso a puerta trasera, dejando a todos los usuarios del servicio comprometidos.
Q5. ¿Podrías compartir un ejemplo ( fuera de TM SGNL) donde un defecto del lado del vendedor socavó las garantías del cifrado de extremo a extremo?
El uso de Twilio por parte de Signal para la verificación por SMS resultó en que algunas cuentas de usuarios de Signal fueran comprometidas cuando Twilio fue hackeado. Dado que la verificación por SMS es una de las maneras en que los usuarios de Signal pueden recuperar sus cuentas, cuando Twilio fue hackeado, los atacantes pudieron engañar a los servidores de Signal para que pensaran que poseían el número de teléfono de un usuario de Signal y recuperar su cuenta, utilizando este acceso para enviar mensajes no autorizados desde las cuentas de esos usuarios de Signal.
Q6. ¿Por qué crees que la descentralización es la única forma de mitigar completamente el riesgo de un solo proveedor?
La descentralización es la única forma de mitigar completamente el riesgo de un solo proveedor porque elimina el punto único de fallo inherente a cualquier sistema centralizado. Cuando una sola entidad controla partes clave de la pila – desde las identidades de los usuarios hasta el enrutamiento y almacenamiento de mensajes – se convierten en un objetivo irresistible para los atacantes, y sus fallas de diseño o implementación pueden tener consecuencias catastróficas, como se ha visto con TM SGNL.
En una red descentralizada, no hay un servidor central que pueda ser vulnerado, ninguna empresa única que pueda ser presionada para insertar puertas traseras, y ninguna base de datos única que pueda ser objetivo de la recopilación de metadatos. Las identidades de los usuarios son a menudo claves criptográficas, no identificadores del mundo real vinculados a una autoridad central. Los mensajes son enrutados y almacenados en una red distribuida de nodos independientes, lo que significa que ningún nodo ve tanto las direcciones IP del remitente como del receptor, y ninguna entidad única puede recopilar un registro completo de las comunicaciones.
Esta distribución de poder y datos hace que el sistema sea inherentemente más resistente a ataques, censura y explotación de datos porque no hay un único punto de estrangulación que explotar. La seguridad no depende de la confiabilidad de una sola empresa, sino de la integridad colectiva y el diseño criptográfico robusto de la red distribuida.
Q7. Session utiliza una red de nodos de servicio. ¿Cómo garantiza esta arquitectura que ninguna parte pueda comprometer los datos del usuario?
A diferencia de las aplicaciones de mensajería tradicionales, Session no depende de un único servidor central que almacene todos los datos de los usuarios. En su lugar, los mensajes se envían a través de una red distribuida de miles de nodos de Session operados de manera independiente por la comunidad. Esto elimina el efecto "honeypot" de una base de datos centralizada única, lo que hace extremadamente difícil que cualquier entidad única pueda recopilar mensajes cifrados y metadatos de manera integral. Los nodos de Session almacenan temporalmente los mensajes para los destinatarios que están fuera de línea. Sin embargo, estos mensajes están cifrados de extremo a extremo, lo que significa que los nodos mismos no pueden leer el contenido. Además, los mensajes solo se almacenan por un tiempo limitado (Time-To-Live) y pueden ser eliminados una vez leídos, evitando la retención a largo plazo en la red de nodos.
Además, Session utiliza una técnica de enrutamiento en cebolla modificada, similar a Tor. Cuando envías un mensaje, se cifra en capas, y cada capa es retirada por nodos de Session sucesivos. Lo crucial es que ningún nodo individual conoce tanto la dirección IP del remitente como la del destinatario. Esto significa que incluso si un nodo fuera comprometido, no podría vincular un mensaje a su origen o destino.
Las cuentas de sesión se generan criptográficamente sin requerir información personal como números de teléfono o direcciones de correo electrónico. Esto significa que no hay una identidad del mundo real vinculada a tu ID de Cuenta de Sesión, lo que mejora aún más la privacidad y dificulta la compromisión de la identidad de un usuario a través de violaciones de datos externas.
Este enfoque multicapas, sin un punto central de control, almacenamiento temporal, cifrado de extremo a extremo y enrutamiento anonimizado, asegura que incluso si un pequeño número de Nodos de Sesión se viera comprometido, la integridad y privacidad general de la red permanecerían intactas.
Q8. Dada la implementación de TM SGNL en agencias federales, ¿ves a los gobiernos moviéndose hacia un mensajería realmente descentralizada? ¿Qué barreras existen para ese cambio?
Esa es una pregunta difícil. Las agencias gubernamentales generalmente requieren que se creen y almacenen registros de auditoría de manera que sean visibles para un auditor, esto crea una vulnerabilidad de seguridad inherente, el cifrado de extremo a extremo está diseñado para que solo los participantes de la conversación puedan ver el contenido de las comunicaciones. El requisito de auditoría introduce una puerta trasera intencionada en el cifrado de extremo a extremo, lo cual es difícil de implementar de manera segura.
Sin embargo, hay formas en que esto se puede gestionar mejor, por ejemplo, el registro de auditoría siempre debe almacenarse cifrado en reposo y debe haber protecciones robustas alrededor de los usuarios que pueden acceder a ese registro de auditoría. Los gobiernos deben utilizar herramientas de código abierto que pueden ser fácilmente auditadas y pensar con extrema cautela sobre cómo se almacenan los registros de auditoría y en qué servidores se almacenan.
Si la regulación se actualizara, podría ofrecer una forma de aprovechar mejor las soluciones descentralizadas en las comunicaciones gubernamentales.
Q9. ¿Cómo persuadirías a una organización consciente de la seguridad para que migre de un cliente propietario compatible con Signal a Session?
Creo que el hackeo de TM SGNL proporciona el incentivo más claro hasta ahora para que los usuarios se alejen de soluciones técnicas propietarias hacia herramientas de código abierto como Session, que ofrecen características de seguridad y privacidad mucho más avanzadas. Puede ser posible en el futuro que las organizaciones tomen herramientas de código abierto como Session y desarrollen sus propias herramientas de auditoría que se integren en estas herramientas. Sin embargo, tales soluciones de auditoría también deben ser de código abierto y auditables para asegurar que no veamos los mismos problemas que resurgieron con TM SGNL.
P10. Mirando hacia adelante, ¿qué características o mejoras importantes están en la hoja de ruta de Session para los próximos 12‒18 meses? En última instancia, ¿cuál es su visión a largo plazo para Session y para la mensajería segura y privada en general?
El enfoque actual de Session es alcanzar a más usuarios. Session ya tiene más de un millón de usuarios activos mensuales, pero queremos ver aún más usuarios eligiendo soluciones que incorporen una fuerte privacidad y seguridad en el núcleo del diseño de la aplicación. Los colaboradores de Session están trabajando actualmente en un conjunto premium de características para usuarios avanzados de Session que permiten un financiamiento sostenible para el ecosistema de Session. Esto incluye características como grupos más grandes, mayor personalización del perfil y tamaños de archivo aumentados, todas características que aumentan la utilidad de Session.
En términos más amplios, veo a Session como la única aplicación que ofrece tanto privacidad de contenido como de metadatos en una experiencia altamente consumible y fácil de usar, y creo que a medida que las violaciones de datos continúan afectando a los usuarios, Session seguirá creciendo en los próximos 12-18 meses.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Reinventando la mensajería segura: un análisis profundo con el cofundador de Session Kee Jefferys
Q1. ¿Puede contarnos brevemente la historia de origen de Session y qué lo motivó a construir una red de mensajería descentralizada?
Session es la creación conjunta de cientos de contribuyentes de todo el mundo; esa es la belleza del software de código abierto; cualquiera puede escribir y contribuir con código a la base de código de Session. Sin embargo, cada producto tiene una historia fundacional más central. Para Session, los fundadores originales querían construir una aplicación de prueba de concepto sobre una red descentralizada recién establecida. Pensamos que la mejor aplicación de prueba de concepto era construir una aplicación de mensajería que almacenara y dirigiera mensajes a través de esta red descentralizada, porque una vez que tenías un mensajero básico, podías generalizar este concepto a muchas otras aplicaciones que a menudo se reducen a pasar mensajes de un dispositivo a otro. Session se lanzó bajo un nombre diferente y creció inmediatamente. Quedó claro que la atención debería centrarse en Session, y lo que originalmente se diseñó como una prueba de concepto se convirtió en una de las aplicaciones de mensajería privada más grandes disponibles hoy en día.
Q2. La reciente directiva de emergencia de CISA identificó dos fallos críticos en TM SGNL. Desde tu perspectiva, ¿qué salió mal en el diseño o la implementación que permitió a los atacantes recopilar registros de chat y metadatos?
Este es un caso clásico de problemas de diseño e implementación en cascada que, por sí mismos, pueden no ser explotables, pero cuando se combinan pueden causar una falla catastrófica en la seguridad de una red.
El primer fallo fue en el diseño, TeleMessage tomó Signal, una aplicación de mensajería segura de gran renombre, y agregó lo que equivale a una puerta trasera intencionada en la aplicación con el propósito de crear un registro de auditoría. La forma en que funcionaba este registro de auditoría era enviando una copia de cada mensaje que un usuario enviaba, antes de que fuera cifrado de extremo a extremo, a un único servidor central, que luego almacenaría una copia de todos estos mensajes en un estado no cifrado. Esto creó la trampa para atacantes de datos extremadamente sensibles, un tesoro de información de seguridad nacional irresistible para los hackers.
El segundo fallo fue una mala configuración de un servicio (Spring Boot Actuator) que se ejecutaba en el servidor de archivos TM SGNL. Este es un problema de mala configuración muy básico, donde una URL que normalmente utilizan los desarrolladores para diagnosticar errores quedó abierta para que cualquiera pudiera usarla sin autenticación. Esto permitió a los atacantes volcar la memoria del servidor, en ese volcado se podían ver mensajes sin cifrar e información de autenticación de los usuarios en texto plano, lo que permitió a los hackers recuperar mensajes e información de cuentas.
Es importante señalar que ambas fallas necesitaban coexistir para que ocurriera un hackeo de esta magnitud. Este es a menudo el caso en las brechas de ciberseguridad, donde los atacantes encuentran un único defecto de diseño o implementación y luego utilizan ese defecto para encontrar otras vulnerabilidades que explotar.
Q3. ¿Qué tan común es que los clientes E2EE—incluso los compatibles con Signal—introduzcan tales debilidades, y por qué no se detectan antes?
Las aplicaciones de mensajería de consumo comunes como WhatsApp, Signal y Telegram suelen tener una seguridad mucho mejor alrededor de sus servidores que la que tenían los servidores de TeleMessage. Sin embargo, cuando se trata de aplicaciones de mensajería desarrolladas y modificadas explícitamente para crear un registro de auditoría de conversiones, es más común ver este tipo de configuraciones incorrectas. Especialmente cuando esas aplicaciones tienen código cerrado, los investigadores de seguridad de la comunidad no tienen la misma capacidad para analizar el código en busca de debilidades, por lo que las configuraciones incorrectas comunes pueden permanecer sin descubrir durante mucho tiempo o ser mantenidas en secreto por hackers a nivel estatal para mantener puertas traseras en los sistemas que no se corrigen.
Q4. Has argumentado que mientras un único proveedor controle partes clave de la pila, hay un riesgo inherente. ¿Cómo se traduce la centralización de proveedores en fallos de privacidad en el mundo real?
La centralización del proveedor suele combinarse con código de fuente cerrada y servidores centralizados. Cuando un servicio de mensajería almacena todos los mensajes de los usuarios en una única ubicación central, crea un objetivo para los atacantes; saben que al vulnerar un solo servidor obtienen acceso a todos los mensajes enviados a través del servicio. Cuando se combina con código de fuente cerrada que no puede ser revisado por investigadores y auditores de seguridad de código abierto, el incentivo para los atacantes aumenta, y los errores que podrían haber sido descubiertos pasan desapercibidos para todos menos para los atacantes más sofisticados que mantienen estos errores en privado para poder persistir su acceso a puerta trasera, dejando a todos los usuarios del servicio comprometidos.
Q5. ¿Podrías compartir un ejemplo ( fuera de TM SGNL) donde un defecto del lado del vendedor socavó las garantías del cifrado de extremo a extremo?
El uso de Twilio por parte de Signal para la verificación por SMS resultó en que algunas cuentas de usuarios de Signal fueran comprometidas cuando Twilio fue hackeado. Dado que la verificación por SMS es una de las maneras en que los usuarios de Signal pueden recuperar sus cuentas, cuando Twilio fue hackeado, los atacantes pudieron engañar a los servidores de Signal para que pensaran que poseían el número de teléfono de un usuario de Signal y recuperar su cuenta, utilizando este acceso para enviar mensajes no autorizados desde las cuentas de esos usuarios de Signal.
Q6. ¿Por qué crees que la descentralización es la única forma de mitigar completamente el riesgo de un solo proveedor?
La descentralización es la única forma de mitigar completamente el riesgo de un solo proveedor porque elimina el punto único de fallo inherente a cualquier sistema centralizado. Cuando una sola entidad controla partes clave de la pila – desde las identidades de los usuarios hasta el enrutamiento y almacenamiento de mensajes – se convierten en un objetivo irresistible para los atacantes, y sus fallas de diseño o implementación pueden tener consecuencias catastróficas, como se ha visto con TM SGNL.
En una red descentralizada, no hay un servidor central que pueda ser vulnerado, ninguna empresa única que pueda ser presionada para insertar puertas traseras, y ninguna base de datos única que pueda ser objetivo de la recopilación de metadatos. Las identidades de los usuarios son a menudo claves criptográficas, no identificadores del mundo real vinculados a una autoridad central. Los mensajes son enrutados y almacenados en una red distribuida de nodos independientes, lo que significa que ningún nodo ve tanto las direcciones IP del remitente como del receptor, y ninguna entidad única puede recopilar un registro completo de las comunicaciones.
Esta distribución de poder y datos hace que el sistema sea inherentemente más resistente a ataques, censura y explotación de datos porque no hay un único punto de estrangulación que explotar. La seguridad no depende de la confiabilidad de una sola empresa, sino de la integridad colectiva y el diseño criptográfico robusto de la red distribuida.
Q7. Session utiliza una red de nodos de servicio. ¿Cómo garantiza esta arquitectura que ninguna parte pueda comprometer los datos del usuario?
A diferencia de las aplicaciones de mensajería tradicionales, Session no depende de un único servidor central que almacene todos los datos de los usuarios. En su lugar, los mensajes se envían a través de una red distribuida de miles de nodos de Session operados de manera independiente por la comunidad. Esto elimina el efecto "honeypot" de una base de datos centralizada única, lo que hace extremadamente difícil que cualquier entidad única pueda recopilar mensajes cifrados y metadatos de manera integral. Los nodos de Session almacenan temporalmente los mensajes para los destinatarios que están fuera de línea. Sin embargo, estos mensajes están cifrados de extremo a extremo, lo que significa que los nodos mismos no pueden leer el contenido. Además, los mensajes solo se almacenan por un tiempo limitado (Time-To-Live) y pueden ser eliminados una vez leídos, evitando la retención a largo plazo en la red de nodos.
Además, Session utiliza una técnica de enrutamiento en cebolla modificada, similar a Tor. Cuando envías un mensaje, se cifra en capas, y cada capa es retirada por nodos de Session sucesivos. Lo crucial es que ningún nodo individual conoce tanto la dirección IP del remitente como la del destinatario. Esto significa que incluso si un nodo fuera comprometido, no podría vincular un mensaje a su origen o destino.
Las cuentas de sesión se generan criptográficamente sin requerir información personal como números de teléfono o direcciones de correo electrónico. Esto significa que no hay una identidad del mundo real vinculada a tu ID de Cuenta de Sesión, lo que mejora aún más la privacidad y dificulta la compromisión de la identidad de un usuario a través de violaciones de datos externas.
Este enfoque multicapas, sin un punto central de control, almacenamiento temporal, cifrado de extremo a extremo y enrutamiento anonimizado, asegura que incluso si un pequeño número de Nodos de Sesión se viera comprometido, la integridad y privacidad general de la red permanecerían intactas.
Q8. Dada la implementación de TM SGNL en agencias federales, ¿ves a los gobiernos moviéndose hacia un mensajería realmente descentralizada? ¿Qué barreras existen para ese cambio?
Esa es una pregunta difícil. Las agencias gubernamentales generalmente requieren que se creen y almacenen registros de auditoría de manera que sean visibles para un auditor, esto crea una vulnerabilidad de seguridad inherente, el cifrado de extremo a extremo está diseñado para que solo los participantes de la conversación puedan ver el contenido de las comunicaciones. El requisito de auditoría introduce una puerta trasera intencionada en el cifrado de extremo a extremo, lo cual es difícil de implementar de manera segura.
Sin embargo, hay formas en que esto se puede gestionar mejor, por ejemplo, el registro de auditoría siempre debe almacenarse cifrado en reposo y debe haber protecciones robustas alrededor de los usuarios que pueden acceder a ese registro de auditoría. Los gobiernos deben utilizar herramientas de código abierto que pueden ser fácilmente auditadas y pensar con extrema cautela sobre cómo se almacenan los registros de auditoría y en qué servidores se almacenan.
Si la regulación se actualizara, podría ofrecer una forma de aprovechar mejor las soluciones descentralizadas en las comunicaciones gubernamentales.
Q9. ¿Cómo persuadirías a una organización consciente de la seguridad para que migre de un cliente propietario compatible con Signal a Session?
Creo que el hackeo de TM SGNL proporciona el incentivo más claro hasta ahora para que los usuarios se alejen de soluciones técnicas propietarias hacia herramientas de código abierto como Session, que ofrecen características de seguridad y privacidad mucho más avanzadas. Puede ser posible en el futuro que las organizaciones tomen herramientas de código abierto como Session y desarrollen sus propias herramientas de auditoría que se integren en estas herramientas. Sin embargo, tales soluciones de auditoría también deben ser de código abierto y auditables para asegurar que no veamos los mismos problemas que resurgieron con TM SGNL.
P10. Mirando hacia adelante, ¿qué características o mejoras importantes están en la hoja de ruta de Session para los próximos 12‒18 meses? En última instancia, ¿cuál es su visión a largo plazo para Session y para la mensajería segura y privada en general?
El enfoque actual de Session es alcanzar a más usuarios. Session ya tiene más de un millón de usuarios activos mensuales, pero queremos ver aún más usuarios eligiendo soluciones que incorporen una fuerte privacidad y seguridad en el núcleo del diseño de la aplicación. Los colaboradores de Session están trabajando actualmente en un conjunto premium de características para usuarios avanzados de Session que permiten un financiamiento sostenible para el ecosistema de Session. Esto incluye características como grupos más grandes, mayor personalización del perfil y tamaños de archivo aumentados, todas características que aumentan la utilidad de Session.
En términos más amplios, veo a Session como la única aplicación que ofrece tanto privacidad de contenido como de metadatos en una experiencia altamente consumible y fácil de usar, y creo que a medida que las violaciones de datos continúan afectando a los usuarios, Session seguirá creciendo en los próximos 12-18 meses.