Arquitectura y seguridad

1Componentes#

Extensión del navegador. 38 KB de JavaScript puro, sin minificar ni ofuscar: el código se puede leer entero. Dirige el enrutamiento mediante los mecanismos propios del navegador: PAC en Chrome, la Proxy API en Firefox. No requiere permisos de administrador, no instala controladores y no cambia ni las rutas del sistema ni el DNS.

Pasarela. Un binario de 8 MB en Go, sin dependencias ni archivos de configuración. Todos los ajustes y certificados los recibe del panel de control por un canal seguro y los aplica al vuelo. El estado lo guarda localmente para sobrevivir a reinicios y a caídas de conexión.

Panel de control (CP). La interfaz web y la API. Guarda la configuración, entrega los ajustes a pasarelas y extensiones y lleva la cuenta de dispositivos y límites.

2El camino de una petición#

Navegador ──TLS──► Pasarela ──TLS──► Servidor de destino
   │
   └── dominios no protegidos ──► directos a internet

1. Con el token, la extensión recibe la lista de dominios protegidos y las reglas de enrutamiento.
2. El navegador dirige las peticiones a esos dominios hacia la pasarela mediante CONNECT, y el resto directamente.
3. La pasarela comprueba la conexión, resuelve el nombre con su propio resolutor (teniendo en cuenta las sobrescrituras de IP y puerto fijadas por el administrador) y establece la conexión con el servidor de destino.
4. A partir de ahí, la pasarela solo mueve bytes entre sockets.

La consecuencia clave: la ruta se elige por dominio, no globalmente para el navegador. Por la pasarela pasa exactamente lo que enumera el token.

3Identificación de dispositivos#

Un token es una invitación, no un documento de identidad. La identidad en el sistema es el dispositivo.

Al instalarse, la extensión se registra y recibe un identificador de dispositivo (dev_id) y una clave secreta. Se guardan aparte de los tokens y no se reinician al borrar los datos del navegador, solo al desinstalar la extensión.

Cada petición a la API va acompañada de:

• el identificador del dispositivo
• una marca de tiempo
• una firma HMAC-SHA256

Esto produce tres efectos:

La API distingue a los usuarios de un mismo token. Un token entregado a tres auditores son tres dispositivos distintos, con estadística propia y revocación propia.

Probar tokens a ciegas resulta difícil. A la API no se puede acceder de forma anónima: hace falta un dev_id registrado con firma válida. Los intentos quedan atados a un dispositivo concreto y se cortan por él, no por una IP que se cambia fácilmente.

Las peticiones repetidas no cuelan. La marca de tiempo dentro de la firma protege frente a ataques de repetición.

4Qué protege a un token#

Cinco caracteres del alfabeto base58 (las mayúsculas cuentan) son un identificador de acceso, no la única barrera. Aun conociendo el token, un extraño no obtiene acceso, porque:

• a la API solo se puede acceder desde un dispositivo registrado y con firma válida;
• el número de activaciones es limitado: agotado el límite, no se conectan dispositivos nuevos;
• el token puede tener una ventana de activación fuera de la cual no funciona;
• el token puede estar protegido con contraseña: la configuración se descarga cifrada y no se descifra sin ella;
• cada dispositivo conectado es visible para el administrador y se revoca por separado.

Los tokens con contraseña empiezan por mayúscula: se ve en la grafía, así que la contraseña se espera desde el principio.

Políticas a nivel de dominio#

Los requisitos de seguridad se pueden fijar en el propio recurso en lugar de en cada token:

• Solo token protegido: cualquier token que incluya ese dominio tiene que llevar contraseña. El panel de control no dejará crearlo sin ella.
• Solo sesión privada: un token con ese dominio funciona obligatoriamente en el modo privado de la extensión: al cerrar el navegador, el token y la configuración se olvidan.

Es una protección frente al error humano: la marca se pone una vez en un recurso sensible y rige para todos los tokens futuros, sin importar quién los cree ni con cuánta prisa.

Las políticas se aplican fail-closed, pero sin romper el acceso que ya funciona: un dominio protegido no se puede añadir a un token sin protección, y si la política se activó después, el dominio queda desactivado en los tokens existentes y solo se puede activar tras cumplir el requisito. Cambiar las políticas de un dominio solo pueden hacerlo el propietario del espacio de trabajo y un administrador; un gestor no.

Aparte, un dominio se puede ocultar de la lista de la extensión: el acceso funciona, pero el recurso no aparece en la interfaz del usuario. Útil para dominios técnicos a los que el usuario nunca accede directamente.

5Invisibilidad de la pasarela#

La pasarela no responde a nadie salvo a los dispositivos registrados y no cuenta nada sobre sí misma.

Una dirección única por dispositivo. Cada dispositivo se conecta a la pasarela con un nombre de host propio. En el DNS público y en el certificado solo hay un comodín: los nombres concretos no se publican en ninguna parte. Esto importa por Certificate Transparency: certificados por dispositivo significarían una lista pública de todos los dispositivos, y el comodín descarta esa fuga.

