Kompromi Intermediate CA: Ketika Trust Chain Patah

Ini pendapat yang kedengarannya terbalik: insiden otoritas sertifikat terburuk justru bukan yang diserang lalu dibobol. Insiden kompromi intermediate CA eMudhra yang baru-baru ini terjadi membuktikannya. Delapan kunci intermediate CA bisa direkonstruksi langsung dari sertifikatnya sendiri, tanpa ada intrusi, karena proses key generation ceremony milik CA itu sendiri menghasilkan private key yang sangat lemah, bahkan salah satunya secara harfiah adalah angka 4. Tidak ada yang mencuri kunci-kunci itu. Kunci-kunci itu sudah lahir dalam kondisi terkompromi. Ini mode kegagalan yang lebih menakutkan dibanding breach mana pun, karena Anda tidak bisa memperbaikinya dengan merotasi kredensial dan menambal celah. Kepercayaannya sendiri sudah cacat sejak hari pertama.

Jika Anda menjalankan apa pun yang melakukan koneksi TLS di luar browser, dan Anda pasti melakukannya, insiden ini layak mendapat perhatian Anda. Browser sudah terlindungi dalam hitungan hari. Sisa ekosistemnya, seperti panggilan curl di cron job Anda, layanan Python yang mem-pin certifi, dan binary Go dengan root store yang sudah tertanam, masih mengejar. Mari saya jelaskan apa yang sebenarnya terjadi, mengapa kompromi intermediate jauh lebih buruk dibanding kompromi leaf, dan apa yang ditunjukkan oleh remediasi yang tidak merata ini tentang kondisi revocation di internet modern.

Apa Sebenarnya yang Salah di eMudhra

Menurut penilaian awal dari pihak CA sendiri di tracker insiden Mozilla, ceritanya sangat membosankan. Sebuah script key generation ceremony, yaitu proses terkontrol dan diaudit yang dipakai CA untuk membuat kunci paling sensitifnya, dimodifikasi dengan deviasi yang disetujui untuk menguji prosedur key wrap/unwrap untuk ekspor. Sebuah bug di kode yang dimodifikasi itu menyebabkan satu set kunci ECC tambahan dibuat di HSM, dan kunci-kunci itu lemah. Bukan lemah dalam arti “entropi berkurang”. Lemah dalam arti bisa direkonstruksi dengan mudah hanya dari sertifikat publiknya.

Coba pikirkan artinya. Private key ECC seharusnya berupa angka acak 256-bit. Keamanan seluruh skema ini bertumpu pada discrete logarithm problem: dengan diberikan public key, mencari scalar private seharusnya tidak layak secara komputasi. Tetapi jika “angka acak” Anda hanya satu byte, public key hanyalah titik generator yang dikalikan dengan byte itu, dan siapa pun bisa melakukan brute-force ke 256 kemungkinan dalam hitungan mikrodetik di laptop. Salah satu dari delapan kunci dilaporkan berupa integer 4. Ini bukan kompromi dalam arti tradisional, melainkan sertifikat yang memang tidak pernah aman, diterbitkan di bawah root yang dipercaya Mozilla, Microsoft, Apple, dan Chrome.

Peneliti yang melaporkannya, yang diidentifikasi sebagai Wayne, membuktikan kepemilikan dengan menandatangani sebuah pesan menggunakan masing-masing dari delapan private key dan mengirimkan tanda tangannya ke root program. Siapa pun bisa memverifikasi bukti ini dengan beberapa perintah OpenSSL: ekstrak public key dari setiap sertifikat intermediate, lalu cek apakah tanda tangan pada pesan itu valid terhadapnya. Inilah yang elegan sekaligus mengerikan dari bukti kepemilikan kunci kriptografis. Tidak ada ambiguitas, tidak ada kabut PR “kami sangat serius soal keamanan”. Matematikanya benar atau tidak. Dan ternyata benar.

Mengapa Kompromi Intermediate CA Lebih Buruk daripada Leaf

