Rincian Teknis Kerusakan Ekstensi Firefox Terbaru

Tentang penulis. Eric Rescorla - Direktur Teknis, Firefox Group di Mozilla

Baru-baru ini, sebuah insiden terjadi di Firefox ketika sebagian besar add-on (ekstensi, add-on) berhenti berfungsi. Ini karena kesalahan pada bagian kami: kami tidak melihat bahwa salah satu sertifikat, yang digunakan untuk menandatangani add-ons, telah kedaluwarsa, yang telah menyebabkan terputusnya sebagian besar dari mereka. Sekarang kami telah memperbaiki masalah dan sebagian besar add-on telah dipulihkan, saya ingin memberi tahu secara rinci apa yang terjadi, mengapa dan bagaimana kami memperbaikinya.

Untuk referensi: ekstensi dan tanda tangannya

Meskipun banyak menggunakan Firefox seperti yang ada di luar kotak, browser juga mendukung mekanisme ekstensi yang kuat. Mereka menambahkan fitur pihak ketiga ke Firefox yang memperluas fitur yang kami tawarkan secara default. Saat ini terdapat lebih dari 15.000 pengaya Firefox: dari pemblokiran iklan hingga mengelola ratusan tab .

Firefox mengharuskan semua add-on yang terinstal ditandatangani secara digital . Persyaratan ini dimaksudkan untuk melindungi pengguna dari ekstensi jahat dengan mengharuskan standar verifikasi minimum oleh karyawan Mozilla. Sebelum kami memperkenalkan persyaratan ini pada 2015, kami memiliki masalah serius dengan ekstensi jahat.

Tanda tangan bekerja melalui "sertifikat root" Firefox yang telah diinstal sebelumnya. Itu disimpan offline dalam modul keamanan perangkat keras (HSM) . Setiap beberapa tahun, digunakan untuk menandatangani "sertifikat perantara" yang baru, yang disimpan secara online dan digunakan dalam proses penandatanganan. Ketika ekstensi diajukan untuk ditandatangani, kami membuat "sertifikat entitas akhir" sementara yang baru dan menandatanganinya dengan sertifikat perantara. Sertifikat tujuan kemudian digunakan untuk menandatangani ekstensi. Secara visual, tampilannya seperti ini:



Harap dicatat bahwa setiap sertifikat memiliki "subjek" (milik sertifikat) dan "penerbit" (penandatangan). Dalam hal sertifikat root, ini adalah satu dan sama, tetapi untuk sertifikat lain, penerbit adalah subjek yang menandatanganinya.

Poin penting di sini adalah bahwa setiap add-on ditandatangani dengan sertifikat sendiri untuk objek final, tetapi hampir semua add-on memiliki sertifikat perantara yang sama (beberapa add-on yang sangat lama ditandatangani oleh tautan perantara lain). Di sinilah masalahnya muncul: setiap sertifikat memiliki tanggal kedaluwarsa yang tetap. Sebelum atau setelah jendela ini, sertifikat tidak akan diterima, dan ekstensi yang ditandatangani oleh sertifikat ini tidak dapat diunggah ke Firefox. Sayangnya, sertifikat perantara yang kami gunakan kedaluwarsa pada 4 Mei setelah 1:00 UTC, dan segera setiap add-on yang ditandatangani oleh sertifikat ini menjadi tidak terverifikasi dan tidak dapat diunggah ke Firefox.

Meskipun semua add-on berakhir sekitar pukul satu pagi, konsekuensinya tidak segera terasa. Alasannya adalah bahwa Firefox tidak selalu memeriksa validitas pengaya. Mereka diperiksa kira-kira setiap 24 jam, dan waktu verifikasi berbeda untuk setiap pengguna. Akibatnya, beberapa orang langsung mengalami masalah, beberapa di kemudian hari. Kami di Mozilla pertama kali mengetahui tentang masalah sekitar pukul 6:00 malam. PST pada hari Jumat 3 Mei dan segera membentuk tim untuk memperbaiki situasi.