Preautorización por SNI. La pasarela comprueba el nombre de host en el handshake TLS antes que nada. Si el nombre no se esperaba, la conexión se descarta: ni ServerHello, ni certificado, ni alerta TLS. El tipo de alerta es por sí mismo una huella, así que no se envía.

La misma reacción ante cualquier basura. Una petición HTTP normal y un TLS inválido reciben idéntico descarte de la conexión: por la respuesta no se puede saber qué protocolo espera el puerto.

Bloqueo por IP. El origen de un sondeo fallido acaba en la lista de bloqueo.

Lo que ve un escáner: el puerto acepta una conexión TCP. Nada más: ni banner, ni certificado, ni código de error.

6Cifrado del tráfico#

Sitios públicos: cifrado de extremo a extremo. La pasarela enruta por SNI y no termina TLS. La sesión va cifrada entre el navegador y su servidor; la pasarela ve el nombre del dominio y el volumen de bytes transferidos, pero no el contenido. Descifrar el tráfico no puede técnicamente: no tiene las claves.

Servicios internos por HTTP: terminación en su lado. Si el servicio funciona sin TLS (por ejemplo, Grafana en 127.0.0.1:3000), la pasarela se instala en la misma máquina o en la misma red y termina TLS localmente, accediendo al servicio por bucle local o por dirección privada. El tramo sin cifrar no sale de su máquina ni de su red.

En ambos casos, el tráfico en claro nunca circula por redes públicas.

7Sincronización de los ajustes#

Las pasarelas reciben sus ajustes del panel de control por una conexión permanente.

De forma incremental. Se transmiten solo los cambios, no la configuración completa de todos los usuarios. Eso mantiene la aplicación rápida sea cual sea el tamaño de la instalación.

Al vuelo. Los ajustes nuevos se aplican sin reinicio y sin cortar las conexiones en curso. Si a un usuario se le añade tráfico mientras descarga un archivo, la descarga no se interrumpe.

Conservando el estado. La pasarela guarda la configuración localmente y sigue funcionando cuando pierde contacto con el panel de control, incluido un reinicio del servidor.

8Revocación del acceso#

Revocar un dispositivo o cambiar los límites llega a las pasarelas en segundos y se aplica de inmediato: reiniciar el navegador no ayudará al usuario.

Una limitación importante. Si en el momento de la revocación la pasarela no es accesible para el panel de control, el cambio se aplicará al restablecerse la conexión. La autonomía de las pasarelas es lo que protege frente a caídas cuando hay problemas de nuestro lado, pero también significa que la ventana de propagación de una revocación equivale al tiempo que tarde en volver la conexión. En condiciones normales son segundos.

9Escenarios de fallo#

El panel de control no está disponible. Las pasarelas siguen funcionando con la última configuración conocida. No se pueden conectar dispositivos nuevos; el acceso existente se mantiene. Los cambios de ajustes se aplicarán al restablecerse.

Una pasarela no está disponible. Los sitios protegidos no se abren para quienes pasan por esa pasarela. El resto del tráfico del navegador no se ve afectado. Los dominios se pueden pasar a otra pasarela desde el panel de control.

Se ha desinstalado la extensión. El acceso cesa y en el sistema no queda nada. Volver a instalarla exigirá activar de nuevo un token.

Un usuario ha perdido su dispositivo. Revoque su dev_id: el acceso cesa y los demás usuarios del mismo token no se ven afectados.

10Qué vemos y qué no vemos#

Vemos:

• a qué dominios se han conectado los dispositivos y cuándo
• el volumen de tráfico transferido
• los identificadores de los dispositivos y la estadística de su actividad
• eventos de escaneo de las pasarelas (telemetría de protección)

No vemos:

• el contenido del tráfico hacia sitios públicos: va cifrado de extremo a extremo con TLS
• contraseñas, cookies, datos de formularios, contenido de las páginas
• el tráfico hacia dominios que no están en ningún token: no pasa en absoluto por nuestra infraestructura

Con una pasarela self-hosted no vemos: absolutamente nada del tráfico, no pasa por nuestra infraestructura de ninguna forma. En ese caso el panel de control intercambia con la pasarela únicamente configuración y estadísticas.

Limitaciones conocidas#

Una lista honesta, para no hacerle perder el tiempo comprobándolo:

• Solo HTTP/HTTPS en el navegador. SSH, bases de datos y acceso desde la CLI no se admiten. Un cliente para TCP-over-HTTPS está en los planes.
• La pasarela debe ser accesible desde fuera. Funcionar tras NAT sin reenvío de puertos no es posible.
• No se usa ECH. Los navegadores no aplican Encrypted Client Hello a las conexiones de proxy, así que un observador en el camino (un operador, un DPI corporativo) ve el nombre de host con el que el dispositivo se conecta a la pasarela. El nombre es seudónimo e inútil sin las claves del dispositivo.
• Un dominio, una ruta a la vez dentro de un navegador.