Tailscale の状態ファイル暗号化、デフォルト設定で無効化

 (tailscale.com)
1 ポイント 投稿者 GN⁺ 2026-01-09 | 2件のコメント | WhatsAppで共有
  • Tailscale v1.92.5 で、Linux および Windows クライアントの 状態ファイル暗号化（state file encryption） と ハードウェア認証キー 機能がデフォルトで無効化
  • TPM デバイスがリセットまたは交換された場合でも、クライアントは正常に起動し、ハードウェア認証キーの読み込み失敗が実行を妨げない
  • Tailscale コンテナイメージ では、ハードウェア認証キーが Kubernetes の状態 Secrets に追加されなくなり、コンテナを別ノードへ移動可能
  • Tailscale Kubernetes Operator は、証明書更新時に ARI 注文方式をデフォルトで使用せず、ハードウェア認証キーを Secrets に保存しない
  • 今回の変更は、Tailscale のセキュリティ機能の構成方法を簡素化し、さまざまな環境でのデプロイ柔軟性を高める更新

Tailscale v1.92.5 アップデート

  • Linux および Windows クライアント

    • Secure node state storage 関連機能のうち、状態ファイル暗号化 と ハードウェア認証キー がデフォルトで無効化
    • TPM（Trusted Platform Module）デバイスがリセットまたは交換されても、クライアント起動はブロックされない

  • Tailscale コンテナイメージ

    • 新バージョンを Docker Hub および GitHub Packages で提供
    • ハードウェア認証キーが Kubernetes の状態 Secrets に追加されないため、Tailscale コンテナを別の Kubernetes ノードへ移動できる

  • Tailscale Kubernetes Operator

    • 新バージョンは インストールガイド に従ってデプロイ可能
    • 証明書更新時に ARI 注文方式 をデフォルトで使用しないため、ACME アカウントキー再生成時に発生しうる更新失敗を防止
    • ハードウェア認証キーが Kubernetes の状態 Secrets に追加されないため、Operator を別ノードへ移動可能

  • Tailscale tsrecorder

    • Docker Hub で新バージョンを提供
    • 今回のリリースは ライブラリアップデートのみを含み、機能変更はない

2026年1月5日 — Workload Identity Federation API

2025年12月23日 — GitHub Action v4.1.1

  • Tailscale GitHub Action が、macOS ベースの GitHub Runner でキャッシュの保存・取得時に正しいアーキテクチャを使用するよう修正

関連記事

2件のコメント

 
joyfui 2026-01-09

あっ、少し前にこれ関連でユーティリティを配布してくださった方の投稿を見た気がするんですが……
 
