Saltar al contenido
Life Security

Buscar en el sitio

Encuentra páginas y secciones.

Tipos de redes de comunicación

Última actualización:

Cada aplicación de mensajería mueve tus palabras a través de una determinada disposición de computadoras. Quién administra esas computadoras y cómo se conectan determina quién puede ver que le enviaste un mensaje a alguien, cuándo y con qué frecuencia, incluso cuando el mensaje en sí esté cifrado. Esto es el diseño de la red y resulta tan importante como el cifrado de la propia aplicación.

Existen cuatro diseños comunes: centralizados, federados, de igual a igual (P2P) y redes de retransmisión (relays) construidas para evitar el uso de cuentas de usuario. Cada uno deposita la confianza en una parte diferente y falla de una manera distinta. Después de leer esto, sabrás qué expone cada diseño, por qué “descentralizado” no significa “privado” y cómo elegir uno para la amenaza a la que realmente te enfrentas.

No recomendamos aplicaciones específicas aquí. Las que nombramos son ejemplos tomados de su propia documentación para mostrar cómo funciona un diseño. No cubrimos cómo opera el cifrado de extremo a extremo en sí ni cómo comparar mensajerías función por función.

Qué es una red de comunicación, en términos sencillos

Imagina que Amira quiere enviarle un mensaje a Daniel. El teléfono de ella tiene que encontrar el teléfono de él y entregarle el mensaje. Incluso en un chat sencillo, tres preguntas se responden en algún lugar: ¿dónde está Daniel en este momento?, ¿cómo le llega el mensaje si está desconectado? y ¿quién llega a saber que esa conversación ocurrió?

El análisis del IETF sobre la centralización, RFC 9518, señala que el punto de encuentro (rendezvous) entre dos partes a menudo requiere a un tercero, que es una de las razones por las que los puntos centrales aparecen en primer lugar. Los cuatro diseños a continuación responden a esas preguntas de forma diferente.

Los cuatro diseños

Centralizado

Una sola organización administra los servidores, el software y las reglas. Signal es el ejemplo habitual. Su fundador explicó esta elección en 2016: argumentó que los protocolos federados son difíciles de cambiar, que ya no creía que se pudiera construir una mensajería federada competitiva y que proteger los metadatos requeriría nuevos protocolos “que solo serían posibles en entornos centralizados con mayor control”. Añadió que la infraestructura de código abierto permite a los usuarios ejecutar su propia alternativa si el proveedor realiza cambios inadecuados (Signal, 2016). Esa es una postura dentro de un debate real, proveniente de quien tomó la decisión.

La ventaja es que el operador puede corregir problemas rápidamente y mantener la coherencia del diseño. La desventaja es que una sola organización (y cualquiera que pueda obligarla legalmente) ve el tráfico. Lo que conserva el operador depende de lo que recopile. En una respuesta de 2021 a una orden de registro en EE. UU., Signal declaró que solo podía proporcionar la hora en que se creó cada cuenta y la fecha en que se conectó por última vez (Signal, 2021). Su función de “remitente oculto” (sealed sender) oculta la identidad del remitente ante el servicio, pero la publicación señala que el servicio aún necesita saber quién es el destinatario, y que los tiempos de conexión y las direcciones IP siguen siendo áreas de trabajo continuo (Signal, 2018). Signal todavía solicita un número de teléfono para registrarse. Los nombres de usuario son opcionales y permiten que otras personas te contacten sin conocer tu número (Soporte de Signal).

Federado

Muchos servidores independientes, administrados por personas distintas, se comunican entre sí bajo un estándar compartido. Tú eliges un servidor para alojar tu cuenta y este intercambia mensajes con los demás. El correo electrónico es el ejemplo más antiguo: SMTP permite que un servidor acepte un mensaje y luego actúe como cliente frente al siguiente servidor en la ruta (RFC 5321, 2008). Matrix funciona de forma similar para el chat. La cuenta de cada usuario reside en un servidor hogareño (homeserver), y una sala se replica en cada servidor que tenga miembros en ella (Matrix). ActivityPub, un estándar del W3C desde enero de 2018, hace lo propio para las redes sociales, con servidores publicando actividades en las bandejas de entrada de los demás (W3C).

La ventaja es la libertad de elección: puedes elegir o administrar tu propio servidor, y ninguna empresa es dueña de la red. La desventaja es que el operador de tu servidor ve la actividad de tu cuenta, al igual que los operadores de los servidores que usan tus contactos. Matrix lo expone abiertamente: señala que actualmente expone los metadatos de quién habla en qué salas a los administradores de los servidores involucrados (Matrix, 2025). La especificación de ActivityPub, por su parte, señala que no se acordó ningún mecanismo de autenticación durante la estandarización, y no encontramos nada en ella sobre cifrar mensajes directos.

El correo electrónico muestra un segundo límite. El estándar para proteger la conexión de tu aplicación de correo a su servidor, RFC 8314, señala que no aborda cómo los servidores retransmiten el correo entre sí. Y un borrador del IETF indica que el cifrado PGP/MIME por sí solo no protege los encabezados de los mensajes (Borrador del IETF, 2019, caducado y nunca adoptado).

Igual a igual (Peer-to-peer / P2P)

No hay ningún servidor en medio. Los dispositivos intercambian mensajes directamente entre sí. El sitio del proyecto Briar lo describe así: no depende de un servidor central, los mensajes se sincronizan directamente entre los dispositivos de los usuarios y las listas de contactos se cifran y almacenan en cada dispositivo. Cuando hay conexión a internet, se sincroniza a través de Tor, lo que el proyecto afirma que impide a los observadores ver qué usuarios se comunican. Cuando no hay internet, los datos pueden moverse por Bluetooth, Wi-Fi o tarjetas de memoria. Para las personas que no están en línea al mismo tiempo, un Buzón de Briar (Briar Mailbox) independiente puede retransmitir los mensajes (Briar).

