eMudhra mundur dari TLS, server Anda masih percaya CA-nya

Yang jadi berita adalah mundurnya, bukan perbaikannya

Pada 22 Oktober, eMudhra mengumumkan bahwa dewan direksinya memutuskan untuk "voluntarily withdraw from the global SSL/TLS certificate business", alias mundur secara sukarela dari bisnis sertifikat SSL/TLS global. Menurut perusahaan, bisnis itu hanya "about 1% of the global revenue". eMudhra juga menyatakan CA yang terdampak sudah dicabut "within 14 hours of discovery", dan layanan pencabutan serta status sertifikat akan tetap berjalan "until every issued certificate has expired or been replaced". Root G1 RSA miliknya tetap aktif selama masa transisi, pelanggan terdampak mendapat sertifikat pengganti gratis dari mitra, dan produk DSC, eSign, PKI enterprise, serta identitasnya berjalan seperti biasa.

Penutupan yang rapi, setidaknya di atas kertas. Tetapi tidak ada yang berubah di mesin yang Anda kelola. Sertifikat intermediate yang bobol itu masih ada di setiap trust store yang belum diperbarui, dan sekarang sudah ada tool siap pakai yang memanfaatkan celah persis itu. Kalau anggapan Anda selama ini "browser sudah membereskannya", tulisan ini untuk Anda.

Delapan kunci, delapan bit

Detailnya nyaris menggelikan. Tulisan Scott Helme mendaftar delapan intermediate yang terdampak: enam CA penerbit TLS untuk DV, OV, dan EV pada generasi G3B dan G3C, ditambah dua CA code-signing. Semuanya dibuat pada April 2025, dan semuanya di-cross-sign oleh root "AAA Certificate Services" milik Sectigo pada Mei 2025.

Kunci-kunci itu bertipe P-384, yang seharusnya berarti skalar privat sekitar 384 bit. Nyatanya, kunci privatnya adalah 156, 230, 115, 56, 155, 4, 66, dan 237. Semuanya di bawah 256, jadi masing-masing muat dalam satu byte. Siapa pun yang memegang sertifikat publiknya bisa memulihkan kunci privatnya dalam waktu kurang dari satu detik, cukup dengan mencoba semua kemungkinan satu per satu.

Penjelasan eMudhra, seperti dilaporkan TNW, adalah bahwa key generation ceremony pada 30 April 2025 menyertakan langkah wrap/unwrap yang menghasilkan set kunci lemah kedua, dan kunci lemah itulah yang akhirnya masuk ke root store. Perusahaan menyatakan tidak ada sertifikat yang diterbitkan dari CA yang terdampak.

Poin terakhir itu tidak semenenangkan kedengarannya. Yang penting bukan apa yang diterbitkan eMudhra, melainkan apa yang sekarang bisa diterbitkan orang lain. Jawabannya: sertifikat untuk hostname apa pun, ditandatangani oleh CA yang mungkin masih dipercaya software Anda.

Firefox beres dalam tiga jam, CI runner Anda belum

Mozilla bergerak cepat. Menurut blog keamanannya, laporan masuk pada Sabtu, 17 Oktober, pukul 20.06 UTC, dan blokir OneCRL untuk konfigurasi Firefox standar sudah terpasang pukul 22.59 UTC. Setelah itu Mozilla merilis Firefox 158.0.1, ESR 115.43.1, ESR 153.5.1, dan NSS 3.131.1, yang menghapus root penanda tangan intermediate tersebut. Mozilla mencatat bahwa perubahan di NSS juga melindungi aplikasi lain yang memakai trust store Mozilla atau turunannya.

Kecepatan itu justru menutupi masalah sebenarnya. Browser punya jalur push untuk pencabutan sertifikat, sedangkan kebanyakan klien TLS lain tidak punya apa-apa. Helme menyatakannya dengan lugas: dalam konfigurasi bawaan, curl, Python, Node, Go, Java, dan git "trust a CA bundle on disk, they don't check revocation by default, and they don't check CT". Mereka memercayai bundle CA di disk, tidak memeriksa pencabutan, dan tidak memeriksa Certificate Transparency. Perangkat dengan firmware yang tidak lagi diperbarui akan memercayai sertifikat ini sampai kedaluwarsa, yaitu Juli 2039.

Jadi paparannya ada di semua yang bukan browser: klien API di layanan Anda, pengirim webhook, installer paket di build agent, skrip yang memanggil requests atau fetch, binary Go yang dikompilasi berbulan-bulan lalu, dan image kontainer yang dibangun dari base layer yang tidak pernah disegarkan sejak musim semi.

