El cifrado del archivo de estado de Tailscale está desactivado en la configuración predeterminada

 (tailscale.com)
1 puntos por GN⁺ 2026-01-09 | 2 comentarios | Compartir por WhatsApp
  • En la versión Tailscale v1.92.5, las funciones de cifrado del archivo de estado (state file encryption) y claves de atestación de hardware de los clientes de Linux y Windows quedan desactivadas de forma predeterminada
  • Incluso si un dispositivo TPM se restablece o se reemplaza, el cliente inicia normalmente y una falla al cargar la clave de atestación de hardware no impide la ejecución
  • En la imagen de contenedor de Tailscale, las claves de atestación de hardware ya no se agregan a los Secrets de estado de Kubernetes, por lo que el contenedor puede moverse a otros nodos
  • El Tailscale Kubernetes Operator ya no usa de forma predeterminada el método de pedidos ARI durante la renovación de certificados, y no guarda claves de atestación de hardware en Secrets
  • Este cambio es una actualización que simplifica la forma en que Tailscale configura sus funciones de seguridad y mejora la flexibilidad de despliegue en distintos entornos

Actualización de Tailscale v1.92.5

  • Clientes de Linux y Windows

    • Dentro de las funciones relacionadas con Secure node state storage, el cifrado del archivo de estado y las claves de atestación de hardware quedan desactivados de forma predeterminada
    • Aunque el dispositivo TPM (Trusted Platform Module) se restablezca o se reemplace, el inicio del cliente no se bloquea

  • Imagen de contenedor de Tailscale

    • La nueva versión está disponible en Docker Hub y GitHub Packages
    • Como las claves de atestación de hardware no se agregan a los Secrets de estado de Kubernetes, el contenedor de Tailscale puede moverse a otro nodo de Kubernetes

  • Tailscale Kubernetes Operator

    • La nueva versión puede desplegarse siguiendo la guía de instalación
    • Durante la renovación de certificados, ya no usa de forma predeterminada el método de pedidos ARI, lo que evita fallas de renovación que podrían ocurrir cuando se vuelve a generar la clave de cuenta de ACME
    • Como las claves de atestación de hardware no se agregan a los Secrets de estado de Kubernetes, el Operator puede moverse a otro nodo

  • Tailscale tsrecorder

    • La nueva versión está disponible en Docker Hub
    • Esta versión solo incluye actualizaciones de bibliotecas, sin cambios funcionales

5 de enero de 2026 — API de Workload Identity Federation

23 de diciembre de 2025 — GitHub Action v4.1.1

  • Se corrigió Tailscale GitHub Action para que use la arquitectura correcta al guardar y recuperar caché en GitHub Runner basado en macOS

Lecturas relacionadas

2 comentarios

 
joyfui 2026-01-09

Eh, creo que hace poco vi una publicación de alguien que había compartido una utilidad relacionada con esto...
 
