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

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

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

Контекст: разширения и подписи

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

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

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

Обърнете внимание: всеки сертификат има „субект“ (кому е издаден сертификатът) и „издател“ (кой е издал сертификата). В случая на кореновия сертификат „субектът“ = „издателя“, но за другите сертификати издателят на сертификата е субектът на по-висшия сертификат, който го подписва.

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

Забележка на автора: изключение правят много стари дополнения. В това време бяха използвани различни междинни сертификати.

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

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

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

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

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

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

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

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

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

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

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

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

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

Смяна на сертификата

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

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

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

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

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

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

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

Normandy и системата за изследвания

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

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

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

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

"Но изчакайте", ще кажете вие, "добавките не работят, как да стартираме системната добавка?". Подписваме я с новия сертификат!

Събираме всичко заедно... защо отнема толкова дълго?

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

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

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

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

Финални стъпки

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

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

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

Разбираме, че всичко това не е перфектно. В някои случаи потребителите загубиха данни от разширения (например данни от разширението Multi-Account Containers).

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

Уроци

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

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

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

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

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

През следващата седмица ще разгледаме резултатите от по-подробен анализ на случилото се, а засега ще се радвам да отговоря на въпроси на електронна поща: ekr-blog@mozilla.com

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