Criptografia do arquivo de estado do Tailscale desativada por padrão

 (tailscale.com)
1 pontos por GN⁺ 2026-01-09 | 2 comentários | Compartilhar no WhatsApp
  • Na versão Tailscale v1.92.5, os recursos de criptografia do arquivo de estado (state file encryption) e chaves de autenticação por hardware dos clientes Linux e Windows foram desativados por padrão
  • Mesmo que o dispositivo TPM seja redefinido ou substituído, o cliente inicia normalmente, e falhas ao carregar chaves de autenticação por hardware não impedem a execução
  • Nas imagens de contêiner do Tailscale, as chaves de autenticação por hardware não são mais adicionadas aos Secrets de estado do Kubernetes, permitindo mover o contêiner para outro nó
  • O Tailscale Kubernetes Operator não usa mais o método de pedido ARI por padrão ao renovar certificados e não armazena chaves de autenticação por hardware em Secrets
  • Esta mudança simplifica a forma de configurar os recursos de segurança do Tailscale e aumenta a flexibilidade de implantação em diferentes ambientes

Atualização do Tailscale v1.92.5

  • Clientes Linux e Windows

    • Entre os recursos relacionados a Secure node state storage, a criptografia do arquivo de estado e as chaves de autenticação por hardware foram desativadas por padrão
    • Mesmo que o dispositivo TPM (Trusted Platform Module) seja redefinido ou substituído, a inicialização do cliente não é bloqueada

  • Imagem de contêiner do Tailscale

    • A nova versão está disponível no Docker Hub e no GitHub Packages
    • Como as chaves de autenticação por hardware não são adicionadas aos Secrets de estado do Kubernetes, é possível mover o contêiner do Tailscale para outro nó do Kubernetes

  • Tailscale Kubernetes Operator

    • A nova versão pode ser implantada conforme o guia de instalação
    • Ao renovar certificados, o método de pedido ARI não é usado por padrão, evitando falhas de renovação que podem ocorrer quando a chave da conta ACME é recriada
    • Como as chaves de autenticação por hardware não são adicionadas aos Secrets de estado do Kubernetes, é possível mover o Operator para outro nó

  • Tailscale tsrecorder

    • Nova versão disponível no Docker Hub
    • Esta versão inclui apenas atualizações de biblioteca, sem mudanças de funcionalidade

5 de janeiro de 2026 — API de Workload Identity Federation

23 de dezembro de 2025 — GitHub Action v4.1.1

  • O Tailscale GitHub Action foi corrigido para usar a arquitetura correta ao salvar e recuperar cache em GitHub Runners baseados em macOS

Leituras relacionadas

2 comentários

 
joyfui 2026-01-09

Ah, acho que vi há pouco tempo um post de alguém que distribuiu um utilitário relacionado a isso...
 