GN⁺ 2026-01-09
Hacker Newsのコメント
  • 私はTailscaleで node state encryption 機能を最初に実装したエンジニアです（GitHubでは @awly）。今回、1.92.5 バージョンで既定値をオフにすることを決めました。
    他のコメントで推測されていたとおり、この機能は サポート負担が大きすぎました。もともとはTPMがリセットまたは交換された場合、必ず改ざんと見なしてクライアントが実行を拒否するよう設計していました。しかし実際には、悪意のない理由でTPMが不安定になるケースが多くありました。
    例として issue 17654、issue 18288、issue 18302 などがあります。
    TPMは、組織が機器を適切に管理できる場合には優れたツールですが、Tailscaleのように 多様な環境の機器 をサポートしなければならないサービスには複雑すぎます。そこで今は、セキュリティに敏感なユーザーや管理者が自分で有効化する形にしています。changelogにこうした文脈をもっと書くべきでしたが、その点は申し訳なく思っています。
    • リンクされたissueを読んで驚きました。TPMの問題は古い機器や特殊な環境だけで起きるものかと思っていましたが、Dell XPSや複数のVMでも発生していました。
      私はTailscaleインスタンスの大半を VMとコンテナ で動かしていますが、実際にTPM暗号化が適用されていたのは、メインPC、iPhone、そしてLinuxサーバーのホストだけでした。VMやコンテナではまったく動作せず、ノートPCは古すぎて未対応だったようです。
    • とても合理的な方針だと思います。説明してくれてありがとうございます。
    • issue 17654 では、あるユーザーが TS_ENCRYPT_STATE=false 設定でも解決しなかったと言っていましたが、その後の 1.92.1 では問題がなくなったとのことです。
      このケースは実際にstate encryptionの問題だったのか、それとも別の原因だったのか、もう少し説明してもらえないでしょうか。
    • 私もTPMを信頼していましたが、BIOSアップデート 一発でTPMが完全に初期化されてしまいました。それ以来、TPMには依存しないことにしています。
    • ここまで率直に説明してくれてありがとうございます。changelogにこうした背景が少しでも入るとよいと思います。
      事情が複雑なら、短い ブログ記事 として別にまとめてくれるのも歓迎です。
  • この機能はそもそも デフォルトで有効化されるべきではありませんでした。管理者がTPMを使うと明示的に選ぶべきです。
    changelogにもあるように、TPMがリセットまたは交換されるとハードウェア認証キーを読み込めず、クライアントが起動しない問題がありました。
    多くのデプロイ環境ではこの機能が必要ですが、Tailscaleは非常に多様なOSと機器で動くため、予測不能な衝突 が多すぎました。
    • TPMを暗号化用途で使おうとするたび、結局は 復旧用パスワードやバックアップキー が必要になります。ですが、それではTPMを使う目的自体が薄れてしまいます。
      ちょっとしたミス一つでユーザーのキーが完全に失われる可能性があり、実運用では難しいと感じます。
    • WindowsはデフォルトでTPMを使っているのでは？ もしそうなら、何百万人ものWindowsユーザーが問題に直面していたはずです。
      なので、これは少し 過剰な対応 に見えます。一部のTPMの例外ケースのために機能全体をオフにしたのは残念です。
      中間的な段階（例: 任意の有効化）があってもよかった気がします。
    • TPMがリセットまたは交換されたときにブロックするのは、むしろ 物理攻撃への防御 という観点では正しい動作なのでは、という疑問があります。
  • このPR に無効化の理由が説明されています。
    TPM品質の ばらつきが大きすぎて、さまざまな問題を引き起こしたそうです。
  • changelogを見る限り、デフォルト有効化による問題が原因のようです（内部事情は知りません）。
    ただ、この問題が解決したら再びデフォルト有効化する計画があるのか気になります。
    私はTailscaleチームを信頼していますが、監視への懸念 が高まっている今のような時期には、この変更が政府の要請によるものではないと分かる明確な説明を聞きたいです。
    • 問題の原因はTailscaleではなく、TPMハードウェア自体の不安定さ にあると思います。
      だからこの機能は、制御された環境でのみ選択的に使うのが適切だと考えます。
  • 古いハードウェアのNixOSマシンでTailscaleがずっと クラッシュ していて理由が分からなかったのですが、今回の変更で原因が分かりました。TPM暗号化が原因でした。
  • おそらく サポート依頼が多すぎたため 無効化したのだろうと推測します。
  • この1か月、Tailscaleがずっと壊れたままでしたが、今日のパッチでその問題が解決しました。
    原因は BIOSアップデート で、その後Tailscaleは何のエラーも表示せず Starting 状態で止まっていました。
  • 私は USBにインストールしたLinux をデスクトップとノートPCで交互に起動していますが、ある日突然Tailscaleが動かなくなりました。
    自分だけの特殊なケースだと思っていましたが、TPMベースの暗号化が他の理由でも失敗することを知りました。
  • Linuxでは /etc/default/tailscaled に FLAGS="--encrypt-state" を追加すればよいようです。
    ログに "migrated ... to TPM-sealed format" というメッセージが出ているので、うまく動いているようです。
  • こういう理由があるので、大衆向け市場では 1%でも壊れる機能 をデフォルトにすることはできません。
    結局は最小公倍数ではなく最小公約数に合わせるしかなく、完全なセキュリティより 安定性優先 にならざるを得ません。
    もし私がTailscaleを運営していたら、「TPMが壊れた人は自分で直してほしい、こちらはデフォルトでセキュリティを維持する」と言っていたかもしれません。
    それでも、Averyがこの判断をした理由は理解できます。