Batas kerusakan

Segera setelah kami memahami apa yang kami hadapi, kami mengambil beberapa langkah untuk menghindari memburuknya situasi.

Pertama, kami mematikan penandatanganan penambahan baru. Pada saat itu wajar, karena tanda tangan meletakkan sertifikat yang tidak valid. Melihat ke belakang, tampaknya mungkin untuk meninggalkan fungsi ini, tetapi ternyata itu juga bertentangan dengan pelunakan "hard date firmware", yang akan kita bahas di bawah ini (walaupun pada akhirnya kami tidak menggunakannya). Karena itu, ada baiknya kami mempertahankan opsi ini. Jadi, penandatanganan penambahan baru sekarang ditunda.

Kedua, kami segera merilis perbaikan cepat yang menekan verifikasi ulang tanda tangan ekstensi. Idenya adalah untuk melindungi pengguna yang belum diuji ulang. Kami melakukan ini sebelum kami memiliki perbaikan lain, dan sekarang dihapus ketika perbaikan tersedia.

Pekerjaan paralel

Secara teoritis, solusi untuk masalah ini terlihat sederhana: buat sertifikat baru yang valid dan diterbitkan ulang setiap tambahan dengan sertifikat ini. Sayangnya, kami dengan cepat menentukan bahwa ini tidak akan berhasil karena sejumlah alasan:

1. Ada banyak ekstensi (lebih dari 15.000), dan layanan ini tidak dioptimalkan untuk penandatanganan massal, jadi hanya dengan menandatangani ulang setiap add-on akan membutuhkan waktu lebih lama daripada yang kami inginkan.
   
2. Setelah pengaya ditandatangani, pengguna perlu mendapatkan pengaya baru. Beberapa di-host di server Mozilla, dan Firefox akan memperbaruinya dalam waktu 24 jam, tetapi pengguna harus memperbarui secara manual semua pengaya yang diinstal dari sumber lain, yang sangat merepotkan.

Alih-alih, kami fokus untuk mencoba mengembangkan perbaikan yang akan memperbaiki situasi dengan sedikit atau tanpa intervensi manual dari pengguna.

Setelah mempertimbangkan sejumlah pendekatan, kami dengan cepat menyetujui dua strategi utama yang kami lakukan secara paralel:

1. Patch Firefox untuk mengubah tanggal yang digunakan untuk memverifikasi sertifikat. Dalam hal ini, add-on yang ada secara ajaib akan berfungsi kembali, tetapi pengiriman versi baru Firefox akan diperlukan.
   
2. Buat sertifikat baru yang valid dan entah bagaimana meyakinkan Firefox untuk menerimanya alih-alih yang sudah kadaluwarsa.

Kami tidak yakin apa yang akan bekerja, jadi kami memutuskan untuk melakukan pekerjaan secara paralel dan mengimplementasikan yang pertama, yang akan terlihat seperti solusi yang berfungsi. Pada akhir hari, kami menyelesaikan penyebaran perbaikan kedua - sertifikat baru, yang akan saya jelaskan lebih terinci.

Sertifikat pengganti

Seperti disebutkan di atas, ada dua langkah utama yang harus diikuti:

1. Buat sertifikat baru yang valid.
   
2. Instal dari jarak jauh di Firefox.

Untuk memahami mengapa ini bekerja, Anda perlu tahu lebih banyak tentang cara Firefox memeriksa add-on. Add-on itu sendiri datang dalam bentuk paket file, yang mencakup rantai sertifikat yang digunakan untuk menandatanganinya. Akibatnya, addon diperiksa secara independen jika sertifikat root diketahui, yang dikonfigurasikan di Firefox selama pembuatan. Namun, seperti yang saya katakan, sertifikat perantara rusak, jadi add-on itu tidak benar-benar dapat diverifikasi.

