Pada tahun 2014, sebuah bug ditemukan di OpenSSL, perpustakaan enkripsi populer yang digunakan untuk mengamankan sebagian besar server di Internet. Bug ini memungkinkan penyerang menyalahgunakan fitur tidak jelas yang disebut detak jantung TLS untuk membaca memori dari server yang terpengaruh. Heartbleed adalah berita besar karena memungkinkan penyerang mengekstrak rahasia terpenting di server: kunci privat sertifikat TLS/SSL-nya. Setelah mengonfirmasikan bahwa bug tersebut mudah dieksploitasi,, kami mencabut dan menerbitkan kembali lebih dari 100.000 sertifikat, yang menyoroti beberapa masalah utama tentang cara mengamankan Internet.
Meskipun Heartbleed dan peristiwa kompromi penting lainnya menyakitkan bagi tim keamanan dan operasi di seluruh dunia, peristiwa itu juga memberikan kesempatan belajar bagi industri. Selama tujuh tahun terakhir, Cloudflare telah mengambil pelajaran dari Heartbleed dan menerapkannya untuk meningkatkan desain sistem dan ketahanan Internet kami secara keseluruhan. Baca terus untuk mengetahui cara menggunakan Cloudflare untuk mengurangi risiko kompromi kunci dan mengurangi biaya pemulihan jika kejadian tersebut terjadi.
Menjaga kunci tetap aman
Prinsip penting dari desain sistem keamanan adalah pertahanan mendalam. Hal-hal penting harus dilindungi dengan beberapa layer pertahanan. Inilah sebabnya mengapa orang yang sadar akan keamanan menyimpan kunci rumah cadangan di kotak kunci yang aman bukan di bawah keset. Untuk sistem kriptografi yang menghadap ke Internet, pertahanan mendalam berarti merancang sistem Anda sehingga kunci tidak dicuri dengan satu eksploitasi saja. Ini tidak berlaku untuk OpenSSL dan Heartbleed. Kunci privat dimuat ke dalam memori ke dalam proses menghadap ke Internet yang tidak aman untuk memori, jadi hanya satu bug pengungkapan memori yang diperlukan untuk mencurinya.
Keyless SSL: menjaga server tetap terpisah dari kunci
Strategi pertahanan mendalam yang efektif untuk melindungi kunci pribadi TLS/SSL adalah dengan membagi proses menjadi dua bagian: bagian kunci pribadi/autentikasi, dan bagian enkripsi/deskripsi. Inilah tepatnya mengapa kami mengembangkan Keyless SSL, untuk memungkinkan pelanggan tetap mengontrol kunci privat mereka sekaligus memungkinkan Cloudflare menangani detail koneksi lainnya. Keyless SSL menyediakan pemisahan fisik antara tempat kunci yang sedang digunakan dan tempat penyimpanannya. Kami mendukung Keyless SSL baik untuk modul keamanan perangkat lunak maupun perangkat keras (HSM), dan hari ini kami mengumumkan bahwa kami sekarang mendukung beberapa HSM berbasis cloud.
Geo Key Manager: manajemen kunci yang dapat dikonfigurasi berdasarkan geografi
Heartbleed menunjukkan kepada kami bahwa strategi ini juga dapat berguna dalam menambahkan layer keamanan ekstra untuk kunci privat yang kami kelola untuk pelanggan kami. Pada tahun 2017, kami meluncurkan Geo Key Manager, sebuah fitur yang memungkinkan pelanggan untuk memilih lokasi mana di dunia yang mereka inginkan untuk menyimpan kunci mereka. Geo Key Manager melindungi kunci dari kompromi fisik server di berbagai geografi. Pada tahun 2019, kami melangkah lebih jauh dengan menerapkan strategi yang disebut Keyless Everywhere, yang memindahkan semua kunci terkelola ke sistem yang menyediakan pemisahan logis antara Internet dan kunci privat.
Kredensial yang Didelegasikan: pemisahan kunci tanpa latensi
Keyless SSL adalah solusi keamanan yang hebat, tetapi tergantung di mana kunci disimpan, Keyless SSL dapat menimbulkan beberapa latensi. Karena itu, kami bekerja dengan IETF untuk mengembangkan standar baru yang disebut Kredensial yang Didelegasikan, yang memungkinkan koneksi menggunakan kunci berumur pendek yang ditandatangani oleh sertifikat alih-alih sertifikat itu sendiri di TLS. Ini menghilangkan latensi tambahan yang diakibatkan oleh Keyless SSL. Kami mendukung Kredensial yang Didelegasikan untuk semua pelanggan Keyless SSL dan Geo Key Manager; dan Firefox 89 (Mei 2021) akan mengaktifkan dukungan Delegated Credential secara default.
Membuat pencabutan berfungsi
Ketika Heartbleed terjadi dan ratusan ribu sertifikat dianggap berpotensi disusupi, hal logis yang harus dilakukan adalah mencabut dan menerbitkan kembali sertifikat tersebut. Melakukan hal tersebut dapat menyebabkan beberapa konsekuensi yang tidak terduga.
Konsekuensi pertama dari pencabutan adalah lonjakan lalu lintas jaringan yang besar terkait dengan informasi pencabutan. Pada tahun 2014, ada tiga mekanisme utama pencabutan sertifikat:
Daftar Pencabutan Sertifikat (CRL)
Daftar nomor seri yang dicabut untuk otoritas sertifikat tertentu
Protokol Status Sertifikat Online(OCSP)
Protokol untuk menanyakan otoritas sertifikat tentang status pencabutan sertifikat
OCSP dapat ditanyakan oleh browser atau respons dapat dimasukkan oleh server pada waktu koneksi "stapel OCSP"
CRLSets — Sistem pencabutan kustom Chrome
Daftar meta nomor seri yang dicabut, terbatas pada sertifikat yang bernilai tinggi
Puluhan ribu sertifikat dicabut sekaligus karena potensi kompromi dari Heartbleed. Setelah ini, CRL untuk CA terkemuka, GlobalSign, meningkat dari 22KB menjadi 4,7MB dalam sehari. Ini menyebabkan gangguan besar pada infrastruktur caching internal Cloudflare dan lonjakan bandwidth yang memengaruhi Internet secara luas karena semua klien yang mengandalkan CRL memeriksa validasi sertifikat (sebagian besar Microsoft Windows) mengunduh file.
Setelah peristiwa pencabutan ini, menjadi jelas bahwa ada alasan lain mengapa pencabutan bukan merupakan sistem yang fungsional. Di Firefox, jika pengguna membuat koneksi ke situs dan respons OCSP yang distapel tidak disediakan, Firefox akan menanyakan server OCSP untuk mendapatkan respons. Namun, Firefox menerapkan strategi gagal-terbuka: jika respons OCSP terlalu lama, pemeriksaan pencabutan akan dilewati dan halaman dirender. Penyerang dengan posisi jaringan dengan hak istimewa dapat menggunakan sertifikat yang disusupi dan dicabut untuk menyerang pengguna hanya dengan memblokir permintaan OCSP dan membiarkan browser melewati pemeriksaan pencabutan. Staple OCSP adalah cara bagi server untuk mendapatkan respons OCSP ke browser dengan cara yang andal, tetapi karena staple bukan persyaratan untuk klien, penyerang tidak dapat menyertakan staple sehingga browser akan gagal terbuka, yang membuat pengguna rentan untuk diserang. OCSP juga tidak memberikan perlindungan yang kuat terhadap penyusupan kunci dalam mode gagal-terbuka (ditambah, OCSP adalah kebocoran privasi, tapi itu masalah lain).
Situasi di Chrome bahkan lebih buruk dari perspektif keamanan. Karena baik OCSP maupun CRL tidak diperiksa untuk sebagian besar sertifikat (CRLSet hanya berisi sertifikat "Validasi Diperluas" yang dicabut), sebagian besar sertifikat dipercaya tanpa memeriksa status pencabutan. Solusi untuk mencabut kumpulan sertifikat yang dikelola Cloudflare di Chrome untuk Heartbleed sebenarnya adalah patch singkat ke basis kode Chromium. Jelas ini bukanlah solusi yang dapat ditingkatkan!
Pencabutan sertifikat secara massal pada tahun 2014 jelas tidak berhasil. Sebagian sertifikat pada saat itu berlaku hingga lima tahun, jadi kunci yang disusupi menjadi masalah untuk waktu yang lama.
Pada tahun 2015, standar baru muncul yang tampaknya memberikan solusi yang masuk akal untuk masalah ini: OCSP Must-staple. Sertifikat yang diterbitkan dengan fitur must-staple hanya dapat dipercaya jika disertai dengan staple OCSP yang valid. Jika sertifikat must-staple disusupi dan dicabut, maka sertifikat tersebut hanya dapat digunakan untuk menyerang pengguna selama masa pakai OCSP yang diterbitkan terakhir (biasanya 10 hari atau kurang). Ini adalah peningkatan besar dan memungkinkan pemilik sertifikat untuk membatasi risiko mereka secara keseluruhan.
Cloudflare telah mendukung staple OCSP dengan upaya yang terbaik sejak 2012. Pada tahun 2017, kami mulai meningkatkan keandalan staple OCSP kami sehingga kami dapat mendukung sertifikat OCSP must-staple. Hasil dari pekerjaan ini adalah staple OCSP dengan keandalan tinggi dan studi penelitian yang diterbitkan di IMC yang menunjukkan kelayakan OCSP must-staple secara lebih luas di Internet. Cloudflare sekarang mendukung sertifikat OCSP must-staple, yang menyediakan jaring pengaman tambahan jika terjadi kompromi kunci di masa mendatang.
2014 vs. sekarang
Kami telah membuat banyak kemajuan dalam tujuh tahun. Cloudflare terus berinovasi dalam perlindungan kunci dan ruang keamanan TLS/SSL. Inilah yang berubah selama beberapa tahun terakhir:
2014
Sertifikat lima tahun
Opportunistic OCSP stapling
Tidak ada OCSP must-staple
Kunci dalam proses yang menghadap ke Internet
Tidak ada Keyless SSL
Tidak ada Kredensial yang Didelegasikan
2021
Sertifikat seumur hidup yang dapat dikonfigurasi (dari satu tahun hingga dua minggu dengan ACM)
100% dukungan stapel OCSP
Dukungan OCSP Must-staple
Keyless di mana saja
Dukungan Keyless SSL + Cloud HSM! (baru)
Geo Key Manager
Dukungan Kredensial yang Didelegasikan
Peningkatan ini dan lebih banyak lagi adalah alasan besar mengapa Cloudflare adalah pemimpin dalam ruang keamanan dan mengapa Heartbleed berikutnya akan lebih baik.