La ventaja es la resiliencia y la resistencia a la censura: no hay un servidor central que se pueda derribar u obligar legalmente. Las desventajas son prácticas. Sin un servidor que guarde los mensajes, la entrega depende de que los dispositivos estén localizables, y el diseño se apoya en herramientas adicionales como Tor y un buzón para ocultar quién habla con quién. El propio modelo de amenazas de Briar también asume que un usuario que no puede mantener su dispositivo seguro está controlado por el atacante.

Redes de retransmisión sin cuentas de usuario

Un diseño más reciente evita por completo los identificadores de usuario. SimpleX se describe a sí mismo de esta manera: los usuarios no tienen números de teléfono, nombres de usuario ni claves públicas asignadas. Los mensajes se mueven a través de servidores de retransmisión (relays) utilizando direcciones de cola de un solo sentido, una dirección independiente para cada contacto, y los servidores guardan los mensajes solo de forma temporal. El proyecto afirma que los servidores no pueden determinar fácilmente quién habla con quién, aunque se reconocen los ataques de correlación de tráfico (SimpleX). Sus comparaciones con otros diseños proceden del propio proyecto y no las hemos verificado de forma independiente. Además, no pueden contactarte sin que compartas un enlace de invitación o una dirección temporal.

Tor es un tipo de red relacionado pero diferente. Encamina el tráfico a través de varios repetidores para que ningún repetidor individual sepa a la vez quién eres y a dónde vas. Nuestra descripción general de Tor lo explica.

Qué muestra cada diseño a quién

Diseño Quién transporta los mensajes Quién puede averiguar quién habla con quién Principal debilidad
Centralizado Un solo operador El operador, más cualquiera que pueda obligarlo legalmente o vulnerarlo Un solo punto de control y de fallo
Federado Muchos servidores independientes Cada servidor involucrado, para sus propios usuarios y salas Tu privacidad depende de servidores que tú no eliges
Igual a igual (P2P) Los propios dispositivos de los usuarios Los observadores de las conexiones, a menos que Tor o algo similar los oculte La entrega y la protección de metadatos requieren piezas adicionales
Retransmisión (relay), sin cuentas Servidores de retransmisión No es fácil de determinar para un relay, según el proyecto, pero los ataques de correlación son posibles Más reciente y documentado principalmente por su propio proyecto

Lo que el diseño no puede hacer

  • No puede hacer seguro un dispositivo final comprometido. Si alguien tiene acceso a tu teléfono o al de tu contacto, ningún diseño de red resulta de ayuda.
  • No puede eliminar la necesidad de confiar en alguien. El RFC 9518 recomienda que los estándares permitan a los usuarios cambiar de proveedor y limiten el poder que posee cualquier parte individual, no que pretendan eliminar la necesidad de confianza.
  • No puede evitar que se unan personas a las que no invitaste. Las redes federadas abiertas tienen que lidiar con el spam, que Matrix cita como un modo de fallo conocido.
  • No puede garantizar que lo “descentralizado” se convierta en algo descentralizado en la práctica. El RFC 9518 señala que la tecnología descentralizada por sí sola no garantiza resultados descentralizados, porque los efectos de red, los costos y las barreras de cambio aún pueden concentrar a los usuarios en unos pocos servidores grandes.

Mitos comunes

“Descentralizado significa privado.” Significa que el control está repartido. Cada operador en una red federada puede ver los metadatos de sus propios usuarios, tal como Matrix afirma sobre sí misma.

“Centralizado significa inseguro.” Un operador central es un punto único de confianza, no una garantía de debilidad. Lo que importa es qué recopila y qué se le puede obligar a entregar. La respuesta publicada por Signal a la orden de registro muestra un conjunto de datos almacenados extremadamente reducido.

“El cifrado de extremo a extremo oculta con quién hablo.” Protege el contenido. La entrega sigue necesitando una dirección, y la propia publicación de Signal indica que el servicio debe conocer al destinatario.

Qué hacer

Estos pasos están ordenados según cuánto ayudan con el menor esfuerzo:

  1. Decide primero de quién te estás ocultando. Un desconocido curioso, un operador de red, una empresa o un gobierno requieren diseños diferentes. Comienza con el modelado de amenazas.
  2. Elige en función de lo que el operador pueda ver, no por la palabra “descentralizado”. Pregunta qué detalles de la cuenta y metadatos conserva el operador, y qué muestran sus respuestas publicadas a las solicitudes legales.
  3. Si usas un servicio federado, elige el servidor a propósito. El operador de tu servidor ve tu actividad. Lee quién lo administra y dónde. Administrar el tuyo propio traslada la confianza a ti mismo y añade trabajo de mantenimiento.
  4. Usa una opción sin número de teléfono si tu número es la parte sensible. Los nombres de usuario de Signal y los diseños sin cuenta como SimpleX abordan esto de diferentes maneras, con distintas ventajas e inconvenientes.
  5. Planifica para el día en que tu red habitual sea bloqueada. Herramientas P2P como Briar y herramientas con capacidad de puentes (bridges) como Tor existen para esto, pero instálalas y pruébalas antes de necesitarlas.
  6. Usa la red que realmente vayan a utilizar tus contactos. Una herramienta privada en la que nadie responde no protege a nadie. El costo de cambiar de plataforma forma parte del panorama de la seguridad.

Fuentes

Páginas relacionadas

Preguntas frecuentes