Технически подробности за скорошното деактивиране на добавките на Firefox

Забележка. преводач: за удобство на читателите датите са дадени в московско време

Наскоро пропуснахме датата на изтичане на един от сертификатите, използвани за подписване на добавки. Това доведе до деактивиране на добавките за потребителите. Сега, когато по-голямата част от проблема е отстранен, бих искал да споделя подробности за случилото се и свършената работа.

Фон: допълнения и подписи

Докато мнозина използват браузъра веднага, Firefox поддържа разширения, наречени „добавки“. С тяхна помощ потребителите добавят различни функции към браузъра. Има над 15 хиляди допълнения: от блокиране на реклами до управление на стотици раздели.

Трябва да има инсталирани добавки цифров подпис, който защитава потребителите от злонамерени добавки и изисква минимален преглед на добавките от служители на Mozilla. Въведохме това изискване през 2015 г., докато тествахме сериозни проблеми със злонамерени разширения.

Как работи: Всяко копие на Firefox съдържа "главен сертификат". Ключът към този "корен" се съхранява в Модул за хардуерна сигурност (HSM)който няма достъп до мрежата. На всеки няколко години с този ключ се подписва нов "междинен сертификат", който се използва при подписване на добавки. Когато разработчик изпрати добавка, ние създаваме временен „краен сертификат“ и го подписваме с помощта на междинния сертификат. След това самата добавка се подписва от крайния сертификат. схематично изглежда така.

Обърнете внимание, че всеки сертификат има "субект" (на когото е издаден сертификатът) и "издател" (който е издал сертификата). В случай на основен сертификат, "subject" = "issuer", но за други сертификати, издателят на сертификат е субектът на родителския сертификат, който го е подписал.

Важен момент: всяко добавяне се подписва от уникален краен сертификат, но почти винаги тези крайни сертификати се подписват от един и същ междинен сертификат.

Бележка на автора: Изключение правят много старите допълнения. По това време се използват различни междинни сертификати.

Този междинен сертификат създава проблеми: всеки сертификат е валиден за определен период. Преди или след този период сертификатът е невалиден и браузърът няма да използва добавки, подписани с този сертификат. За съжаление временният сертификат изтече на 4 май в 4:XNUMX сутринта.

Последствията не се появиха веднага. Firefox проверява подписите на инсталираните добавки не през цялото време, а приблизително веднъж на всеки 24 часа, като времето за проверка е индивидуално за всеки потребител. В резултат на това някои хора имат проблеми веднага, други много по-късно. За първи път разбрахме за проблема около времето, когато сертификатът изтече и веднага започнахме да търсим решение.

Ние намаляваме щетите

След като разбрахме какво се е случило, се опитахме да предотвратим влошаване на ситуацията.

Първо спряха да приемат и подписват нови попълнения. Няма смисъл да използвате изтекъл сертификат за това. Поглеждайки назад, бих казал, че би било възможно да оставим всичко както е. Сега приемането на допълнения е възобновено.

Второ, те незабавно изпратиха корекция, която предотвратява ежедневната проверка на подписите. Така спасихме онези потребители, чийто браузър не е имал време да провери добавките през последните XNUMX часа. Тази корекция вече е оттеглена и вече не е необходима.

Паралелна работа

Теоретично решението на проблема изглежда просто: създайте нов валиден междинен сертификат и преподпишете всяко добавяне. За съжаление това няма да работи:

• не можем бързо да преподпишем 15 XNUMX добавки наведнъж, системата не е проектирана за такова натоварване
• след като подпишем допълненията, актуализираните версии трябва да бъдат доставени на потребителите. Повечето добавки се инсталират от сървърите на Mozilla, така че Firefox ще намери актуализации през следващите XNUMX часа, но някои разработчици разпространяват подписани добавки чрез канали на трети страни, така че потребителите ще трябва да актуализират тези добавки ръчно

Вместо това се опитахме да разработим корекция, която да достигне до всички потребители с малко или никакво действие от тяхна страна.

Доста бързо измислихме две основни стратегии, които използвахме паралелно:

• Актуализирайте Firefox, за да промените периода на валидност на сертификата. Това ще накара съществуващите добавки магически да работят отново, но ще изисква нова версия на Firefox да бъде пусната и изпратена.
• Генерирайте валиден сертификат и по някакъв начин убедете Firefox да го приеме вместо изтекъл съществуващ

