Pada akhirnya, tweet Jeff Johnson dengan jelas menunjukkan akar penyebabnya. Ternyata layanan Responder OCSP Apple terlalu kelebihan beban, sehingga macOS tidak dapat memverifikasi sertifikat kriptografi pengembang aplikasi.
Tetapi mengapa OCSP Responder berada di jalur kritis untuk meluncurkan aplikasi? Pada artikel ini, kami akan membahas secara singkat penandatanganan kode, cara kerja Protokol Status Sertifikat Online (OCSP), mengapa ini sepenuhnya salah, dan beberapa alternatif terbaik. Tidak seperti posting lain tentang kejadian ini, saya ingin membahas aspek kriptografi praktis (pada tingkat tinggi) dan menawarkan perspektif yang seimbang.
Penandatanganan Kode
Di portal pengembang, Apple menjelaskan tujuan penandatanganan kode:
Menandatangani kode aplikasi Anda memastikan pengguna bahwa itu berasal dari sumber yang dikenal dan belum diubah sejak terakhir kali ditandatangani. Aplikasi harus ditandatangani dengan sertifikat yang dikeluarkan oleh Apple sebelum dapat diintegrasikan, diinstal pada perangkat, atau dimasukkan ke katalog aplikasi.
Dengan kata lain, agar app dapat dipercaya di macOS, app harus ditandatangani dengan sertifikat berbasis pasangan kuncinya sendiri. Rantai kunci digunakan untuk membuat sertifikat "ID Pengembang" unik yang menyertakan kunci pribadi untuk digunakan oleh pengembang dan kunci publik untuk distribusi. Saat Apple telah menandatangani sertifikat ID Pengembang, pengembang dapat menggunakan kunci privat untuk membuat tanda tangan kriptografik di aplikasi mereka dengan setiap rilis.
Saat aplikasi diluncurkan, tanda tangannya diverifikasi terhadap kunci publik dari sertifikat pengembang. Sertifikat itu sendiri kemudian diverifikasi untuk memastikan bahwa sertifikat tersebut belum kedaluwarsa (sertifikat biasanya berlaku selama satu tahun), dan pada akhirnya ditandatangani oleh sertifikat akar Apple. Bisa juga ada sertifikat perantara sebagai bagian dari rantai hingga sertifikat akar. Ini adalah "rantai kepercayaan" karena sertifikat ID Pengembang ditandatangani oleh aplikasi, sertifikat perantara menandatangani sertifikat ID Pengembang, dan sertifikat akar Apple menandatangani sertifikat perantara. Perangkat Apple apa pun dapat memeriksa rantai kepercayaan ini dan karenanya menyetujui peluncuran aplikasi.
Ini mirip dengan infrastruktur kunci publik TLS Internet. Tetapi juga berbeda secara fundamental, karena Apple memiliki kendali penuh atas rantai kepercayaannya sendiri. CA lain tidak diizinkan mengeluarkan sertifikat penandatanganan kode yang valid karena semua sertifikat harus dikaitkan dengan Apple.
Jika verifikasi gagal, pengguna akan melihat jendela yang buruk:
Umpan balik
Apa yang terjadi jika pengembang melanggar kebijakan Apple atau kehilangan kunci pribadinya? Otoritas sertifikasi harus segera mencabut sertifikat yang diterbitkan. Jika sertifikat digunakan dengan jahat, tidak dapat diterima untuk menunggu berhari-hari atau berbulan-bulan sampai sertifikat itu kedaluwarsa secara alami, jika tidak, kebocoran kunci pribadi akan membuat seluruh sistem tidak berguna.
Dalam situasi inilah sertifikat dicabut. Ini adalah langkah tambahan dalam proses verifikasi tanda tangan, yang melibatkan menanyakan otoritas sertifikasi bahwa sertifikat tersebut masih berlaku.
Di Internet, ini dilakukan dengan cara yang paling sederhana. CA memberi Anda Daftar Pencabutan Sertifikat (CRL) dengan nomor seri dari semua sertifikat yang dicabut, dan Anda memverifikasi bahwa sertifikat tersebut tidak ada dalam daftar. Namun, browser berhenti menggunakan pendekatan ini karena daftarnya semakin panjang. Terutama setelah eksploitasi mengerikan seperti Heartbleed memerlukan pencabutan sertifikat besar-besaran.
Protokol Status Sertifikat Online (OCSP) adalah alternatif yang memungkinkan Anda memvalidasi sertifikat secara real time. Setiap sertifikat berisi OCSP Responder bawaan, yang merupakan URL yang Anda minta dan memberitahu Anda jika sertifikat telah dicabut. Dalam kasus Apple, ini
ocsp.apple.com... Jadi sekarang, selain memverifikasi validitas kriptografi tanda tangan, setiap kali Anda meluncurkan aplikasi, Anda melakukan verifikasi waktu nyata di situs Apple (dengan beberapa cache) bahwa mereka masih menganggap sertifikat pengembang itu sah.
Masalah ketersediaan OCSP
Masalah besar dengan OCSP adalah bahwa layanan eksternal menjadi satu titik kegagalan. Apa yang terjadi jika penjawab OCSP mati atau tidak tersedia? Apakah kita hanya menolak untuk memverifikasi sertifikat (gagal-gagal)? Atau apakah kita berpura-pura bahwa pemeriksaan itu berhasil (gagal lunak)?
Apple terpaksa menggunakan perilaku gagal-lunak, jika tidak, aplikasi tidak akan bekerja secara offline. Semua browser utama juga menerapkan perilaku gagal-lunak, karena responden OCSP secara tradisional tidak dapat diandalkan dan browser ingin memuat situs bahkan jika responden CA tidak aktif untuk sementara.
Tetapi kegagalan lunak bukanlah pilihan yang baik, karena dengan kontrol atas jaringan, penyerang dapat memblokir permintaan ke responden, dan pemeriksaan akan dilewati. Faktanya, "perbaikan" kesalahan tersebut telah beredar luas di Twitter selama kejadian ini: lalu lintas ke sana
ocsp.apple.comdiblokir oleh sebuah baris di file / etc / hosts. Banyak yang akan meninggalkan baris ini untuk sementara waktu, karena menonaktifkan OCSP tidak menyebabkan masalah yang nyata.
Kejadian
Jika validasi OCSP Apple dibangun di atas kegagalan lunak, mengapa aplikasi akan hang saat responder OCSP dinonaktifkan? Mungkin karena itu sebenarnya kesalahan yang berbeda: responden OCSP sebenarnya tidak sepenuhnya dinonaktifkan. Itu tidak bekerja dengan baik.
Karena beban dari jutaan pengguna di seluruh dunia yang memperbarui ke macOS Big Sur, server Apple melambat dan tidak merespons dengan baik permintaan OCSP. Tetapi pada saat yang sama, mereka bekerja cukup baik sehingga soft-fail tidak berhasil.
Masalah privasi OCSP
Selain masalah ketersediaan OCSP, protokol tersebut tidak dirancang untuk melindungi privasi sejak awal. Permintaan OCSP dasar mencakup permintaan HTTP yang tidak terenkripsi ke penjawab OCSP dengan nomor seri sertifikat. Dengan cara ini, responder tidak hanya dapat menentukan sertifikat yang Anda minati, tetapi juga ISP Anda dan orang lain yang mencegat paket. Apple dapat membuat daftar, secara berurutan, aplikasi pengembang mana yang Anda buka, dan pihak luar dapat melakukan hal yang sama.
Enkripsi dapat ditambahkan, dan ada versi yang lebih baik dan lebih pribadi yang disebut penjepitan OCSP , tetapi Apple juga tidak melakukannya. Stapel OCSP tidak terlalu masuk akal dalam skenario ini, tetapi teknologi ini menggambarkan bahwa OCSP seharusnya tidak membocorkan data secara default.
Masa depan yang lebih baik
Insiden tersebut memicu diskusi yang meriah di komunitas, dengan satu pihak menyatakan, "Komputer Anda sebenarnya bukan milik Anda," dan pihak lainnya berargumen, "Membangun kepercayaan pada aplikasi itu sulit, tetapi Apple melakukannya dengan baik . " Saya mencoba untuk menunjukkan bahwa OCSP adalah cara yang buruk untuk mengelola pencabutan sertifikat, dan di masa mendatang hal itu akan menyebabkan lebih banyak insiden terkait dengan ketersediaan dan privasi responden. Menurut pendapat saya, ini adalah keputusan teknik yang buruk - untuk mengatur ketergantungan peluncur aplikasi di OCSP. Setidaknya dalam jangka pendek, mereka mengurangi kerusakan dengan meningkatkan waktu cache respons .
Untungnya, metode terbaik untuk mencabut sertifikat, CRLite, sudah hampir matang. Ini memungkinkan Anda untuk mempersingkat semua daftar pencabutan sertifikat ke ukuran yang wajar. Di blog Scott Helme memberikan ringkasan yang bagus tentang bagaimana CRLite menggunakan filter Bloom untuk mengembalikan pendekatan lama dengan daftar sertifikat yang dicabut, yang beroperasi hingga OCSP.
Perangkat MacOS mungkin secara berkala menerima pembaruan untuk CRL ini dan melakukan pemeriksaan secara lokal di perangkat, menangani masalah ketersediaan dan privasi OCSP. Di sisi lain, karena daftar pencabutan ID Pengembang jauh lebih kecil daripada daftar semua sertifikat yang dicabut PKI, ada baiknya bertanya mengapa Apple tidak menggunakan CRL. Mereka mungkin tidak ingin mengungkapkan sertifikat mana yang telah dicabut.
Kesimpulan
Secara keseluruhan, insiden ini adalah alasan yang baik untuk merefleksikan model kepercayaan yang dipromosikan oleh organisasi seperti Apple dan Microsoft. Perangkat lunak perusak menjadi lebih canggih, dan kebanyakan orang tidak dapat menentukan apakah aman untuk menjalankan binari tertentu. Penandatanganan kode tampaknya merupakan cara kriptografik yang bagus untuk membangun kepercayaan untuk aplikasi dan setidaknya menghubungkan aplikasi dengan pengembang terkenal. Dan mencabut sertifikat adalah bagian penting dari kepercayaan itu.
Tetapi hanya sedikit gangguan dalam proses verifikasi OCSP yang merusak keanggunan kriptografi dari proses penandatanganan dan verifikasi kode. OCSP juga banyak digunakan untuk sertifikat TLS di Internet, tetapi kegagalan terjadi lebih sedikit akibat bencana karena banyaknya CA dan meluasnya ketidaktahuan tentang kegagalan dari browser. Selain itu, orang terbiasa melihat situs web yang tidak tersedia dari waktu ke waktu, tetapi mereka tidak mengharapkan hal yang sama dari aplikasi di komputer mereka sendiri. Pengguna MacOS khawatir aplikasi mereka sendiri terpengaruh oleh masalah infrastruktur Apple. Namun, ini adalah hasil yang tidak dapat dihindari, karena validasi sertifikat bergantung pada infrastruktur eksternal, dan tidak ada infrastruktur yang 100% dapat diandalkan.
Scott Helme juga mengungkapkan keprihatinan tentang kewenangan yang diperoleh CA jika pencabutan sertifikat benar-benar efektif. Bahkan jika Anda tidak khawatir tentang potensi penyensoran, kesalahan terkadang akan terjadi dan harus dipertimbangkan terhadap manfaat keamanan. Seperti yang ditemukan oleh seorang pengembang ketika Apple secara keliru mencabut sertifikatnya , risiko menjalankan pada platform yang terisolasi adalah Anda dapat diisolasi darinya.