Insiden gangguan Tailscale.com pada 7 Maret 2024

 (tailscale.com)
2 poin oleh GN⁺ 2024-04-01 | 1 komentar | Bagikan ke WhatsApp
  • Pada 7 Maret 2024, tailscale.com sempat tidak tersedia selama sekitar 90 menit karena sertifikat TLS yang kedaluwarsa, tetapi dampaknya terutama terbatas pada situs dokumentasi dan pemasaran
  • Masalah ini muncul sekitar 90 hari setelah perombakan situs web dan migrasi ke hosting baru pada Desember 2023; konfigurasi proxy internal yang dibuat untuk menutupi lingkungan tanpa dukungan IPv6 menghambat pembaruan otomatis
  • Prober pemantau kedaluwarsa sertifikat hanya memeriksa rute IPv6, melewati proxy yang memiliki sertifikat valid terpisah, sehingga melewatkan tanda bahwa sertifikat tailscale.com dan www.tailscale.com yang sebenarnya hampir kedaluwarsa
  • Penggunaan Tailscale secara umum sebagian besar tidak terhenti, tetapi ada dampak pada dokumentasi, blog, install.sh, serta alur akses ke konsol admin bagi pengguna yang tidak mengetahui URL langsungnya
  • Tailscale memulihkan layanan dengan menghapus record AAAA tambahan dan memperbarui sertifikat secara manual; setelah sistem pembaruan manual jangka pendek dan pemeriksaan terpisah IPv4/IPv6, mereka menargetkan dukungan IPv6 yang lebih langsung

Mengapa kedaluwarsa sertifikat terlewat

  • Pada 7 Maret 2024, sertifikat TLS untuk tailscale.com dan www.tailscale.com kedaluwarsa, sehingga akses ke situs terhenti selama sekitar 90 menit
  • Pada Desember 2023, Tailscale melakukan perombakan besar situs web sekaligus pindah ke penyedia hosting baru
  • Karena penyedia hosting baru tidak mendukung IPv6 secara bawaan, Tailscale menjalankan proxy sendiri untuk menangani permintaan IPv6 dan menyiapkan record AAAA tambahan
  • Penyedia hosting menganggap konfigurasi ini sebagai “misconfiguration” dan mengirim peringatan, tetapi peringatan tersebut tidak secara jelas menyebutkan bahwa konfigurasi itu menghalangi penyelesaian pembaruan sertifikat otomatis
  • Prober untuk memantau kedaluwarsa sertifikat hanya memeriksa rute IPv6
    • Prober melewati proxy internal
    • Proxy memiliki sertifikat valid yang dikelola secara terpisah
    • Karena itu, kedaluwarsa sertifikat sebenarnya untuk tailscale.com dan www.tailscale.com tidak terdeteksi sebelumnya

Dampak yang terlihat oleh pengguna

  • Dampak terkonsentrasi pada materi dan alur instalasi yang bergantung pada situs web
    • Dokumentasi Tailscale, blog, dan materi referensi lain berbasis situs web tidak dapat diakses selama gangguan
    • Konsol admin dan halaman pengaturan itu sendiri tidak terdampak, tetapi pengguna yang tidak tahu cara langsung membuka https://login.tailscale.com/ bisa mengira halaman tersebut sedang offline
    • Skrip instalasi cepat tidak dapat digunakan, sehingga sebagian instalasi dan instalasi otomatis terganggu
  • Domain yang benar-benar menyediakan instalasi paket Tailscale tetap dapat diakses, dan penghentian resolusi melalui mekanisme go get milik Go dinilai minimal berkat caching
  • Berdasarkan desain Tailscale, sebagian besar pengguna pada sebagian besar kasus penggunaan tidak mengalami gangguan akibat insiden ini, dan berkat prinsip koneksi langsung, jaringan tidak terlalu bergantung pada ketersediaan langsung endpoint tertentu seperti tailscale.com

Pemulihan dan pencegahan agar tidak terulang

  • Setelah mengidentifikasi masalah, Tailscale untuk sementara menghapus record AAAA “tambahan” dan memperbarui sertifikat terkait secara manual
  • Langkah ini langsung menyelesaikan gangguan yang terlihat oleh pengguna, dan record segera dipulihkan agar situs dan layanan dapat disajikan melalui IPv6
  • Masalah pembaruan otomatis masih tersisa, sehingga untuk jangka pendek mereka berencana memperbarui sertifikat secara langsung dengan pengingat kalender ganda dan waktu pembaruan manual yang telah ditentukan
  • Infrastruktur prober akan diperbarui agar memeriksa endpoint IPv4 dan IPv6 secara terpisah
  • Dalam jangka panjang, targetnya adalah mendukung IPv6 secara lebih langsung di infrastruktur situs web sehingga tidak lagi memerlukan proxy internal