Решихме първо да използваме първата опция, която изглежда работеше доста добре. В края на деня беше пусната и втората корекция (нов сертификат), за която ще говорим по-късно.

Подмяна на сертификат

Както споменах по-горе, изискваше се:

• създайте нов валиден сертификат
• инсталирайте го дистанционно във Firefox

За да разберем защо това ще работи, нека разгледаме по-подробно процеса на валидиране на добавките. Самата добавка идва като набор от файлове, включително верига от сертификати, използвани за подписване. В резултат на това добавката може да бъде проверена, ако браузърът знае основния сертификат, който е вграден във Firefox по време на изграждане. Въпреки това, както вече знаем, междинният сертификат е изтекъл, така че не е възможно да проверите добавката.

Когато Firefox се опитва да потвърди добавка, това не се ограничава до използването на сертификатите, съдържащи се в самата добавка. Вместо това браузърът се опитва да изгради валидна верига от сертификати, започвайки с крайния сертификат и продължавайки, докато стигне до корена. На първо ниво започваме с листовия сертификат и след това намираме сертификата, чийто предмет е издателят на листовия сертификат (т.е. междинния сертификат). Обикновено този междинен сертификат идва с добавката, но всеки сертификат от хранилището на браузъра може също да действа като този междинен сертификат. Ако можем дистанционно да добавим нов валиден сертификат към хранилището на сертификати, Firefox ще се опита да го използва. Ситуация преди и след инсталиране на нов сертификат.

След като новият сертификат бъде инсталиран, Firefox ще има две опции при проверка на веригата от сертификати: използване на стария невалиден сертификат (който няма да работи) или новия валиден (който ще работи). Важно е новият сертификат да съдържа същото име на субект и публичен ключ като стария сертификат, така че неговият подпис върху окончателния сертификат ще бъде валиден. Firefox е достатъчно умен, за да изпробва и двете, докато намери тази, която работи, така че добавките ще бъдат проверени отново. Имайте предвид, че това е същата логика, която използваме за валидиране на TLS сертификати.

Бележка на автора: Читателите, запознати с WebPKI, ще забележат, че кръстосаните сертификати работят по същия начин.

Страхотното при тази корекция е, че не изисква да подписвате отново съществуващи добавки. Веднага след като браузърът получи нов сертификат, всички добавки ще работят отново. Остава предизвикателството да се предостави нов сертификат на потребителите (автоматично и отдалечено), както и да се накара Firefox да провери отново деактивираните добавки.

Нормандия и изследователската система

По ирония на съдбата този проблем се решава от специална добавка, наречена "система". За да провеждаме изследвания, ние разработихме система, наречена Normandy, която предоставя изследвания на потребителите. Тези изследвания се извършват автоматично в браузъра и имат подобрен достъп до вътрешните API на Firefox. Проучването може да добави нови сертификати към хранилището на сертификати.

Бележка на автора: Ние не добавяме сертификат с никакви специални привилегии; подписан е с основен сертификат, така че Firefox му се доверява. Ние просто го добавяме към пула от сертификати, които могат да се използват от браузъра.

Така че решението е да създадете проучване:

• който инсталира новия сертификат, който създадохме за потребителите
• принуждавайки браузъра да проверява отново деактивираните добавки, така че да работят отново

„Но чакайте“, казвате вие, „добавките не работят, как да стартирам системната добавка?“ Нека го подпишем с нов сертификат!

Като съберем всичко заедно… защо отнема толкова време?

И така, планът е да се издаде нов сертификат, който да замени стария, да се създаде системна добавка и да се инсталира на потребителите през Normandy. Проблемите, както казах, започнаха на 4 май в 4:00, а още в 12:44 на същия ден, по-малко от 9 часа по-късно, изпратихме фикс в Нормандия. Отне още 6-12 часа, за да достигне до всички потребители. Вече не е лошо, но потребителите на Twitter питат защо не сме могли да действаме по-бързо.

Първо, издаването на нов междинен сертификат отне време. Както споменах по-горе, ключът от основния сертификат се съхранява офлайн в хардуерния модул за сигурност. Това е добре от гледна точка на сигурността, тъй като коренът се използва рядко и трябва да бъде защитен, но е малко неудобно, когато трябва спешно да подпишете нов сертификат. Един от нашите инженери трябваше да отиде до хранилището на HSM. След това имаше неуспешни опити за издаване на правилния сертификат и всеки опит струваше един или два часа, прекарани в тестване.