Ketika private key sebuah leaf certificate bocor, misalnya key api.example.com Anda berakhir di repo GitHub publik, radius dampaknya hanya satu hostname, atau segelintir jika itu wildcard. Anda mencabut sertifikatnya, menerbitkan yang baru, lalu lanjut. Menjengkelkan, tapi bukan bencana eksistensial.

Kunci intermediate CA itu makhluk yang sama sekali berbeda. Web PKI bekerja sebagai rantai tanda tangan: root CA (disimpan offline, dijaga seperti material nuklir) menandatangani intermediate, dan intermediate menandatangani leaf certificate yang benar-benar disajikan server. Siapa pun yang memegang private key intermediate adalah CA tersebut, untuk semua keperluan kriptografis. Mereka bisa mencetak sertifikat valid untuk google.com, untuk bank Anda, untuk domain SSO internal Anda, dan setiap klien yang mempercayai rantai itu akan menerimanya tanpa keberatan. Tidak ada rate limit, tidak ada otoritas pusat untuk dihubungi, tidak ada cara untuk membedakan tanda tangan palsu-tapi-valid dari yang sah.

Insiden eMudhra mengalikan ini dengan delapan intermediate, sebagian di-cross-sign melalui root Sectigo, tersambung ke trust store yang dikirim di miliaran perangkat. Selama kurang lebih satu setengah tahun, dari saat sertifikat yang cacat itu dibuat sampai diumumkan, setiap klien yang mempercayai intermediate tersebut dan tidak menerapkan Certificate Transparency bisa diimpersonasi oleh siapa pun yang mau repot merekonstruksi kuncinya. Itulah jendela waktunya. Kita tidak tahu apakah ada yang mengeksploitasinya, dan kecuali ada tangkapan beruntung di CT log atau serangan yang teramati, kita mungkin tidak pernah tahu.

Inilah alasan root program memperlakukan insiden intermediate dengan tingkat keparahan yang tidak pernah didapat insiden leaf. Mendistrust sebuah intermediate berarti setiap sertifikat yang pernah diterbitkannya menjadi tidak valid, dan ribuan situs web rusak sekaligus. Kisah distrust Symantec, yang berlangsung selama bertahun-tahun, adalah contoh klasik betapa menyakitkannya remediasi penuh ketika operasi sebuah CA dinilai tidak layak dipercaya. Sistemnya berfungsi, tapi cara kerjanya seperti amputasi, bukan operasi bedah.

Certificate Transparency Ternyata Pahlawan Tak Sengaja

Bagian cerita ini yang layak mendapat perhatian lebih: Chrome, Safari, Firefox, dan Edge bisa dibilang sudah terlindungi sebelum ada yang tahu ada masalah. Bukan karena revocation, tapi karena Certificate Transparency.

Browser yang menerapkan CT mewajibkan setiap sertifikat yang dipercaya publik dan mereka terima tercatat di CT log publik yang bersifat append-only. Intermediate eMudhra yang terkompromi tidak punya entri CT log untuk periode yang bersangkutan, yang berarti setiap leaf certificate yang dicetak penyerang dengan kunci-kunci itu tetap akan ditolak oleh klien yang menerapkan CT, karena datang tanpa signed certificate timestamp yang valid. Penipuan itu harus dipublikasikan agar bisa dipercaya, dan mempublikasikannya berarti langsung ketahuan.

CT dirancang untuk mendeteksi penerbitan yang salah setelah kejadian, agar sertifikat nakal bisa dilacak. Dalam insiden ini, ia bekerja sebagai kontrol preventif: membuat kunci yang terkompromi hampir tidak berguna terhadap populasi browser, yang merupakan target bernilai tertinggi untuk intersepsi massal. Ini kabar baik yang benar-benar nyata untuk infrastruktur yang jarang dipikirkan kebanyakan engineer.