Tetapi ternyata ketika Firefox mencoba memverifikasi ekstensi, itu tidak terbatas pada hanya menggunakan sertifikat dalam ekstensi itu sendiri. Sebagai gantinya, ia mencoba untuk membuat rantai sertifikat yang valid, mulai dengan sertifikat titik akhir dan melanjutkan ke direktori root. Algoritma ini kompleks, tetapi pada tingkat tinggi, Anda mulai dengan sertifikat objek akhir, dan kemudian menemukan sertifikat yang subjeknya sama dengan penerbit sertifikat objek akhir (mis., Sertifikat perantara). Dalam kasus sederhana, ini hanya tautan perantara yang dilengkapi dengan add-in, tetapi ini bisa berupa sertifikat apa pun yang diketahui peramban. Jika kami dapat menambahkan sertifikat baru yang valid dari jarak jauh, Firefox juga akan mencoba membuat rantai seperti itu. Gambar di bawah ini menunjukkan situasi sebelum dan sesudah memasang sertifikat baru.



Setelah memasang sertifikat baru, Firefox memiliki dua opsi untuk memeriksa rantai sertifikat: gunakan sertifikat lama yang tidak valid (yang tidak akan berfungsi) atau gunakan sertifikat baru yang valid (yang akan berfungsi). Fitur penting di sini adalah bahwa sertifikat baru memiliki nama subjek dan kunci publik yang sama dengan sertifikat lama, sehingga tanda tangannya pada sertifikat objek akhir valid. Untungnya, Firefox cukup pintar untuk mencoba kedua metode hingga menemukan yang berfungsi, sehingga ekstensi menjadi valid kembali. Harap perhatikan bahwa ini adalah logika yang sama yang kami gunakan untuk memverifikasi sertifikat TLS, jadi ini adalah kode yang relatif dipahami dengan baik yang dapat kami gunakan (pembaca yang akrab dengan WebPKI akan memahami bahwa sertifikasi silang bekerja dengan cara ini).

Hal terbaik tentang perbaikan ini adalah tidak memerlukan perubahan pada ekstensi yang ada. Saat kami memasang sertifikat baru di Firefox, bahkan ekstensi dengan sertifikat lama akan lulus ujian. Trik untuk memberikan sertifikat baru di Firefox adalah dengan melakukannya secara otomatis dan jarak jauh, dan kemudian minta Firefox memeriksa ulang semua ekstensi yang mungkin telah dinonaktifkan.

Normandia dan sistem penelitian

Ironisnya, solusi untuk masalah ini adalah jenis ekstensi khusus yang disebut sistem add-on (SAO). Untuk studi tentang audiens (Studi), kami sebelumnya mengembangkan sistem yang disebut Normandy, yang dapat mengirimkan SAO ke pengguna Firefox. SAO ini dijalankan secara otomatis di browser pengguna. Meskipun mereka biasa digunakan untuk eksperimen, mereka juga memiliki akses luas ke API internal di Firefox. Dalam hal ini, penting bahwa mereka dapat menambahkan sertifikat baru ke basis data sertifikat yang digunakan Firefox untuk memeriksa ekstensi (catatan teknis: kami tidak menambahkan sertifikat dengan hak istimewa khusus; ia mendapatkan hak istimewa dengan menandatangani dengan sertifikat root. Kami hanya menambahkannya ke kumpulan sertifikat yang dapat digunakan Firefox, jadi kami tidak menambahkan sertifikat khusus di Firefox).

Jadi, solusinya di sini adalah membuat SAO yang melakukan dua hal:

1. Pasang sertifikat baru yang kami buat.
   
2. Menyebabkan browser memeriksa ulang setiap add-on untuk mengaktifkan yang telah terputus.

Tapi tunggu, katamu. Pengaya tidak berfungsi, jadi bagaimana membuat SAO berfungsi? Baiklah, kami akan menandatanganinya dengan sertifikat baru!

Menyatukan semuanya ... dan mengapa begitu lama?

