Catatan penerjemah: untuk kenyamanan pembaca, tanggal diberikan dalam waktu Moskow
Kami baru-baru ini melewatkan masa berlaku salah satu sertifikat yang digunakan untuk menandatangani add-on. Hal ini mengakibatkan add-on dinonaktifkan untuk pengguna. Sekarang sebagian besar masalahnya telah diperbaiki, saya ingin berbagi rincian tentang apa yang terjadi dan pekerjaan yang telah dilakukan.
Latar Belakang: penambahan dan tanda tangan
Add-on yang diinstal harus dimiliki tanda tangan digital, yang melindungi pengguna dari add-on berbahaya dan memerlukan peninjauan minimal terhadap add-on oleh staf Mozilla. Kami memperkenalkan persyaratan ini pada tahun 2015 karena kami mengalaminya masalah serius dengan add-on berbahaya.
Cara kerjanya: Setiap salinan Firefox berisi "sertifikat root". Kunci “root” ini disimpan di Modul Keamanan Perangkat Keras (HSM)tanpa akses jaringan. Setiap beberapa tahun, “sertifikat perantara” baru ditandatangani dengan kunci ini, yang digunakan saat menandatangani add-on. Saat pengembang mengirimkan add-on, kami membuat "sertifikat akhir" sementara dan menandatanganinya menggunakan sertifikat perantara. Add-on itu sendiri kemudian ditandatangani dengan sertifikat akhir. Secara skematis sepertinya ini.
Harap dicatat bahwa setiap sertifikat memiliki "subjek" (kepada siapa sertifikat diterbitkan) dan "penerbit" (yang menerbitkan sertifikat). Dalam hal sertifikat akar, "subjek" = "penerbit", tetapi untuk sertifikat lainnya, penerbit sertifikat adalah subjek dari sertifikat induk yang menandatanganinya.
Poin penting: setiap add-on ditandatangani oleh sertifikat akhir yang unik, namun hampir selalu sertifikat akhir ini ditandatangani oleh sertifikat perantara yang sama.
Catatan Penulis: Pengecualian adalah tambahan yang sangat lama. Saat itu, berbagai sertifikat perantara digunakan.
Sertifikat perantara ini menimbulkan masalah: setiap sertifikat berlaku untuk jangka waktu tertentu. Sebelum atau setelah periode ini, sertifikat tidak valid dan browser tidak akan menggunakan add-on yang ditandatangani oleh sertifikat ini. Sayangnya, sertifikat perantara habis masa berlakunya pada 4 Mei pukul 4 pagi.
Konsekuensinya tidak serta merta terlihat. Firefox tidak terus-menerus memeriksa tanda tangan dari add-on yang diinstal, tetapi kira-kira sekali setiap 24 jam, dan waktu verifikasi bersifat individual untuk setiap pengguna. Akibatnya, beberapa orang langsung mengalami masalah, sementara yang lain mengalami masalah jauh di kemudian hari. Kami pertama kali menyadari masalah ini sekitar waktu masa berlaku sertifikat habis dan segera mulai mencari solusi.
Mengurangi kerusakan
Begitu kami menyadari apa yang terjadi, kami berusaha mencegah situasi menjadi lebih buruk.
Pertama, mereka berhenti menerima dan menandatangani tambahan baru. Tidak ada gunanya menggunakan sertifikat kadaluwarsa untuk ini. Melihat ke belakang, menurut saya kita bisa saja membiarkan semuanya apa adanya. Kami sekarang telah kembali menerima suplemen.
Kedua, mereka segera mengirimkan perbaikan yang mencegah pemeriksaan tanda tangan setiap hari. Oleh karena itu, kami menyelamatkan pengguna yang browsernya belum sempat memeriksa add-on dalam XNUMX jam terakhir. Perbaikan ini sekarang telah ditarik dan tidak diperlukan lagi.
Operasi paralel
Secara teori, solusi untuk masalah ini terlihat sederhana: buat sertifikat perantara baru yang valid dan tanda tangani ulang setiap add-on. Sayangnya ini tidak berhasil:
- kami tidak dapat dengan cepat menandatangani ulang 15 ribu add-on sekaligus, sistem tidak dirancang untuk beban seperti itu
- Setelah kami menandatangani penambahan, versi terbaru perlu dikirimkan ke pengguna. Sebagian besar add-on diinstal dari server Mozilla, sehingga Firefox akan menemukan pembaruan dalam waktu XNUMX jam ke depan, namun beberapa pengembang mendistribusikan add-on yang ditandatangani melalui saluran pihak ketiga, sehingga pengguna harus memperbarui add-on tersebut secara manual
Sebaliknya, kami mencoba mengembangkan perbaikan yang dapat menjangkau semua pengguna tanpa memerlukan banyak atau tanpa tindakan apa pun dari mereka.
Dengan cepat kami sampai pada dua strategi utama, yang kami gunakan secara paralel:
- Perbarui Firefox untuk mengubah masa berlaku sertifikat. Hal ini akan membuat add-on yang sudah ada berfungsi kembali secara ajaib, namun memerlukan rilis dan pengiriman versi baru Firefox
- Hasilkan sertifikat yang valid dan yakinkan Firefox untuk menerimanya, bukan sertifikat yang sudah kedaluwarsa
Kami memutuskan untuk menggunakan opsi pertama terlebih dahulu, yang tampaknya cukup bisa diterapkan. Pada akhirnya, mereka merilis perbaikan kedua (sertifikat baru), yang akan kita bicarakan nanti.
Mengganti sertifikat
Seperti yang saya sebutkan di atas, diperlukan:
- membuat sertifikat baru yang valid
- menginstalnya dari jarak jauh di Firefox
Untuk memahami mengapa ini berhasil, mari kita lihat lebih dekat proses verifikasi add-on. Add-on itu sendiri hadir sebagai sekumpulan file, termasuk rangkaian sertifikat yang digunakan untuk penandatanganan. Hasilnya, add-on tersebut dapat diverifikasi jika browser mengetahui sertifikat root, yang ada di dalam Firefox pada waktu pembuatan. Namun, seperti yang telah kita ketahui, sertifikat perantara telah kedaluwarsa, sehingga tidak mungkin untuk memverifikasi add-on tersebut.
Saat Firefox mencoba memverifikasi sebuah add-on, hal ini tidak terbatas pada penggunaan sertifikat yang ada di dalam add-on itu sendiri. Sebaliknya, browser mencoba membuat rantai sertifikat yang valid, dimulai dengan sertifikat akhir dan berlanjut hingga mencapai root. Pada tingkat pertama, kita mulai dengan sertifikat akhir dan kemudian menemukan sertifikat yang subjeknya adalah penerbit sertifikat akhir (yaitu sertifikat perantara). Biasanya sertifikat perantara ini disertakan dengan add-on, namun sertifikat apa pun dari penyimpanan browser juga dapat berfungsi sebagai sertifikat perantara ini. Jika kami dapat menambahkan sertifikat baru yang valid ke penyimpanan sertifikat dari jarak jauh, Firefox akan mencoba menggunakannya. Situasi sebelum dan sesudah pemasangan sertifikat baru.
Setelah menginstal sertifikat baru, Firefox akan memiliki dua opsi saat memvalidasi rantai sertifikat: menggunakan sertifikat lama yang tidak valid (yang tidak akan berfungsi) atau sertifikat baru yang valid (yang akan berfungsi). Sertifikat baru harus berisi nama subjek dan kunci publik yang sama dengan sertifikat lama, sehingga tanda tangannya pada sertifikat akhir akan valid. Firefox cukup pintar untuk mencoba kedua opsi tersebut hingga menemukan satu yang berfungsi, sehingga add-on tersebut diuji lagi. Perhatikan bahwa ini adalah logika yang sama yang kami gunakan untuk memvalidasi sertifikat TLS.
Catatan Penulis: Pembaca yang akrab dengan WebPKI akan mengetahui bahwa lintas-sertifikat bekerja dengan cara yang persis sama.
Hal hebat tentang perbaikan ini adalah Anda tidak perlu menandatangani ulang add-on yang ada. Segera setelah browser menerima sertifikat baru, semua add-on akan berfungsi kembali. Tantangan yang tersisa adalah memberikan sertifikat baru kepada pengguna (secara otomatis dan jarak jauh), serta meminta Firefox memeriksa ulang add-on yang dinonaktifkan.
Normandia dan sistem penelitiannya
Ironisnya, masalah ini diselesaikan dengan add-on khusus yang disebut “sistem”. Untuk melakukan penelitian, kami mengembangkan sistem yang disebut Normandia yang menyampaikan penelitian kepada pengguna. Studi ini dilakukan secara otomatis di browser, dan memiliki akses yang ditingkatkan ke API internal Firefox. Penelitian dapat menambahkan sertifikat baru ke penyimpanan sertifikat.
Catatan Penulis: Kami tidak menambahkan sertifikat dengan hak istimewa apa pun; itu ditandatangani oleh sertifikat root, jadi Firefox mempercayainya. Kita cukup menambahkannya ke kumpulan sertifikat yang dapat digunakan oleh browser.
Jadi solusinya adalah dengan membuat studi:
- menginstal sertifikat baru yang kami buat untuk pengguna
- memaksa browser untuk memeriksa ulang add-on yang dinonaktifkan agar berfungsi kembali
“Tapi tunggu,” Anda berkata, “add-on tidak berfungsi, bagaimana cara meluncurkan add-on sistem?” Ayo tandatangani dengan sertifikat baru!
Menyatukan semuanya...kenapa lama sekali?
Jadi rencananya: menerbitkan sertifikat baru untuk menggantikan yang lama, membuat add-on sistem dan menginstalnya ke pengguna melalui Normandia. Masalahnya, seperti yang saya katakan, dimulai pada tanggal 4 Mei pukul 4:00, dan sudah pada pukul 12:44 di hari yang sama, kurang dari 9 jam kemudian, kami mengirimkan perbaikan ke Normandia. Butuh waktu 6-12 jam lagi untuk menjangkau semua pengguna. Tidak buruk sama sekali, namun orang-orang di Twitter bertanya mengapa kami tidak bisa bertindak lebih cepat.
Pertama, perlu waktu untuk menerbitkan sertifikat perantara yang baru. Seperti yang saya sebutkan di atas, kunci sertifikat root disimpan secara offline di modul keamanan perangkat keras. Ini bagus dari sudut pandang keamanan, karena root sangat jarang digunakan dan harus dilindungi dengan andal, tetapi ini sedikit merepotkan ketika Anda harus segera menandatangani sertifikat baru. Salah satu teknisi kami harus melakukan perjalanan ke fasilitas penyimpanan HSM. Kemudian ada upaya yang gagal untuk menerbitkan sertifikat yang benar, dan setiap upaya memerlukan waktu satu atau dua jam untuk pengujian.
Kedua, pengembangan add-on sistem memerlukan waktu. Secara konseptual ini sangat sederhana, tetapi program sederhana pun memerlukan kehati-hatian. Kami ingin memastikan bahwa kami tidak memperburuk situasi. Penelitian perlu diuji sebelum dikirim ke pengguna. Selain itu, add-on harus ditandatangani, tetapi sistem penandatanganan add-on kami dinonaktifkan, jadi kami harus mencari solusinya.
Terakhir, setelah penelitian kami siap untuk diserahkan, penerapannya membutuhkan waktu. Browser memeriksa pembaruan Normandia setiap 6 jam. Tidak semua komputer selalu hidup dan terhubung ke Internet, sehingga perlu waktu agar perbaikan dapat menyebar ke pengguna.
Langkah terakhir
Penelitian ini seharusnya memperbaiki masalah bagi sebagian besar pengguna, namun tidak tersedia untuk semua orang. Beberapa pengguna memerlukan pendekatan khusus:
- pengguna yang telah menonaktifkan penelitian atau telemetri
- pengguna versi Android (Fennec), dimana penelitian tidak didukung sama sekali
- pengguna versi khusus Firefox ESR di perusahaan yang telemetrinya tidak dapat diaktifkan
- pengguna yang duduk di belakang proxy MitM, karena sistem instalasi add-on kami menggunakan penyematan kunci, yang tidak berfungsi dengan proxy tersebut
- pengguna Firefox versi lama yang tidak mendukung penelitian
Kami tidak dapat melakukan apa pun terhadap kategori pengguna yang terakhir - mereka tetap harus memperbarui ke versi baru Firefox, karena versi lama memiliki kerentanan serius yang belum ditambal. Kami tahu bahwa beberapa orang tetap menggunakan Firefox versi lama karena ingin menjalankan add-on lama, namun banyak dari add-on lama telah di-porting ke versi browser yang lebih baru. Untuk pengguna lain, kami telah mengembangkan patch yang akan menginstal sertifikat baru. Itu dirilis sebagai rilis perbaikan bug (catatan penerjemah: Firefox 66.0.5), sehingga orang akan mendapatkannya - kemungkinan besar sudah mendapatkannya - melalui saluran pembaruan rutin. Jika Anda menggunakan Firefox ESR versi khusus, harap hubungi pengelola Anda.
Kami memahami bahwa ini tidak ideal. Dalam beberapa kasus, pengguna kehilangan data tambahan (misalnya, data tambahan Penampung Multi-Akun).
Efek samping ini tidak dapat dihindari, namun kami yakin bahwa dalam jangka pendek kami telah memilih solusi terbaik bagi sebagian besar pengguna. Dalam jangka panjang, kami akan mencari pendekatan arsitektur lain yang lebih maju.
Pelajaran
Pertama, tim kami melakukan pekerjaan luar biasa dalam membuat dan mengirimkan perbaikan dalam waktu kurang dari 12 jam setelah masalah ditemukan. Sebagai seseorang yang menghadiri pertemuan tersebut, saya dapat mengatakan bahwa dalam situasi sulit ini orang-orang bekerja sangat keras dan sangat sedikit waktu yang terbuang.
Tentu saja semua ini tidak seharusnya terjadi. Jelas ada gunanya menyesuaikan proses kami untuk mengurangi kemungkinan terjadinya insiden semacam itu dan mempermudah remediasi.
Minggu depan kami akan menerbitkan hasil otopsi resmi dan daftar perubahan yang ingin kami lakukan. Untuk saat ini, saya akan membagikan pemikiran saya. Pertama, harus ada cara yang lebih baik untuk memantau status potensi bom waktu. Kita perlu memastikan bahwa kita tidak berada dalam situasi di mana salah satu dari mereka tiba-tiba berhasil. Kami masih mengerjakan detailnya, tapi minimal, semua hal seperti itu perlu diperhitungkan.
Kedua, kita memerlukan mekanisme yang dapat memberikan pembaruan dengan cepat kepada pengguna, bahkan ketika—terutama ketika—semua hal lainnya gagal. Sangat menyenangkan bahwa kami dapat menggunakan sistem "penelitian", tetapi ini adalah alat yang tidak sempurna dan memiliki beberapa efek samping yang tidak diinginkan. Secara khusus, kami mengetahui bahwa banyak pengguna yang mengaktifkan pembaruan otomatis, namun memilih untuk tidak berpartisipasi dalam penelitian (saya akui, saya juga menonaktifkannya!). Pada saat yang sama, kami memerlukan cara untuk mengirimkan pembaruan kepada pengguna, tetapi apa pun penerapan teknis internalnya, pengguna harus dapat berlangganan pembaruan (termasuk perbaikan terbaru) tetapi memilih untuk tidak ikut serta dalam hal lainnya. Selain itu, saluran pembaruan harus lebih responsif dibandingkan sekarang. Bahkan pada tanggal 6 Mei, masih ada pengguna yang tidak memanfaatkan perbaikan atau versi baru. Masalah ini telah diatasi, namun apa yang terjadi menunjukkan betapa pentingnya masalah ini.
Terakhir, kita akan melihat lebih dekat arsitektur keamanan add-on untuk memastikan add-on tersebut memberikan tingkat keamanan yang tepat dengan risiko minimal terhadap kerusakan apa pun.
Minggu depan kita akan melihat hasil analisis yang lebih menyeluruh atas apa yang terjadi, namun sementara itu saya akan dengan senang hati menjawab pertanyaan melalui email: [email dilindungi]
Sumber: linux.org.ru