Familias de relays declaradas: por qué la construcción de rutas de Tor evita los circuitos de un mismo operador
Durante la mayor parte de su historia, operar más de un relay de Tor conllevaba una pequeña tarea administrativa: una línea MyFamily en cada torrc, con las huellas de todos los demás relays bajo el mismo operador. Ese mecanismo ya ha abandonado la red, y los operadores con varios relays declaran ahora sus familias mediante un sucesor basado en claves. La razón de ser de la opción no ha cambiado, y conviene recordarla a quien añada hoy un segundo relay.
Para qué sirve una declaración de familia
Una familia de relays es un conjunto de relays bajo un mismo control administrativo: una persona, una organización o un host con varias instancias de tor. La declaración existe para la construcción de rutas. Los clientes de Tor procuran no colocar dos miembros de la misma familia en un mismo circuito, porque un circuito cuya entrada y salida responden a la misma parte es justo el escenario de un ataque de correlación extremo a extremo: la entrada ve al cliente, la salida ve al destino, y un solo operador con ambas vistas puede unirlas.Cuando dos relays declaran que pertenecen a la misma 'familia', los clientes de Tor no los usarán en el mismo circuito.La documentación comunitaria describe la opción sucesora de la misma manera: FamilyID, dice el texto, simplemente indica a los clientes de Tor qué relays controla una única entidad, operador u organización, para que los relays de un mismo operador no se usen en varias posiciones de un circuito. Sin esa señal, la selección de rutas trata a los relays emparentados como desconocidos.
Cuando los operadores olvidan declarar
El diseño antiguo dependía por completo de que los operadores llevaran el registro en cada relay y lo mantuvieran al día. Un grupo que comparte operador pero no declara nada es invisible para la selección de rutas: la red cuenta sus relays como participantes independientes. Eso distorsiona las estadísticas de diversidad con que se describe la red, y reduce la protección que los clientes realmente obtienen, porque la regla del cliente se detiene justo en el límite de lo declarado. El proyecto OrNetStats, del investigador de relays veterano nusenu, lleva años rastreando el tema. Agrega los relays en familias efectivas - relays con una configuración de MyFamily mutua - y entre sus preguntas de fondo figuran qué grupos de relays tienen posibles malas configuraciones de MyFamily y cuáles plantean un riesgo de correlación extremo a extremo para los usuarios de Tor. Su informe dedicado solo enumera operadores cuando la combinación es realista: probabilidad de guard y de exit sobre cero, sin familia bien configurada y relays repartidos en más de un bloque de red /16; en otras palabras, grupos que podrían de verdad ocupar ambos extremos de un circuito. Cuando la familia se configura bien, señala el informe, los relays desaparecen de la página en uno o dos días. La información de contacto forma parte de la misma historia. ContactInfo es una cadena sin autenticación, y OrNetStats señala que ello ha permitido suplantar a otros operadores de relays, algo que, según el proyecto, ya se ha explotado en la práctica. Por eso muestra, cuando existen, identificadores de operador autenticados (AROI), que ligan los datos de contacto a un control de DNS o de servidor web que el operador debe poseer de verdad.De MyFamily a Happy Families
El mecanismo antiguo, además, escalaba mal. Cada relay tenía que listar a todos los demás miembros, y cada cambio obligaba a actualizar la configuración de todos. La propuesta 321, escrita por Nick Mathewson en mayo de 2020, cifró el coste: según su medición de febrero de 2025, las declaraciones de familia superaban el 55 por ciento del contenido de los microdescriptores, y añadir o quitar un servidor exigía cambiar el torrc de todos los demás. Una convocatoria de comentarios de noviembre de 2021 sobre una forma más fácil de declarar familias recibió respuestas de operadores, incluido nusenu, y el diseño resultante conserva la propiedad de seguridad cambiando la mecánica: el operador genera una vez una clave de firma familiar, la entrega a cada relay de la familia y define la opción FamilyId. La pertenencia se prueba con certificados en los descriptores, y las autoridades de directorio publican líneas family-ids compactas en lugar de listas de huellas cuadráticas. La guía comunitaria llama Happy Families a este diseño; está implementado en la serie Tor 0.4.9 y en Arti 1.4.1. La transición se cerró en 2026. La serie 0.4.8 - la última que exigía MyFamily junto al nuevo mecanismo - llegó al fin de su vida útil el 1 de junio, y el 1 de septiembre quedó fijado como la fecha a partir de la cual los clientes 0.4.8 y anteriores dejarían de mantenerse funcionando en la red, con las antiguas líneas de familia obsoletas para ahorrar ancho de banda de directorio. El portal comunitario afirma hoy sin rodeos que MyFamily se ha eliminado y dirige a los operadores con varios relays a FamilyID y una ContactInfo válida. Las herramientas también han seguido: el rol ansible-relayor retiró el soporte de MyFamily en su versión de junio de 2026, al notar que todas las versiones de tor soportadas hablan el nuevo diseño.Guía práctica para operadores con varios relays
- Ejecutar una versión de tor soportada en cada relay; la red ya no transporta las antiguas líneas de familia.
- Generar una clave de familia con tor --keygen-family, copiar el archivo de clave al KeyDir de cada relay, añadir una línea FamilyId al torrc y recargar.
- Rotar las claves por fases: desplegar la nueva FamilyId junto a la antigua, esperar unos días a que se propague y retirar la línea vieja.
- Definir una ContactInfo funcional - siempre exigida a operadores con varios relays - y valorar publicar un AROI para que la identidad del operador no pueda suplantarse.
- Comprobar cómo ve la red: las páginas de familias de OrNetStats y su informe de correlación extremo a extremo muestran si los relays están agrupados correctamente.