Tapi, dan di sinilah saya mengakui batas optimisme saya, penerapan CT pada dasarnya kemewahan khas browser. Mayoritas klien TLS di internet tidak memeriksa SCT. curl Anda tidak. Pemanggilan requests di Python Anda juga tidak. Fleet IoT yang melapor ke cloud vendor juga tidak. Untuk semua itu, satu-satunya perlindungan adalah data revocation yang sampai ke trust store tepat waktu, dan di situlah ceritanya menjadi suram.

Celah Revocation: Browser vs Semua yang Lain

Vendor browser menangani ini dengan baik, dan mereka pantas diapresiasi atas infrastruktur yang dibangun sejak satu dekade lalu. Mozilla sudah mengirimkan OneCRL, yaitu mekanisme push untuk mendistrust sertifikat intermediate dan root, selama lebih dari sepuluh tahun, dan mereka meremediasi insiden ini untuk pengguna Firefox dalam hitungan jam tanpa perlu update browser. CRLSet milik Chrome dan mekanisme setara dari Apple melakukan hal yang sama di platform mereka dalam beberapa hari. CA mencabut intermediate-nya. Dari sudut pandang pengguna browser, insiden ini selesai hampir sebelum sempat dimulai.

Sekarang lihat dunia non-browser. Daftar remediasinya terbaca seperti inventaris supply chain software: paket ca-certificates yang diperbarui untuk Ubuntu, Debian, Fedora, Alpine, Arch, Gentoo; rilis NSS baru; CA bundle curl yang baru; certifi untuk Python; rustls-webpki dan webpki-roots untuk Rust; point release Go; versi patch Electron di tiga jalur rilis; ca-bundle milik Composer; castore milik Elixir. Masing-masing adalah artefak terpisah, dengan ritme rilis terpisah, dikonsumsi oleh mekanisme update yang terpisah pula. Sebagian masih tertunda berhari-hari setelah pengumuman.

Lalu ada kategori yang membuat saya tidak bisa tidur: software yang membawa CA store sendiri di dalam binary-nya. Layanan Go yang di-build secara statis tahun lalu membawa root-nya di dalam artefak yang sudah dikompilasi. Satu-satunya perbaikan adalah build ulang dan deploy ulang, karena tidak ada paket sistem untuk di-patch. Kalikan itu dengan setiap image container di registry Anda yang punya layer /etc/ssl/certs bawaan, setiap aplikasi Electron di setiap desktop, setiap image firmware di setiap perangkat terhubung, dan Anda bisa melihat bentuk masalahnya. System trust store itu bagian yang mudah. Kami sudah pernah menulis tentang bagaimana perangkat embedded dan OT mengubah insiden keamanan menjadi saga bertahun-tahun; kompromi CA adalah jenis kejadian persis di mana perangkat-perangkat itu tidak pernah benar-benar diperbaiki.

Ekor Panjang Trust Store yang Tidak Dimiliki Siapa Pun

Ada kasus khusus dari insiden ini yang layak mendapat paragraf sendiri karena ilustratif sekali: macOS. Platform Apple memblokir intermediate yang terkompromi di level OS dengan cepat. Tapi /usr/bin/curl bawaan memverifikasi terhadap /etc/ssl/cert.pem, file yang tidak diperbarui, dan tidak memeriksa revocation. Jadi Anda bisa punya Mac yang sudah sepenuhnya di-patch di mana Safari menolak sertifikat palsu, sementara curl di mesin yang sama dengan senang hati menerimanya. Dua keputusan trust, satu mesin, jawaban yang berlawanan.

Fragmentasi inilah pelajaran sebenarnya. Kita sering membicarakan “Web PKI” seolah-olah itu satu sistem. Padahal itu puluhan sistem dengan properti yang sangat berbeda:

• Browser: revocation berbasis push (OneCRL, CRLSet), penerapan CT, auto-update. Remediasi diukur dalam hitungan jam sampai hari.
• Trust store OS: update lewat package manager (ca-certificates, ca_root_nss). Remediasi bergantung pada ritme rilis distro dan apakah mesin itu pernah di-patch.
• Ekosistem bahasa: certifi, webpki-roots, root Go yang tertanam, store Mozilla bawaan Node. Remediasi berarti membuat rilis dan menunggu bump dependensi di ribuan proyek.
• Artefak terkompilasi dan image: binary, container, firmware. Remediasi berarti build ulang dan deploy ulang, yang dalam praktiknya berarti ekor rentan yang terbentang bertahun-tahun.
• IoT dan embedded: sering kali tidak punya jalur update sama sekali. Praktisnya paparan permanen.