Eksploitasinya pun tidak lagi butuh keahlian. mitmproxy sudah me-merge opsi --emudhra (PR #8500) dengan teks bantuan "Sign certificates with a compromised eMudhra intermediate CA key." Klien mana pun yang masih memercayai root eMudhra akan menerima sertifikat buatan mitmproxy tanpa perlu ada yang memasang CA milik mitmproxy. Siapa pun yang berada di jalur jaringan, misalnya Wi-Fi yang tidak bisa dipercaya, router yang sudah disusupi, atau jaringan CI bersama, bisa membaca dan mengubah lalu lintas TLS Anda hanya dengan satu flag di command line.

Audit yang perlu dijalankan hari ini

Panduan respons dari SafeDep sejauh ini adalah rujukan paling praktis. Berikut versi ringkasnya, disusun supaya bisa dikerjakan host demi host dan image demi image.

1. Uji dengan curl

SafeDep menyediakan dua host uji. Jalankan keduanya dari setiap lingkungan yang Anda pedulikan, termasuk dari dalam kontainer, bukan hanya di host:

curl -s -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com; echo "exit: $?"
curl -s -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com; echo "exit: $?"

Exit code 0 berarti koneksi berhasil dan lingkungan itu terdampak. Exit code 60 berarti verifikasi sertifikat gagal, dan itulah hasil yang Anda harapkan. Uji ini hanya memeriksa bundle sistem yang dipakai curl. Runtime bahasa pemrograman sering membawa bundle sendiri, jadi hasil curl yang bersih belum tentu berarti proses Python atau Node Anda aman.

2. Periksa runtime yang membawa bundle sendiri

SafeDep mencantumkan versi perbaikan berikut:

• Python: certifi 2026.10.19 atau lebih baru.
• Node.js: 22.23.4, 24.22.1, atau 26.12.1. Node 20 ke bawah tidak mendapat perbaikan, jadi ini saat yang tepat untuk menuntaskan upgrade yang tertunda itu.
• Go: 1.26.10+ atau 1.27.3+. Memperbarui toolchain saja tidak cukup; binary-nya harus di-build ulang. Go 1.25 tidak mendapat perbaikan.
• Rust: webpki-roots 1.0.10.

Per 22 Oktober, SafeDep belum mencantumkan perbaikan untuk Bun, certifi Erlang, maupun Bottlerocket. Kalau Anda bergantung pada salah satunya, pantau terus dan siapkan solusi sementara, jangan berasumsi perbaikannya akan datang tepat waktu.

python -c "import certifi; print(certifi.__version__)"
node --version
go version
go version -m ./your-binary | head -1

Untuk Java, cek trust store mana yang benar-benar dimuat oleh JVM Anda dan kapan terakhir diperbarui, lalu perlakukan seperti dependensi lain. Setelah itu perbarui paket ca-certificates di OS pada setiap host dan base image.

3. Build ulang image, jangan hanya menambal host

Peringatan SafeDep yang ini layak ditempel di monitor: "A host upgrade does not change an image that is already built". Upgrade di host tidak mengubah image yang sudah jadi. Setiap image membawa salinan bundle CA sendiri, di layer mana pun yang terakhir menyentuhnya. Build ulang dengan base yang segar:

docker build --pull --no-cache -t your-service:latest .

Lalu deploy ulang, dan jalankan uji curl di dalam kontainer baru untuk memastikannya.

4. Cocokkan lewat fingerprint, bukan nama

Kalau Anda menulis scanner untuk mencari root atau intermediate yang bermasalah, SafeDep menyarankan agar tidak mencocokkan berdasarkan nama sertifikat. Bandingkan fingerprint SHA-256. Nama bisa diduplikasi atau dipakai ulang, fingerprint tidak.

Pelajarannya: trust store adalah dependensi

Ketika ini mulai merusak sesuatu, dan penggantian sekitar 30.000 sertifikat (estimasi eMudhra sendiri, dikutip iTnews) pasti akan merusak sesuatu, akan ada orang di tim Anda yang tergoda menghilangkan error dengan verify=False, NODE_TLS_REJECT_UNAUTHORIZED=0, atau InsecureSkipVerify. Saran Cloudflare, yang dikutip di artikel yang sama, adalah yang benar: "It's important to not resolve these errors by disabling verification." Mematikan verifikasi di tengah insiden seperti ini sama saja menukar paparan yang sempit dengan paparan total.

Poin yang lebih besar menyangkut ritme patch. Kebanyakan tim melacak CVE di library mereka dan punya proses untuk merilis perbaikan dalam hitungan hari. Hampir tidak ada yang memperlakukan bundle CA dengan cara yang sama, padahal bundle itulah yang menentukan siapa lawan bicara yang dipercaya software Anda. Insiden ini alasan kuat untuk mengubahnya:

• Masukkan ca-certificates, certifi, webpki-roots, dan versi runtime Anda ke pelacakan dependensi yang sama dengan yang Anda pakai untuk hal lain.
• Build ulang image kontainer secara terjadwal, bukan hanya saat kode aplikasi berubah, supaya perbaikan di base layer benar-benar sampai ke production.
• Simpan uji curl tadi, atau yang serupa, sebagai smoke test di CI selama host ujinya masih aktif.
• Inventarisasi perangkat dengan firmware beku sekarang juga. Kalau perangkat itu akan memercayai kunci ini sampai 2039, yang dibutuhkan adalah kontrol jaringan, bukan harapan.

Bagi eMudhra, keluar dari pasar adalah akhir cerita. Bagi sistem Anda, ini awal dari pembersihan yang harus Anda kerjakan sendiri, karena browser tidak akan mengerjakannya untuk Anda.