1 poin oleh GN⁺ 2026-01-09 | 2 komentar | Bagikan ke WhatsApp
  • Pada Tailscale v1.92.5, fitur enkripsi file status (state file encryption) dan kunci autentikasi perangkat keras pada klien Linux dan Windows dinonaktifkan secara default
  • Klien tetap dapat berjalan normal meskipun perangkat TPM di-reset atau diganti, dan kegagalan memuat kunci autentikasi perangkat keras tidak lagi menghalangi proses startup
  • Pada image container Tailscale, kunci autentikasi perangkat keras tidak lagi ditambahkan ke Secrets status Kubernetes, sehingga container bisa dipindahkan ke node lain
  • Tailscale Kubernetes Operator tidak lagi menggunakan metode pemesanan ARI secara default saat pembaruan sertifikat, dan tidak menyimpan kunci autentikasi perangkat keras di Secrets
  • Perubahan ini merupakan pembaruan yang menyederhanakan cara konfigurasi fitur keamanan Tailscale dan meningkatkan fleksibilitas deployment di berbagai lingkungan

Pembaruan Tailscale v1.92.5

  • Klien Linux dan Windows

    • Dari fitur terkait Secure node state storage, enkripsi file status dan kunci autentikasi perangkat keras kini dinonaktifkan secara default
    • Startup klien tidak lagi terblokir meskipun perangkat TPM (Trusted Platform Module) di-reset atau diganti
  • Image container Tailscale

    • Versi baru tersedia di Docker Hub dan GitHub Packages
    • Karena kunci autentikasi perangkat keras tidak ditambahkan ke Secrets status Kubernetes, container Tailscale dapat dipindahkan ke node Kubernetes lain
  • Tailscale Kubernetes Operator

    • Versi baru dapat di-deploy mengikuti panduan instalasi
    • Saat pembaruan sertifikat, metode pemesanan ARI tidak digunakan secara default, sehingga mencegah kegagalan pembaruan yang dapat terjadi saat kunci akun ACME dibuat ulang
    • Karena kunci autentikasi perangkat keras tidak ditambahkan ke Secrets status Kubernetes, Operator dapat dipindahkan ke node lain
  • Tailscale tsrecorder

    • Versi baru tersedia di Docker Hub
    • Rilis ini hanya mencakup pembaruan library, tanpa perubahan fitur

5 Januari 2026 — Workload Identity Federation API

23 Desember 2025 — GitHub Action v4.1.1

  • Tailscale GitHub Action diperbaiki agar menggunakan arsitektur yang benar saat menyimpan dan mengambil cache pada GitHub Runner berbasis macOS

2 komentar

 
joyfui 2026-01-09