Второ, разработването на системна добавка отне известно време. Концептуално е много проста, но дори простите програми изискват внимание. Искахме да сме сигурни, че няма да влошим нещата. Изследването трябва да бъде тествано, преди да бъде изпратено на потребителите. Освен това добавката трябва да бъде подписана, но нашата система за подписване на добавки беше деактивирана, така че трябваше да потърсим заобиколно решение.

Накрая, след като подготвихме проучванията за изпращане, отне време за внедряване. Браузърът проверява за актуализации на Normandy на всеки 6 часа. Не всички компютри са постоянно включени и свързани с интернет, така че отнема време, докато корекцията се разпространи сред потребителите.

Последни стъпки

Изследването трябва да реши проблема за повечето потребители, но не е достъпно за всички. Някои потребители изискват специален подход:

• потребители, които са изключили изследванията или телеметрията
• потребители на версията за Android (Fennec), където изследванията изобщо не се поддържат
• потребители на персонализирани компилации на Firefox ESR в предприятия, където телеметрията не може да бъде активирана
• потребители, които седят зад MitM проксита, тъй като нашата система за инсталиране на добавки използва фиксиране на ключове, което не работи с такива проксита
• потребители на по-стари версии на Firefox, които не поддържат проучване

Не можем да направим нищо за последната категория потребители - те все още трябва да надстроят до новата версия на Firefox, защото остарелите имат сериозни неотстранени уязвимости. Знаем, че някои хора остават на по-стари версии на Firefox, защото искат да стартират по-стари добавки, но много от по-старите добавки вече са пренесени в нови версии на браузъра. За други потребители разработихме корекция, която ще инсталира нов сертификат. Беше пуснат като издание с корекция на грешки (бележка на преводача: Firefox 66.0.5), така че хората ще го получат - най-вероятно вече са го получили - чрез нормалния канал за актуализиране. Ако използвате персонализирана компилация на Firefox ESR, моля, свържете се с вашия поддържащ.

Разбираме, че това не е идеално. В някои случаи потребителите са загубили данни за добавки (например данни за добавки Контейнери с няколко акаунта).

Този страничен ефект не може да бъде избегнат, но ние вярваме, че в краткосрочен план сме избрали най-доброто решение за повечето потребители. В дългосрочен план ще търсим други, по-модерни архитектурни подходи.

Уроците

Първо, нашият екип свърши страхотна работа по създаването и изпращането на корекция за по-малко от 12 часа от откриването на проблема. Като човек, присъствал на срещите, мога да кажа, че в тази тежка ситуация хората работиха много здраво и много малко време се губеше.

Очевидно това изобщо не е трябвало да се случи. Очевидно си струва да коригираме нашите процеси, за да намалим вероятността от подобни инциденти и да улесним коригирането на последствията.

Следващата седмица ще публикуваме официална аутопсия и списък с промените, които възнамеряваме да направим. Засега ще споделя моите мисли. Първо, трябва да има по-добър начин за проследяване на състоянието на това, което е потенциална бомба със закъснител. Трябва да сме сигурни, че няма да се окажем в ситуация, в която някой от тях внезапно работи. Все още работим върху подробностите, но като минимум трябва да отчетем всички тези неща.

Второ, имаме нужда от механизъм за бързо доставяне на актуализации на потребителите, дори когато - особено когато - всичко останало не работи. Беше страхотно, че успяхме да използваме системата за „изследване“, но тя не е перфектен инструмент и има някои нежелани странични ефекти. По-специално знаем, че много потребители имат включени автоматични актуализации, но предпочитат да не участват в проучване (признавам, че и аз съм ги изключил!). В същото време се нуждаем от начин да изпращаме актуализации на потребителите, но независимо от вътрешната техническа реализация, потребителите трябва да могат да се абонират за актуализации (включително горещи корекции), но да се откажат от всичко останало. Освен това каналът за актуализация трябва да е по-отзивчив, отколкото е сега. Дори на 6 май все още имаше потребители, които не са се възползвали нито от корекцията, нито от новата версия. По този проблем вече се работи, но случилото се показа колко е важен.

И накрая, ще разгледаме архитектурата за сигурност на добавките, за да сме сигурни, че осигурява правилното ниво на сигурност с минимален риск от счупване на нещо.

Следващата седмица ще разгледаме резултатите от по-задълбочен анализ на случилото се, но междувременно ще се радвам да отговарям на въпроси по имейл: [имейл защитен]

Източник: linux.org.ru