GN⁺ 2026-01-09
Comentários no Hacker News
  • Eu sou o engenheiro da Tailscale que implementou pela primeira vez o recurso de criptografia do estado do nó (@awly no GitHub). Desta vez, decidiram desativá-lo por padrão na versão 1.92.5
    Como foi especulado em outro comentário, esse recurso trazia uma carga de suporte grande demais. Originalmente, ele foi projetado para considerar qualquer reset ou troca de TPM como adulteração e fazer o cliente se recusar a executar. Mas, na prática, o TPM frequentemente se mostrava instável por motivos não maliciosos
    Alguns exemplos são a issue 17654, a issue 18288 e a issue 18302.
    O TPM é uma ferramenta excelente quando a organização consegue controlar bem os equipamentos, mas, para um serviço como o Tailscale, que precisa dar suporte a dispositivos em ambientes muito diversos, ele é complexo demais. Por isso, agora deixaram a ativação para usuários ou administradores mais sensíveis à segurança. Deveriam ter colocado mais desse contexto no changelog, e sinto muito por isso
    • Fiquei surpreso ao ler as issues vinculadas. Eu achava que problemas de TPM só apareceriam em hardware antigo ou em ambientes muito específicos, mas também ocorreram em Dell XPS e em várias VMs.
      Eu rodo a maior parte das minhas instâncias do Tailscale em VMs e contêineres, e, na prática, a criptografia com TPM só foi aplicada no meu PC principal, no iPhone e no host do meu servidor Linux. Em VMs ou contêineres não funcionou de jeito nenhum, e meu notebook provavelmente é antigo demais para ter suporte
    • Acho a política muito razoável. Obrigado pela explicação
    • Na issue 17654, um usuário disse que nem a configuração TS_ENCRYPT_STATE=false resolveu, mas que o problema desapareceu depois na versão 1.92.1.
      Em casos assim, fico curioso se isso realmente era um problema de criptografia de estado ou se havia outra causa
    • Eu também confiava no TPM, mas uma única atualização de BIOS zerou completamente o TPM. Depois disso, decidi não depender mais dele
    • Obrigado por explicar isso com tanta franqueza. Seria bom se o changelog trouxesse pelo menos um pouco desse contexto.
      Se a situação for complexa, eu também gostaria de ver um post curto de blog explicando separadamente
  • Esse recurso, para começo de conversa, não deveria ter sido ativado por padrão. O administrador deveria escolher explicitamente usar TPM
    Como o próprio changelog diz, se o TPM for resetado ou trocado, o cliente pode deixar de iniciar porque não consegue carregar a chave de autenticação do hardware.
    Em muitos ambientes de implantação esse recurso é realmente importante, mas, como o Tailscale roda em uma enorme variedade de sistemas operacionais e dispositivos, havia conflitos imprevisíveis demais
    • Toda vez que tento usar TPM para criptografia, no fim preciso de uma senha de recuperação ou uma chave de backup. Mas isso acaba anulando o propósito do próprio TPM.
      Um errinho pequeno já pode fazer a chave do usuário desaparecer para sempre, então, na prática, acho difícil de usar
    • O Windows não usa TPM por padrão? Se for assim, milhões de usuários do Windows deveriam ter enfrentado problemas.
      Por isso, isso me parece um pouco reação exagerada. É uma pena desligar o recurso inteiro por causa de alguns casos excepcionais de TPM.
      Eu gostaria que houvesse um meio-termo (por exemplo, ativação opcional)
    • Se o TPM for resetado ou substituído, bloquear o acesso não seria justamente o comportamento correto do ponto de vista de defesa contra ataques físicos?
  • Neste PR há uma explicação do motivo da desativação.
    Diz que a variação na qualidade dos TPMs era grande demais, o que causava vários problemas
  • Pelo changelog, parece que foi por causa dos problemas gerados pela ativação padrão (não tenho informação interna).
    Mas fico curioso se, quando esse problema for resolvido, existe plano de voltar a ativar isso por padrão.
    Eu confio na equipe do Tailscale, mas, num momento como o atual, em que as preocupações com vigilância estão crescendo, queria ouvir uma razão clara de que essa mudança não foi motivada por exigência de governo
    • Acho que a causa do problema não é o Tailscale, e sim a instabilidade do próprio hardware TPM.
      Por isso, acho que esse recurso faz sentido apenas como uso opcional em ambientes controlados
  • Eu não sabia por que o Tailscale continuava travando numa máquina NixOS com hardware antigo, e essa mudança finalmente me fez entender a causa. Era por causa da criptografia com TPM
  • Meu palpite é que desativaram isso porque havia suporte demais para atender
  • No último mês, o Tailscale ficou quebrado o tempo todo para mim, e o patch lançado hoje resolveu o problema.
    A causa foi uma atualização de BIOS, depois da qual o Tailscale ficava preso em “Starting” sem mostrar erro nenhum
  • Eu inicializo um Linux instalado em USB alternadamente em desktop e notebook, e um dia o Tailscale simplesmente parou de funcionar.
    Eu achava que meu caso era algo muito específico, mas agora descobri que a criptografia baseada em TPM também falha por outros motivos
  • No Linux, parece que basta adicionar FLAGS="--encrypt-state" em /etc/default/tailscaled.
    O log mostra a mensagem "migrated ... to TPM-sealed format", então aparentemente está funcionando bem
  • Por esse motivo, no mercado de massa não dá para colocar por padrão um recurso que quebra nem que seja em 1% dos casos.
    No fim, é preciso se alinhar ao menor denominador comum, e não tem jeito: estabilidade vem antes de segurança perfeita.
    Se eu operasse o Tailscale, talvez dissesse “quem teve o TPM quebrado que resolva por conta própria; nós vamos manter a segurança por padrão”.
    Mas entendo que o Avery tenha seus motivos para tomar essa decisão