Jadi sekarang kami memiliki rencana: untuk mengeluarkan sertifikat baru untuk menggantikan yang lama, membangun sistem tambahan untuk menginstalnya di Firefox, dan menyebarkannya ke Normandy. Kami mulai bekerja sekitar pukul 6:00 malam PST pada hari Jumat 3 Mei, dan mengirimkan tambalan ke Normandy sekitar pukul 02:44 pagi, yaitu kurang dari 9 jam, dan kemudian butuh 6-12 jam lagi sebelum sebagian besar pengguna menerimanya. Ini sebenarnya awal yang sangat baik, tetapi saya melihat di Twitter serangkaian pertanyaan, mengapa kami tidak bisa melakukannya lebih cepat. Ada sejumlah langkah yang memakan waktu.

Pertama, butuh beberapa waktu untuk mengeluarkan sertifikat perantara baru. Seperti yang saya sebutkan di atas, sertifikat root terletak di modul keamanan perangkat keras, yang disimpan secara offline. Ini adalah praktik keamanan yang baik, karena Anda jarang menggunakan sertifikat root, dan karenanya ingin tetap aman. Tapi jelas, ini agak merepotkan ketika Anda perlu mengeluarkan sertifikat baru dalam keadaan darurat. Bagaimanapun, salah satu teknisi kami harus pergi ke tempat yang aman di mana HSM disimpan. Lalu ada beberapa awal yang salah, ketika kami tidak dapat mengeluarkan sertifikat yang benar, dan setiap upaya bernilai satu atau dua jam pengujian, sebelum kami tahu persis apa yang harus dilakukan.

Kedua, pengembangan sistem membutuhkan waktu. Secara konseptual, semuanya sangat sederhana, tetapi bahkan program sederhana pun perlu diwaspadai, dan kami benar-benar ingin memastikan bahwa kami tidak memperburuk situasi. Dan sebelum mengirim SAO, perlu untuk mengujinya, dan ini membutuhkan waktu, terutama mengingat bahwa itu perlu ditandatangani. Tetapi sistem tanda tangan dinonaktifkan, jadi kami harus mencari solusi.

Akhirnya, begitu SAO siap untuk dikirim, perlu beberapa saat untuk ditempatkan. Klien Firefox memeriksa pembaruan Normandia setiap 6 jam, dan, tentu saja, banyak klien sedang luring, sehingga mendistribusikan pembaruan ke semua pengguna Firefox tidak instan. Namun, saat ini, sebagian besar telah menerima pembaruan dan / atau rilis baru, yang kami rilis kemudian.

Langkah terakhir

Meskipun addon sistem, yang digunakan melalui sistem Studi, harus memperbaiki situasi bagi sebagian besar pengguna, itu tidak menjangkau semua orang. Secara khusus, beberapa jenis pengguna memerlukan pendekatan yang berbeda:

• Pengguna yang telah menonaktifkan telemetri atau penelitian.
  
• Pengguna Firefox untuk Android (Fennec), tempat kami tidak melakukan penelitian.
  
• Pengguna versi Firefox ESR berikutnya yang tidak berlangganan laporan telemetri.
  
• Pengguna yang berada di belakang proksi HTTPS MiTM, karena sistem instalasi tambahan kami memaksa kunci untuk koneksi ini, yang bertentangan dengan proksi.
  
• Pengguna Firefox yang sudah sangat tua, yang tidak dapat dijangkau oleh sistem Studi.

Kami tidak dapat melakukan apa pun dengan grup terakhir - mereka harus memutakhirkan ke versi baru Firefox, karena versi yang lebih lama biasanya memiliki kerentanan keamanan yang belum ditambal yang cukup serius. Kita tahu bahwa beberapa orang tetap menggunakan Firefox versi lama karena mereka ingin menjalankan ekstensi gaya lama, tetapi banyak dari mereka sekarang bekerja dengan versi Firefox yang lebih baru. Untuk grup lain, kami mengembangkan tambalan untuk Firefox yang akan memasang sertifikat baru setelah peningkatan. Itu juga dirilis sebagai versi baru dari Firefox "bertitik", jadi orang harus mendapatkannya - dan mungkin sudah menerimanya - melalui saluran pembaruan reguler. Jika Anda memiliki bangunan hilir, Anda harus menunggu pembaruan dari pengelola.