Browser sudah menghabiskan satu dekade untuk berinvestasi tepat pada skenario ini. Hampir tidak ada pihak lain yang melakukannya. Satu komentar dari pihak Mozilla menyatakannya dengan blak-blakan: di luar ekosistem browser, hampir tidak ada investasi pada revocation, dan bagi klien-klien itu, kelas insiden ini adalah masalah besar. Itu sesuai dengan semua yang saya lihat saat menjalankan infrastruktur. Jika Anda pernah berurusan dengan titik buta dalam cara event autentikasi cloud dicatat, Anda pasti mengenali polanya: jalur kritisnya terinstrumentasi dengan baik, dan ekor panjangnya adalah ruangan gelap.

Cara Mengecek Apakah Klien Anda Masih Rentan

Teori dulu, Anda sebaiknya benar-benar menguji estate Anda, dan hal bagusnya dari TLS adalah Anda bisa mengujinya secara empiris. Anggota komunitas sudah menyiapkan host yang menyajikan sertifikat yang ditandatangani oleh intermediate yang terkompromi. Jika klien Anda terhubung tanpa error sertifikat, berarti ia masih mempercayai mereka. Pola umum untuk menguji curl atau tool command-line apa pun kira-kira seperti ini:

# A certificate error here means you're protected.
# A successful response means this client still trusts a compromised intermediate.
curl -v https://dv-g3b-emudhra.we-have-a-problem.com/
# You can also test whether a client will accept a forged cert for an
# arbitrary hostname by pointing it at a test server:
curl -v https://example.org --connect-to example.org::2.29.126.86:

Jalankan ini dari setiap konteks yang penting: laptop developer Anda, CI runner, base image container, dan fleet server Anda. Jawabannya akan berbeda di antara mereka, dan perbedaan itulah intinya. Untuk inventaris cepat apa yang perlu di-upgrade:

• Layanan Go: build ulang dengan Go 1.27.3 atau 1.26.10 atau yang lebih baru, karena root-nya sudah terkompilasi di dalam.
• Python: certifi 2026.10.19 atau yang lebih baru (periksa juga versi pip dan uv, keduanya membawa bundle sendiri).
• Rust: rustls-webpki 0.103.16 dan webpki-roots / webpki-root-certs 1.0.10.
• Node.js dan Electron: rilis patch yang tertunda atau sudah tersedia per jalur rilis; periksa setiap artefak yang dikirim.
• System store: paket ca-certificates yang diperbarui sudah tersedia untuk Ubuntu, Debian, Fedora, Alpine, Arch, Gentoo; ca_root_nss FreeBSD masih tertunda saat tulisan ini dibuat.

Jika Anda tidak bisa menunggu paket, sebagian besar distro Linux memungkinkan Anda mendistrust root yang terdampak secara manual. Di Debian/Ubuntu caranya dengan menandai sertifikat dengan awalan ! di /etc/ca-certificates.conf lalu menjalankan update-ca-certificates; di keluarga Fedora/RHEL Anda mengekstrak root ke /etc/pki/ca-trust/source/blocklist/ lalu menjalankan update-ca-trust. NixOS punya opsi deklaratif yang rapi:

security.pki.caCertificateBlacklist = [
"Comodo AAA Services root"
"emSign ECC Root CA - G3"
];

Perhatikan apa yang sebenarnya Anda distrust lewat workaround ini: root tempat intermediate tersebut terhubung. Itulah kenyataan blunt-instrument dalam remediasi PKI. Sebagian besar tooling trust store tidak punya primitif “untrust intermediate ini saja”, jadi Anda memblokir root dan menerima dampak sampingan pada sertifikat lain yang tidak terkait. Ini pilihan yang tepat dalam keadaan darurat, tapi tetap saja sebuah pertukaran.

