Cloudflare tambah visibility Post-Quantum TLS: sekarang engineer bisa lihat koneksi yang masih classical
Migrasi post-quantum sering terasa abstrak karena support di edge belum tentu berarti setiap koneksi pengguna benar-benar bernegosiasi dengan algoritma post-quantum. Cloudflare pada 29 September 2026 memperluas visibility ini sehingga engineer bisa melihat key exchange yang dipakai traffic nyata. Fokus praktisnya bukan sekadar menyalakan fitur, tetapi mengukur berapa banyak koneksi yang sudah memakai X25519MLKEM768, menemukan gap, lalu menentukan apakah masalahnya ada di client, protocol, middlebox, atau jalur origin.
Dipublikasikan 1 Oktober 2026 · Sumber utama 29 September 2026
Request TLS masuk ke Cloudflare→
Key exchange dinegosiasikan→
ClientTLSKeyExchangeGroup dicatat→
Analytics / Log Explorer / Logpush dianalisis→
Gap classical ditindaklanjuti
Apa yang berubah pada 29 September?
Cloudflare mengumumkan visibility tambahan untuk post-quantum TLS 1.3 di produk Application Security dan Logs. Key exchange yang dinegosiasikan pada koneksi visitor ke Cloudflare dapat dilihat melalui HTTP Traffic Analytics, Log Explorer, dan Logpush. Ini melengkapi field ClientTLSKeyExchangeGroup yang sebelumnya sudah tersedia di dataset http_requests, sehingga posture post-quantum bisa diperiksa dari traffic zone sendiri dan tidak hanya dari statistik global.
Support PQC di edge belum sama dengan koneksi benar-benar memakai PQC
Cloudflare sudah mendukung hybrid post-quantum key agreement untuk website dan API yang dilayani melalui TLS 1.3, tetapi koneksi hanya mendapat perlindungan post-quantum jika client juga mendukung dan menegosiasikan algoritma yang sesuai. Karena itu angka adopsi harus dibaca dari handshake nyata. Browser, runtime, library, proxy, atau middlebox yang berbeda dapat menghasilkan key exchange berbeda.
Field utama: ClientTLSKeyExchangeGroup
Pada dataset http_requests, ClientTLSKeyExchangeGroup menunjukkan group yang dinegosiasikan pada koneksi client-to-Cloudflare. X25519MLKEM768 menandakan hybrid post-quantum key agreement. Nilai classical dapat berupa X25519, P-256, atau group lain. UNK berarti group tidak dapat ditentukan, sedangkan NONE perlu dianalisis sesuai konteks dataset dan protocol. Jangan langsung menganggap setiap nilai selain X25519MLKEM768 sebagai insiden.
Kenapa X25519MLKEM768 disebut hybrid?
Cloudflare menggabungkan X25519 dengan ML-KEM. Pendekatan hybrid mempertahankan perlindungan dari algoritma classical yang sudah matang sambil menambahkan key agreement yang dirancang tahan terhadap quantum attack. Tujuan pentingnya adalah mengurangi risiko harvest-now-decrypt-later: adversary menyimpan traffic terenkripsi hari ini untuk mencoba mendekripsinya ketika kemampuan quantum yang relevan tersedia di masa depan.
Apa yang sebaiknya diukur engineer?
Mulai dari persentase request HTTPS yang memakai X25519MLKEM768 dibanding key exchange classical. Setelah itu pecah berdasarkan hostname, user agent, country, path, atau dimensi lain yang tersedia dan relevan. Breakdown membantu membedakan gap yang luas dari gap yang hanya muncul pada satu aplikasi legacy, runtime tertentu, atau kelompok client tertentu.
Contoh analisis Logpush ke SIEM
Kalau http_requests sudah dikirim lewat Logpush, gunakan ClientTLSKeyExchangeGroup sebagai dimensi agregasi. Contoh berikut hanya pseudo-query karena syntax SIEM berbeda-beda. Tujuannya adalah membandingkan jumlah request per key exchange, bukan menjadi query universal.
// PSEUDO QUERY — sesuaikan dengan SIEM
http_requests
| where ClientSSLProtocol == "TLSv1.3"
| stats count() by ClientTLSKeyExchangeGroup
| sort count desc
Decision path saat masih banyak koneksi classical
Kalau traffic classical terkonsentrasi pada user agent atau runtime tertentu, cek dukungan TLS library dan versinya. Kalau hanya muncul pada jalur jaringan tertentu, review proxy, TLS inspection, load balancer, atau middlebox. Kalau traffic bukan TLS 1.3, selesaikan dulu penyebab protocol fallback karena post-quantum key agreement Cloudflare bergantung pada TLS 1.3-based protocols. Jangan memaksa kesimpulan bahwa edge gagal hanya dari satu field.
Bedakan visitor-to-edge dan edge-to-origin
Telemetry visitor-to-Cloudflare tidak otomatis membuktikan koneksi Cloudflare-to-origin juga post-quantum. Itu dua handshake berbeda. Untuk origin, Cloudflare mendukung X25519MLKEM768 dan menyediakan mekanisme automatic key exchange. Verifikasi origin perlu dilakukan terpisah menggunakan tooling dan telemetry yang sesuai.
Contoh verifikasi origin
Dokumentasi Cloudflare memberikan contoh memakai BoringSSL untuk menguji apakah origin dapat bernegosiasi dengan X25519MLKEM768. Jalankan hanya terhadap origin yang Anda kelola atau punya izin untuk diuji.
Middlebox bisa menjadi sumber masalah yang tidak kelihatan
Post-quantum key share membuat ClientHello lebih besar dan dapat terpecah menjadi lebih dari satu packet. Implementasi TLS atau middlebox yang mengalami protocol ossification dapat bermasalah dengan pola ini. Cloudflare Radar API bahkan membedakan gejala seperti split ClientHello failure, HelloRetryRequest failure, dan unknown keyshare. Karena itu gap PQC tidak selalu berarti client sengaja menonaktifkan algoritma baru.
False positive dan limitasi analisis
Traffic classical bukan otomatis malicious dan bukan otomatis misconfiguration. Client lama mungkin memang belum mendukung ML-KEM. Monitoring juga harus memperhitungkan bot, synthetic monitor, API client, mobile runtime, dan perangkat enterprise yang lifecycle upgrade-nya berbeda. Selain itu, key agreement post-quantum tidak sama dengan post-quantum authentication; signature migration adalah lapisan berbeda.
Apa yang perlu dicek minggu ini?
Pastikan dataset dan dashboard yang dipakai menampilkan ClientTLSKeyExchangeGroup, buat baseline rasio X25519MLKEM768 versus classical, identifikasi top user agent atau hostname yang masih classical, lalu review apakah gap berasal dari client support atau network path. Untuk aplikasi sensitif, dokumentasikan visitor-to-edge dan edge-to-origin secara terpisah agar status end-to-end tidak disimpulkan dari satu sisi saja.
Takeaway buat network dan security engineer
Nilai terbesar update ini ada pada observability. Migrasi kriptografi tidak cukup dinyatakan selesai karena platform mendukung algoritma baru. Engineer perlu bukti dari traffic nyata: algoritma apa yang benar-benar dinegosiasikan, siapa yang masih fallback, di jalur mana gap muncul, dan apakah perubahan kompatibilitas menimbulkan error. Dengan telemetry tersebut, post-quantum migration bisa diperlakukan seperti program engineering yang terukur, bukan checklist abstrak.