Eh, rasanya belum lama ini saya melihat tulisan dari seseorang yang membagikan utilitas terkait ini...

 
GN⁺ 2026-01-09
Komentar Hacker News
  • Saya adalah engineer di Tailscale yang pertama kali mengimplementasikan fitur node state encryption (@awly di Github). Kali ini diputuskan untuk mematikan default-nya pada versi 1.92.5
    Seperti dugaan di komentar lain, fitur ini menimbulkan beban dukungan yang terlalu besar. Awalnya, fitur ini dirancang agar jika TPM di-reset atau diganti, itu selalu dianggap sebagai tampering dan klien menolak berjalan. Namun dalam praktiknya, TPM sering tidak stabil karena alasan yang tidak jahat
    Contohnya ada issue 17654, issue 18288, issue 18302.
    TPM adalah alat yang hebat ketika organisasi bisa mengendalikan perangkat dengan baik, tetapi untuk layanan seperti Tailscale yang harus mendukung perangkat dari beragam lingkungan, ini terlalu kompleks. Jadi untuk sekarang, fitur ini dibiarkan agar diaktifkan sendiri oleh pengguna atau admin yang sensitif terhadap keamanan. Seharusnya konteks seperti ini dimasukkan lebih banyak ke changelog, dan saya minta maaf soal itu
    • Saya terkejut setelah membaca issue yang ditautkan. Saya kira masalah TPM hanya akan muncul pada perangkat lama atau lingkungan khusus, tetapi ternyata juga terjadi pada Dell XPS dan berbagai VM.
      Saya menjalankan sebagian besar instance Tailscale saya di VM dan container, dan yang benar-benar mendapat enkripsi TPM hanya PC utama saya, iPhone, dan host dari server Linux saya. Di VM atau container sama sekali tidak berfungsi, dan laptop saya tampaknya terlalu tua untuk mendukungnya
    • Menurut saya kebijakannya sangat masuk akal. Terima kasih sudah menjelaskannya
    • Di issue 17654, ada pengguna yang mengatakan bahwa masalahnya tidak terselesaikan bahkan dengan pengaturan TS_ENCRYPT_STATE=false, tetapi pada versi 1.92.1 masalah itu hilang.
      Untuk kasus seperti ini, saya penasaran apakah itu benar-benar masalah state encryption, atau ada penyebab lain, dan apakah Anda bisa menjelaskannya lebih lanjut
    • Saya juga pernah mempercayai TPM, tetapi satu kali update BIOS membuat TPM terinisialisasi ulang sepenuhnya. Sejak itu saya memutuskan untuk tidak lagi bergantung pada TPM
    • Terima kasih sudah menjelaskannya dengan jujur. Akan bagus kalau changelog memuat sedikit latar belakang seperti ini.
      Jika situasinya rumit, saya juga akan menyambut baik posting blog singkat yang merangkumnya secara terpisah
  • Fitur ini sejak awal seharusnya tidak diaktifkan secara default. Admin seharusnya memilih secara eksplisit jika ingin memakai TPM
    Seperti yang tertulis di changelog, jika TPM di-reset atau diganti, ada masalah di mana klien tidak bisa mulai karena gagal memuat hardware auth key.
    Di banyak lingkungan deployment fitur ini memang sangat dibutuhkan, tetapi karena Tailscale berjalan di begitu banyak OS dan perangkat, ada terlalu banyak benturan yang tak terduga
    • Setiap kali mencoba memakai TPM untuk enkripsi, pada akhirnya selalu butuh kata sandi pemulihan atau backup key. Namun itu justru membuat tujuan TPM sendiri jadi tidak berarti.
      Hanya karena satu kesalahan kecil, kunci pengguna bisa hilang sepenuhnya, jadi dalam praktiknya terasa sulit dipakai
    • Bukankah Windows secara default memakai TPM? Kalau begitu, seharusnya jutaan pengguna Windows mengalami masalah.
      Jadi ini terlihat agak seperti reaksi berlebihan. Sangat disayangkan seluruh fitur dimatikan hanya karena beberapa kasus pengecualian TPM.
      Rasanya akan lebih baik jika ada tahap tengah (misalnya: aktivasi opsional)
    • Kalau TPM di-reset atau diganti lalu diblokir, bukankah itu justru perilaku yang benar dari sisi pertahanan terhadap serangan fisik?
  • Alasan penonaktifannya dijelaskan di PR ini.
    Disebutkan bahwa variasi kualitas TPM terlalu besar dan menimbulkan berbagai masalah
  • Jika melihat changelog, tampaknya ini akibat masalah dari aktivasi default (saya tidak punya info internal).
    Namun saya penasaran apakah setelah masalah ini terselesaikan, ada rencana untuk mengaktifkannya secara default lagi.
    Saya percaya pada tim Tailscale, tetapi di masa seperti sekarang ketika kekhawatiran soal pengawasan meningkat, saya ingin mendengar alasan yang jelas bahwa perubahan ini bukan karena permintaan pemerintah
    • Saya melihat penyebab masalahnya bukan pada Tailscale, melainkan pada ketidakstabilan hardware TPM itu sendiri.
      Jadi menurut saya benar jika fitur ini dipakai secara opsional hanya di lingkungan yang terkontrol
  • Di mesin NixOS dengan hardware lama, Tailscale terus crash dan saya tidak tahu alasannya, tetapi berkat perubahan ini saya jadi tahu penyebabnya. Ternyata karena enkripsi TPM
  • Saya menduga fitur ini dinonaktifkan karena terlalu banyak permintaan dukungan
  • Selama sebulan terakhir Tailscale saya terus rusak, dan patch yang keluar hari ini menyelesaikan masalah itu.
    Penyebabnya adalah update BIOS, dan setelah itu Tailscale hanya berhenti di status “Starting” tanpa menampilkan error apa pun
  • Saya memakai Linux yang diinstal di USB dan bergantian boot di desktop dan laptop, lalu suatu hari Tailscale tiba-tiba berhenti berfungsi.
    Saya kira hanya kasus saya yang aneh, tetapi sekarang saya jadi tahu bahwa enkripsi berbasis TPM juga bisa gagal karena alasan lain
  • Di Linux sepertinya cukup menambahkan FLAGS="--encrypt-state" ke /etc/default/tailscaled.
    Di log muncul pesan "migrated ... to TPM-sealed format", jadi tampaknya berfungsi dengan baik
  • Inilah alasan mengapa untuk pasar massal, fitur yang rusak bahkan 1% saja tidak bisa dijadikan default.
    Pada akhirnya harus disesuaikan dengan common denominator terendah, dan mau tak mau stabilitas lebih diprioritaskan daripada keamanan sempurna.
    Jika saya yang mengelola Tailscale, mungkin saya akan berkata, “kalau TPM Anda rusak, perbaiki sendiri; kami akan tetap menjaga keamanan sebagai default.”
    Tapi saya paham bahwa Avery punya alasan untuk mengambil keputusan ini