Bacaan terkait

1 komentar

 
GN⁺ 2024-04-01
Opini Hacker News

  • Sertifikat yang kedaluwarsa kini menurut saya adalah DNS baru penyebab insiden
    Meski begitu, saya masih kagum betapa bagusnya Tailscale dibuat. Saya lebih seperti pengguna ringan, tetapi saya mengakses dua tempat lewat Tailscale: beberapa server on-premises dan lingkungan produksi AWS
    Saya bisa bekerja dari mana saja. Akhir pekan lalu saya ingin men-deploy container ECS, tetapi Wi-Fi lokal terlalu lambat sehingga deployment terus timeout
    Jadi saya SSH ke mesin pengembangan on-premises, melakukan git pull kode terbaru, lalu men-deploy dari sana. Baik on-premises maupun AWS tetap aman tanpa port terbuka, dan dengan hanya menjalankan agen Tailscale di EC2 kecil di AWS, database Aurora produksi juga bisa diuji tanpa port terbuka
    Saat perlu memberi developer lain akses jaringan, Tailscale juga sangat mudah, begitu pula mencabut aksesnya. Deployment ini bisa saja ditangani dengan sesuatu seperti GitHub Actions untuk menghindari masalah internet yang buruk, tetapi saya ingin melakukannya manual, dan Tailscale memungkinkan itu

    • GitHub Actions tetap berguna saat deployment dengan Tailscale. Saat ini port SSH VM cloud dibuka di port non-standar agar worker GHA bisa masuk lewat SSH dan memulai deployment
      Ke depannya saya ingin memakai action ini supaya worker GHA mana pun bisa mengakses mesin deployment tanpa mengekspos port: https://github.com/tailscale/github-action
    • Pada koneksi yang tidak stabil saya memakai mosh dan GNU screen. Bahkan jika putus setiap 10 detik, keduanya bekerja dengan sangat baik

  • Sertifikat kedaluwarsa kembali menyebabkan insiden
    Sebagai bagian dari postmortem, saya menyarankan memisahkan skrip instalasi dari situs marketing atau menyediakan jalur alternatif lain. Dengan begitu aktivitas situs marketing tidak terkait dengan jalur kritis operasi pelanggan. Hal seperti ini umum terjadi, jadi lebih disayangkan karena mereka sebenarnya hampir mencapai pemisahan yang wajar
    Jika melacak uptime berbagai penyedia, bagian dari situs GitHub atau Zendesk ternyata lebih sering down daripada yang diperkirakan. Mereka masih termasuk contoh yang baik

    • Prioritas keamanan situs marketing sering kali lebih rendah daripada produk itu sendiri, sementara skrip instalasi biasanya harus dilindungi pada level yang mirip dengan produk
    • Saya penasaran apakah ada layanan yang memantau semua sertifikat dan tanggal kedaluwarsanya
      Cloudflare tampaknya cukup menangani bagian ini jika domain di-host di sana, tetapi syaratnya harus memakai Cloudflare

  • Ini sama seperti kesalahan yang pernah kami buat di perusahaan lama. Di beranda situs marketing www.foo.com, kami menaruh tautan ke halaman login web app app.foo.com
    Baru setelah insiden pertama situs marketing, kami sadar bahwa paket hosting 40 dolar per bulan itu bukan sekadar situs marketing, melainkan infrastruktur inti. Secara harfiah itu adalah hosting 40 dolar yang menanggung beban. Aplikasinya tidak down, tetapi pengguna mengira down
    Saya belajar bahwa pengguna hanya mengikuti jalur yang kita buat dan sering tidak tahu ada jalan lain; jika satu jalur itu dihilangkan, sebagian pengguna benar-benar tersesat

    • Jika mengetik tailscale di browser, hasil pertama adalah tailscale.com. Karena jarang memakai konsol admin Tailscale, saya tidak repot menghafal URL lain
      Dulu ketika mengetik cloudflare, browser otomatis melengkapi ke dash.cloudflare.com, tetapi setelah sekali saja mengunjungi situs cloudflare.com, itu menjadi hasil pertama, dan saya melakukan hal yang sama di Cloudflare

  • Tim ini benar-benar bagus, tetapi menurut saya harganya terlalu berlebihan. Kontrol akses yang layak seharga 18 dolar per bulan untuk VPN hampir mustahil dijual ke manajemen, dan tier rendah sulit dijual tanpa fitur itu

    • Saya benar-benar penasaran Tailscale dibandingkan dengan apa secara internal. Tailscale melakukan jauh lebih banyak daripada VPN sederhana
      Apa opsi yang lebih murah, dan apakah opsi-opsi itu juga menyediakan fitur SSH, autentikasi jaringan OAuth untuk layanan otomatisasi, konfigurasi load balancer node VPN di dalam cluster Kubernetes, serta otomatisasi permintaan sertifikat ACME melalui Let’s Encrypt?
      Bahkan jika hanya menyebut beberapa fitur yang saya pakai di tier gratis, banyak di antaranya bukan hal yang biasanya dianggap sebagai peran layanan VPN. Fiturnya juga terus bertambah, jadi menurut saya ini opsi yang cukup menarik dan kompetitif. Justru saya heran betapa banyak yang disediakan di tier murah, sehingga penilaian seperti ini membuat saya makin penasaran
    • Kalau begitu, pasang headscale dan host sendiri, maka bisa dipakai tanpa biaya
      Ada juga produk pesaing yang sebagian tumpang tindih dengan Tailscale, dan mungkin tidak sepenuhnya cocok dengan yang diinginkan
      Namun dalam beberapa menit, sebagian proyek jadi bekerja jauh lebih selaras daripada sebelumnya
      Dibandingkan fungsinya, ini salah satu alat yang sangat jarang terasa sederhana, dan tier gratisnya juga cukup longgar dengan 100 perangkat dan 3 pengguna
    • Ini sangat mudah diyakinkan. Kami keluar dari konfigurasi OpenVPN, dan berkat Tailscale, onboarding karyawan baru serta berbagai hal lain menjadi jauh lebih mudah dilakukan dengan cara yang benar. Ini makin penting karena perusahaan kami sepenuhnya remote
      Tentu, dalam peran saya, saya memang punya pengaruh yang cukup untuk meyakinkan manajemen soal topik seperti ini, tetapi harga bukan masalah
      Kami pelanggan yang puas sejak April tahun lalu dan semua orang memakai premium, yakni tier mahal. Kecepatan pengembangannya juga mengesankan. Beberapa fitur yang katanya bisa butuh bertahun-tahun sudah dirilis tahun lalu
      Cloudflare One juga bisa menjadi alternatif, tetapi kemungkinan akan lebih mahal
    • Saya tidak tahu manajemen macam apa yang tersandung di 18 dolar per bulan. Jika dilihat sebagai biaya per orang, itu hampir nol dibanding puluhan hal yang dibeli untuk karyawan
    • Itu adalah alasan utama yang mendorong kami ke Twingate. Setelah mencoba, saya sedikit lebih menyukai fungsi routing di Twingate. Bukan berarti saya membenci Tailscale; kami memakai keduanya sesuai kebutuhan

  • Saya penasaran penyedia situs webnya memakai apa. Hampir semua penyedia lain mendukung IPv6, jadi terdengar aneh bahwa mereka harus melakukan begitu banyak workaround karena IPv6

    • Dari hasil $ host www.tailscale.com, alamat IPv4 76.76.21.21 untuk www.tailscale.com adalah Vercel, sedangkan alamat IPv6-nya adalah Amazon
      IPv4 memakai sertifikat Let’s Encrypt, sedangkan IPv6 memakai sertifikat Amazon

  • Saya benar-benar iri karena CI/CD dan monitoring mereka begitu solid sampai bisa percaya diri melakukan rollout besar-besaran pada Desember. Budaya engineering-nya terlihat cukup kuat.
    Namun masih ada pertanyaan yang belum terjawab. Kalau konfigurasi IPv6 merusak pembaruan sertifikat otomatis untuk IPv4, saya penasaran kenapa ini tidak terjadi jauh lebih awal. Saya juga penasaran kenapa pemulihan insiden memakan waktu sampai 90 menit. Memang ini artikel blog dan bukan postmortem sungguhan, tetapi rasanya akan lebih baik kalau ada semacam timeline singkat.
    Saya juga penasaran kenapa mereka tidak pindah ke penyedia DNS yang mendukung IPv6 secara native. Saya juga bertanya-tanya apakah beban operasional untuk memisahkan domain khusus skrip atau paket memang sepadan. Selain pihak ketiga seperti repositori paket, saya penasaran apakah tempat lain juga melakukan hal seperti ini.

    • Sejauh yang saya pahami, mereka sepertinya mengubah ke konfigurasi saat ini 90 hari sebelum insiden. Sertifikat awal yang dipasang saat migrasi berlaku 90 hari, jadi insiden terjadi 90 hari setelah migrasi.
    • Mereka memakai Vercel, dan Vercel tidak mendukung IPv6.

  • Saya tidak mengerti kenapa proxy harus melakukan terminasi TLS. Kalau itu hanya TCP proxy, setidaknya monitoring tidak akan keliru mengira sertifikat belum mendekati kedaluwarsa.
    Selain itu, kalau validasi domain dilakukan dengan TLS-ALPN challenge, TCP proxy mungkin juga memungkinkan pembaruan otomatis.

    • TCP proxy akan membuang alamat IP pengguna kecuali memakai sesuatu seperti protokol PROXY. Untuk itu, server HTTPS tujuan juga harus mendukungnya, dan perlu ada cara untuk mencegah pengguna tak berwenang menyisipkan header PROXY mereka sendiri.
      Kalau IP pengguna sama sekali tidak diperlukan, ini bukan masalah, tetapi sering kali berguna untuk log dan deteksi penyalahgunaan.
      https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
    • Bukan alasan yang sangat besar, tetapi HTTP/3 tidak berjalan di atas TCP, dan mengoperasikan proxy UDP tampaknya tidak terlalu menyenangkan.
    • Tidak perlu melakukan terminasi TLS. Itu salah satu kesalahan kami, dan menjadi item pekerjaan yang akan diperbaiki.
      Saat pertama kali menemukan bahwa IPv6 rusak, kami buru-buru memasang proxy, dan orang-orang yang memasang proxy saat itu tidak tahu bagaimana ACME bekerja.
      Kami berencana mengubahnya menjadi TCP proxy saja.
    • Proxy yang tidak melakukan terminasi TLS cocok dijalankan di layanan seperti Hetzner. Jika CAA dikonfigurasi dengan benar, Anda hanya menyerahkan latensi dan ketersediaan kepada penyedia, dan juga bisa menghindari layanan yang kelewat mahal seperti CloudFront atau proxy berbasis EC2.
      Dari yang terlihat, Tailscale memakai NetActuate untuk pkgs.tailscale.com. Dengan NetActuate, sepertinya mereka bisa membantu menyediakan proxy non-terminating di beberapa lokasi dengan harga yang masuk akal. Tidak ada harga di situs webnya, tetapi tampaknya bukan perusahaan yang memasang margin 50 kali lipat untuk trafik keluar.
    • Mereka mungkin menaruh AWS CloudFront CDN di depan untuk IPv6. Kalau begitu, TLS akan diterminasi di CloudFront, dan setahu saya itu bukan opsi yang bisa dipilih.

  • Jika organisasi seperti Tailscale tergelincir sekali saja di area yang sedikit saja bersinggungan dengan keamanan, bagi orang yang sedikit paranoid seperti saya pun rasanya terlalu berisiko.
    Bagian ini perlu penjelasan yang lebih baik.

  • Karena pasti ada monitoring infrastruktur, cukup tambahkan 50 baris kode yang mengakses semua domain publik lewat IPv4 dan IPv6, lalu memberi peringatan jika sertifikat akan kedaluwarsa dalam 19 hari. Pembaruan otomatis dijalankan 20 hari sebelumnya, selesai.
    Setelah beberapa kali melewatkan pembaruan SSL pada masa awal perusahaan kecil, saya menulis kode ini beberapa tahun lalu, dan sejak itu tidak ada insiden terkait SSL.
    Tidak perlu undangan kalender; perbaikan yang diperlukan hanya ini. Bagian pentingnya adalah “kami akan memperbarui infrastruktur prover untuk memeriksa endpoint IPv4 dan IPv6 secara terpisah”.

  • Tertulis bahwa “konfigurasi itu dianggap sebagai miskonfigurasi oleh penyedia tersebut, sehingga sejak diterapkan mereka terus menerima peringatan.”
    Jadi mereka menerima peringatan terkait sertifikat selama 90 hari, lalu sertifikatnya gagal?

    • Sepertinya bukan menerima peringatan sertifikat selama 90 hari, melainkan lebih mirip menerima peringatan terkait DNS selama 90 hari. Tim Tailscale tampaknya belum tahu sebelum insiden bahwa Vercel menolak pembaruan sertifikat otomatis jika ada record DNS IPv6/AAAA.
      Saya tidak melihat peringatan aslinya, jadi tidak tahu apakah peringatan itu menjelaskan hal ini secara eksplisit.