GN⁺ 2026-01-09
Comentarios en Hacker News
  • Soy el ingeniero que implementó por primera vez la función de node state encryption en Tailscale (@awly en Github). Esta vez se decidió desactivarla por defecto en la versión 1.92.5
    Como especularon en otros comentarios, esta función tenía una carga de soporte demasiado alta. Originalmente estaba diseñada para considerar cualquier reinicio o reemplazo del TPM como manipulación y hacer que el cliente se negara a ejecutarse. Pero en la práctica, muchas veces el TPM era inestable por razones no maliciosas
    Como ejemplos, están issue 17654, issue 18288 y issue 18302.
    El TPM es una gran herramienta cuando una organización puede controlar bien sus equipos, pero para un servicio como Tailscale, que debe soportar dispositivos en entornos muy diversos, es demasiado complejo. Por eso ahora se dejó para que los usuarios o administradores sensibles a la seguridad lo activen manualmente. Debimos haber incluido más de este contexto en el changelog, y por esa parte lo siento
    • Me sorprendió leer los issues enlazados. Pensaba que los problemas de TPM solo aparecerían en hardware viejo o entornos especiales, pero también ocurrieron en Dell XPS y en varias VM.
      Yo ejecuto la mayoría de mis instancias de Tailscale en VM y contenedores, y en realidad el cifrado con TPM solo se aplicó en mi PC principal, mi iPhone y el host de mi servidor Linux. En VM o contenedores no funcionó en absoluto, y mi laptop probablemente era demasiado vieja como para soportarlo
    • Me parece una política muy razonable. Gracias por explicarlo
    • En issue 17654, un usuario dijo que tampoco se resolvió con la configuración “TS_ENCRYPT_STATE=false”, pero que en la versión posterior 1.92.1 el problema desapareció.
      En casos así, me pregunto si realmente era un problema de state encryption, o si había otra causa; me gustaría saber si puedes explicarlo un poco más
    • Yo también confiaba en el TPM, pero con una sola actualización de BIOS el TPM quedó completamente reiniciado. Desde entonces decidí no depender más del TPM
    • Gracias por explicarlo con tanta honestidad. Estaría bien que el changelog incluyera хотя sea un poco de este contexto.
      Si la situación es compleja, también sería bienvenido un post corto en el blog para resumirlo por separado
  • Esta función nunca debió estar activada por defecto. El administrador debería elegir explícitamente usar TPM
    Como también dice el changelog, si el TPM se reiniciaba o reemplazaba, el cliente no podía cargar la clave de autenticación de hardware y dejaba de iniciar.
    En muchos entornos de despliegue esta función es necesaria, pero como Tailscale corre en una variedad enorme de OS y dispositivos, hubo demasiados conflictos impredecibles
    • Cada vez que intento usar TPM para cifrado, al final termino necesitando una contraseña de recuperación o clave de respaldo. Pero eso vuelve inútil el propósito mismo del TPM.
      Siento que en la práctica es difícil de usar, porque un solo error pequeño puede hacer que la clave del usuario desaparezca por completo
    • ¿Windows no usa TPM por defecto? Si es así, millones de usuarios de Windows deberían haber tenido problemas.
      Por eso esto me parece una reacción un poco exagerada. Es una lástima que hayan desactivado toda la función por algunos casos excepcionales de TPM.
      Me habría gustado una etapa intermedia, por ejemplo activación opcional
    • Si el TPM se reinicia o reemplaza, bloquearlo no sería más bien el comportamiento correcto desde el punto de vista de defensa contra ataques físicos?
  • En este PR se explica por qué se desactivó.
    Dice que la variación en la calidad del TPM era demasiado grande y causaba varios problemas
  • Viendo el changelog, parece que fue por los problemas causados al estar activado por defecto (no tengo información interna).
    Aun así, me pregunto si planean volver a activarlo por defecto cuando este problema se resuelva.
    Confío en el equipo de Tailscale, pero en una época como esta, con la preocupación por la vigilancia creciendo, me gustaría escuchar una razón clara de que este cambio no se debe a una exigencia del gobierno
    • Creo que la causa del problema no es Tailscale sino la inestabilidad del propio hardware TPM.
      Por eso pienso que esta función solo debería usarse de forma opcional en entornos controlados
  • Tenía una máquina NixOS con hardware viejo en la que Tailscale seguía crasheando y no entendía por qué; gracias a este cambio ahora sé la causa. Era por el cifrado TPM
  • Supongo que lo desactivaron porque probablemente había demasiadas solicitudes de soporte
  • Durante el último mes Tailscale siguió fallando, pero el parche publicado hoy resolvió el problema.
    La causa fue una actualización de BIOS, y después de eso Tailscale se quedaba atascado en estado “Starting” sin mostrar ningún error
  • Yo arranco un Linux instalado en USB alternando entre desktop y laptop, y un día Tailscale dejó de funcionar de repente.
    Pensé que mi caso era algo raro, pero ahora veo que el cifrado basado en TPM también falla por otras razones
  • En Linux, al parecer basta con agregar FLAGS="--encrypt-state" a /etc/default/tailscaled.
    En los logs aparece el mensaje "migrated ... to TPM-sealed format", así que parece estar funcionando bien
  • Por razones como esta, en el mercado masivo no se puede poner por defecto una función que falle aunque sea en 1% de los casos.
    Al final hay que ajustarse al mínimo común denominador, y no queda otra que priorizar la estabilidad sobre la seguridad perfecta.
    Si yo operara Tailscale, quizá habría dicho: “quien tenga el TPM roto que lo arregle por su cuenta; nosotros mantendremos la seguridad por defecto”.
    Pero entiendo que Avery tiene sus razones para tomar esta decisión