Kami mengakui bahwa semua ini tidak sempurna. Secara khusus, dalam beberapa kasus, pengguna kehilangan data yang terkait dengan add-on (misalnya, ekstensi seperti "wadah dengan banyak akun" ).

Kami tidak dapat mengembangkan tambalan yang menghindari efek samping ini, tetapi kami percaya bahwa dalam jangka pendek ini adalah pendekatan terbaik untuk sebagian besar pengguna. Dalam jangka panjang, kami akan mencari pendekatan arsitektur terbaik untuk menyelesaikan masalah tersebut.

Pelajaran

Pertama, saya ingin mengatakan bahwa tim melakukan pekerjaan yang luar biasa di sini: mereka mengembangkan dan mengirim perbaikan dalam waktu kurang dari 12 jam dari saat laporan awal. Sebagai orang yang menghadiri pertemuan di mana ini terjadi, saya dapat mengatakan bahwa orang bekerja sangat keras dalam situasi yang sulit dan sangat sedikit waktu yang terbuang.

Mengingat ini, jelas bahwa ini bukan situasi yang ideal, dan ini seharusnya tidak terjadi sama sekali. Kami jelas perlu menyesuaikan proses kami untuk mengurangi kemungkinan ini dan insiden serupa dan untuk memfasilitasi koreksi mereka.

Minggu depan kita akan melakukan pembekalan formal dan menerbitkan daftar perubahan yang ingin kita buat, tetapi untuk sekarang, inilah pemikiran awal saya tentang hal ini. Yang terpenting, kita harus memiliki cara yang jauh lebih baik untuk memantau status semua sistem di Firefox yang berpotensi menjadi bom waktu. Anda perlu memastikan bahwa tidak satu pun dari mereka yang tiba-tiba berhenti bekerja. Kami masih mengerjakan perincian di sini, tetapi setidaknya kami perlu melakukan inventarisasi sistem tersebut.

Kedua, kita membutuhkan mekanisme untuk memperbarui pengguna dengan cepat, bahkan ketika - terutama ketika - segala sesuatu yang lain tidak berfungsi. Sangat bagus bahwa kami dapat menggunakan sistem Studi, tetapi itu juga bukan alat yang paling sempurna yang kami operasikan, dan yang memiliki beberapa efek samping yang tidak diinginkan. Secara khusus, kita tahu bahwa banyak pengguna mengaktifkan pembaruan otomatis, tetapi mereka lebih suka untuk tidak berpartisipasi dalam penelitian, dan ini adalah preferensi yang masuk akal (untuk mengatakan apa-apa, saya mengatur browser dengan cara ini!), Tetapi pada saat yang sama, kita harus dapat mendorong pembaruan. Apa pun mekanisme teknis internal, pengguna harus dapat memilih pembaruan (termasuk perbaikan), tetapi mengabaikan yang lainnya. Selain itu, saluran pembaruan harus lebih cepat. Bahkan pada hari Senin, kami masih memiliki pengguna yang tidak mengambil perbaikan atau rilis baru, yang jelas tidak sempurna. Kami sudah mengatasi masalah ini, tetapi kejadian ini menunjukkan betapa pentingnya masalah ini.

Akhirnya, kita akan melihat lebih umum pada arsitektur keamanan ekstensi kami untuk memastikan bahwa ia memberikan keamanan dengan benar dengan risiko kegagalan yang minimal.

Minggu depan kami akan mempublikasikan hasil analisis yang lebih menyeluruh tentang situasi ini.