Kunci CA eMudhra Ternyata Cuma Satu Byte. Container Kamu Masih Percaya?

Versi bahasa Inggris: The eMudhra CA Keys Were One Byte Long. Does Your Container Still Trust Them?

Delapan private key milik intermediate CA eMudhra ternyata hanya angka satu byte, bisa ditebak dalam hitungan milidetik. Chrome dan Firefox memblokirnya di hari yang sama. Base image, bundle Python, dan keystore JVM kamu tidak memblokir apa pun sampai ada yang rebuild.

TL;DR (untuk pembaca non-teknis)

• Sebuah certificate authority (CA), yaitu lembaga yang menjamin sebuah situs itu asli, membuat delapan kunci penandatangan yang begitu lemah sehingga siapa pun bisa menebaknya.
• Browser menutup celah ini dalam hitungan jam. Tapi server, script, sistem build, dan aplikasi punya daftar “siapa yang dipercaya” sendiri, dan daftar itu tidak update otomatis.
• Risiko bisnisnya: penyerang bisa menyamar sebagai layanan tepercaya di mata software kamu, bukan di mata browser pelanggan.
• Tanyakan ke tim teknis: “Layanan kita ambil daftar CA tepercayanya dari mana, dan kapan terakhir di-refresh?”

Yang terjadi

Fakta dari pernyataan eMudhra, analisis Scott Helme, dan ringkasan di dev.to:

• Seorang peneliti melaporkan pada 17 Oktober 2026 bahwa private key delapan intermediate CA eMudhra bocor.
• Helme menemukan kunci itu bukan nilai acak 384-bit. Isinya angka kecil seperti 4, 56, dan 115, jadi “pencariannya” tinggal mencoba 1, 2, 3, dan seterusnya. Google menyebutnya “dibuat dengan randomness yang tidak memadai”. Secara teknis benar, tapi sangat meremehkan.
• eMudhra menyatakan ada cacat di langkah key wrap/unwrap pada ceremony 30 April 2025. Hasilnya, muncul set kunci kedua yang lemah di samping yang kuat, dan set lemah inilah yang dikirim ke root program.
• eMudhra juga menyatakan root key tidak terdampak, dan tidak ada dari delapan intermediate itu yang menerbitkan sertifikat untuk situs sungguhan. Satu berada di production tapi belum menerbitkan apa pun.
• Chrome memblokir intermediate tersebut lewat CRLSet dalam hitungan jam. OneCRL milik Mozilla sampai ke Firefox standar dalam waktu kurang dari tiga jam.
• Menurut blog keamanan Google, emSign ECC Root CA - G3 juga akan dihapus dari Chrome Root Store, mulai bergulir 27 Oktober 2026.

Kenapa ini relevan di Indonesia

Banyak tim di Indonesia menjalankan container di VM, cloud, atau on-prem dengan image yang di-build sekali lalu jalan berbulan-bulan. Layanan internal, integrasi antar-sistem, dan job CI sering memanggil endpoint HTTPS tanpa ada browser di antaranya.

Di jalur seperti itu, perlindungan cepat dari browser tidak ikut bekerja. Yang menentukan hanya isi trust store di image atau runtime kamu. Jadi pertanyaan “kapan terakhir image ini di-rebuild?” ikut menentukan postur keamanan, bukan sekadar urusan housekeeping.

Celahnya

Browser            -> fast distrust lane (CRLSet, OneCRL)   -> blocked in hours
Debian/Ubuntu img  -> ca-certificates package, baked in      -> stale until rebuilt
Python (certifi)   -> its own bundle                         -> stale until upgraded
Java (cacerts)     -> JDK keystore                           -> wait for JDK vendor
Vendored (Go, Node, mobile, firmware) -> frozen snapshots    -> depends on release

Menurut Endor Labs, certifi 2026.10.19 dan Alpine ca-certificates 20261020-r0 sudah membawa perubahannya. Untuk Java, anggap belum terkonfirmasi sampai vendor JDK kamu menyatakan sebaliknya. Poin utama mereka: TLS stack default di Python, Go, Node, dan kebanyakan CLI tool tidak mengecek revocation, jadi satu-satunya cara menghilangkan risiko adalah update trust store.

Kata para praktisi