Di Mana Klaim Kontrarian Saya Runtuh

Saya membuka dengan argumen bahwa kegagalan generasi kunci yang disebabkan diri sendiri lebih buruk daripada breach. Izinkan saya jujur tentang di mana argumen itu patah. Breach tradisional, misalnya DigiNotar, setidaknya menyiratkan bahwa CA beroperasi dengan kompeten sampai penyerang mengakalinya, dan CA yang kompeten adalah hal yang dipertaruhkan seluruh sistem. Key ceremony yang menghasilkan private key “4” menyiratkan bahwa kontrol yang diaudit, prosedur HSM, dan daftar centang compliance semuanya gagal menangkap cacat fatal pada operasi paling sensitif yang dilakukan CA. Ini bukan masalah musuh, melainkan masalah jaminan, dan jaminan adalah produk utama yang dijual CA.

Di mana klaim itu benar-benar gagal: breach lebih sulit dihadapi dan bisa tak terlihat lebih lama. Penyerang yang mencuri kunci intermediate dengan hati-hati mungkin memakainya sesekali untuk intersepsi yang tertarget dan tidak pernah menyentuh klien yang menerapkan CT. Kunci lemah, sebaliknya, bisa ditemukan oleh siapa pun yang memindai sertifikat publik, dan itulah cara insiden ini muncul ke permukaan. Ada argumen bahwa bencana yang jelas lebih baik daripada yang halus dan tertarget. Saya tidak sepenuhnya setuju, tapi saya juga tidak bisa menepisnya. Kebenarannya, kedua mode kegagalan berakhir di tempat yang sama: sebuah intermediate yang harus di-distrust, dan ekor panjang klien yang tidak akan menerima pemberitahuan selama berbulan-bulan.

Apa yang Sebaiknya Anda Lakukan

Anda tidak bisa memperbaiki Web PKI. Yang bisa Anda lakukan adalah memperkecil paparan Anda terhadap kegagalan berikutnya:

• Uji, jangan berasumsi. Periksa klien Anda terhadap host yang menyajikan rantai yang terkompromi. Ini memakan waktu setengah hari dan kemungkinan akan mengejutkan Anda.
• Build ulang artefak terkompilasi. Binary Go dan image container membawa trust store mereka sendiri. “Kami sudah patch base image” tidak berarti apa-apa sampai Anda melakukan deploy ulang.
• Inventaris trust store Anda. Anda tidak bisa meremediasi apa yang belum Anda hitung. Hitung salinan certifi, bundle yang di-vendor, dan aplikasi Electron seolah-olah itu penting, karena memang penting.
• Utamakan system trust store jika memungkinkan. Setiap bundle yang di-vendor adalah patch yang akan Anda lupa kirim. Memusatkan pada store OS tidak menghilangkan masalah, tapi memberi Anda satu titik kendali.
• Pantau ekosistem CT dan revocation. Proyek yang bertujuan membawa revocation kelas browser ke klien non-browser memang ada dan layak didukung; insiden ini adalah argumen terbaik yang pernah mereka dapatkan untuk pendanaan.
• Perlakukan insiden CA sebagai insiden keamanan. Insiden ini seharusnya memanggil seseorang, memicu inventory, dan menghasilkan catatan tertulis, sama seperti kredensial yang bocor. Karena memang itulah wujudnya.

Ringkasan yang tidak nyaman: rem darurat Web PKI bekerja dengan sangat baik justru pada klien yang paling tidak membutuhkannya, karena CT sudah melindungi mereka. Klien yang membutuhkan rem itu, yaitu yang headless, embedded, di-vendor, dan terlupakan, sebagian besar tidak punya rem sama sekali. Kompromi intermediate CA berikutnya hanya soal kapan, bukan apakah. Satu-satunya variabel yang ada di bawah kendali Anda adalah apakah estate Anda sendiri menyadarinya.