• Kegagalan proses. Di LWN, seorang komentator bertanya bagaimana HSM bisa menghasilkan kunci satu byte, dan curiga masalahnya lebih dalam dari satu script yang bug.
• Marketing versus kenyataan. Komentator lain menyoroti CA ini memakai bahasa post-quantum dan zero-trust, sementara yang dikirim setara satu byte entropi.
• Keraguan soal penyimpanan. Yang ketiga menunjuk bahwa kesulitan eMudhra memverifikasi tanda tangan CRL-nya sendiri mengisyaratkan kunci tidak disimpan di HSM sebagaimana mestinya.
• Usulan struktural. Satu komentator mengusulkan HSM attestation wajib untuk setiap root dan intermediate, supaya pembuatan kunci bisa dibuktikan.
• Pandangan “sudah terkendali”. Tidak semua melihatnya sebagai darurat. Karena belum ada sertifikat dari enam intermediate TLS itu yang tercatat di Certificate Transparency, browser yang mewajibkan CT tetap akan menolak sertifikat palsu. Bantahan Helme: curl dan Python dengan senang hati menerima chain palsu di proof of concept-nya.

Pendapat saya

Saya setuju dengan yang bilang CA adalah ceritanya, dan dengan yang bilang trust store adalah pelajarannya. Dua-duanya benar, di lapisan yang berbeda.

Respons browser sangat baik dan saya tidak mau meremehkannya. Hitungan jam, bukan minggu. Tapi kecepatan itu hanya melindungi satu jenis client yang memang dirancang untuk itu. Gambaran jujurnya: web PKI punya jalur cepat untuk browser dan jalur lambat untuk yang lain, dan sebagian besar traffic backend ada di jalur lambat.

Soal pandangan “sudah terkendali”, saya kurang sependapat. Belum ada sertifikat yang tercatat bukan jaminan untuk masa depan. Kuncinya sudah publik, jadi yang tersisa di antara client internal kamu dan sertifikat palsu hanyalah apakah trust store masih mencantumkan parent-nya. Itu bisa diperbaiki dengan rebuild, jadi lakukan.

Untuk tim, ini mengarah ke satu kebijakan yang membosankan: base image di-rebuild terjadwal, dan versi trust store bisa di-query, bukan sekadar diharapkan aman. Ini juga mendukung diversifikasi CA dan masa berlaku sertifikat yang pendek, karena mengganti CA jauh lebih mudah kalau sudah pernah dilatih.

Coba dalam 15 menit

1. Daftar siapa saja yang melakukan panggilan TLS keluar

Service, worker, CI runner, script. Tanyakan “trust store yang mana”, bukan “versi berapa”.

2. Cek bundle OS di container yang sedang jalan

docker exec <container> sh -c 'ls -l /etc/ssl/certs/ca-certificates.crt; grep -c "BEGIN CERTIFICATE" /etc/ssl/certs/ca-certificates.crt'
docker exec <container> dpkg -l ca-certificates
docker exec <container> sh -c 'ls /etc/ssl/certs | grep -i emsign'

Bandingkan versi ca-certificates dengan yang dirilis distro kamu sekarang (Endor mencantumkan versi perbaikan untuk Debian dan Ubuntu). Tanggal file yang lebih lama dari 17 Oktober pada image yang berumur panjang berarti harus rebuild.

3. Cek bundle bahasa pemrograman

python -c "import certifi; print(certifi.__version__, certifi.where())"
pip install --upgrade certifi
keytool -list -cacerts -storepass changeit | grep -i emsign

requests memakai certifi kecuali kamu menimpa verify=, jadi satu mesin bisa punya dua “kebenaran” yang berbeda. Untuk Java, changeit adalah password default cacerts. Solusinya build JDK yang lebih baru, bukan mengedit keystore manual.

4. Lihat apa yang disajikan server

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null
openssl x509 -in certificate.pem -noout -issuer -subject -fingerprint -sha256

Kalau issuer menyebut intermediate eMudhra atau emSign, cari tahu kenapa dan kapan diperbarui.

Biar jadi kebiasaan

docker build --pull --no-cache -t myapp:$(date +%Y%m%d) .

Jalankan itu mingguan di CI. Base image yang segar membawa trust store yang segar.

Bahan belajar lanjutan

• Pernyataan insiden eMudhra sendiri, untuk penyebab menurut versi CA-nya.
• Tulisan Scott Helme, untuk cara kunci dipulihkan dan apa yang diterima client non-browser.
• Kebijakan Chrome Root Program, untuk memahami kenapa sebuah root bisa dicabut pada tanggal tertentu.

Pertanyaan

Kalau satu CA yang kamu andalkan dicabut kepercayaannya besok, bisakah kamu menyebutkan dalam sepuluh menit layanan mana saja yang masih akan mempercayainya?