Технические подробности недавнего отключения дополнений в Firefox

Прим. переводчика: для удобства читателей даты приведены по московскому времени

Недавно мы пропустили момент истечения срока действия одного из сертификатов, используемых для подписи дополнений. Это привело к отключению дополнений у пользователей. Теперь, когда по большей части проблема исправлена, я хотел бы рассказать о подробностях произошедшего и о проделанной работе.

Подоплёка: дополнения и подписи

Хотя многие используют браузер «из коробки», Firefox поддерживает расширения, называемые «дополнениями». С их помощью пользователи добавляют в браузер различные возможности. Существует свыше 15 тысяч дополнений: от блокировки рекламы до управления сотнями вкладок.

Установленные дополнения должны иметь цифровую подпись, которая защищает пользователей от вредоносных дополнений, и требует минимальной проверки дополнений сотрудниками Mozilla. Мы ввели это требование в 2015 году, поскольку испытывали серьёзные проблемы с вредоносными дополнениями.

Как это работает: каждая копия Firefox содержит «корневой сертификат». Ключ от этого «корня» хранится в модуле аппаратной защиты (HSM), не имеющем доступа к сети. Каждые несколько лет этим ключом подписывается новый «промежуточный сертификат», который используется при подписании дополнений. Когда разработчик присылает дополнение, мы создаём временный «конечный сертификат» и подписываем его, используя промежуточный сертификат. Затем конечным сертификатом подписывается само дополнение. Схематично это выглядит так.

Обратите внимание: у каждого сертификата есть «субъект» (кому выдан сертификат) и «издатель» (кто выдал сертификат). В случае корневого сертификата «субъект» = «издатель», но для других сертификатов издателем сертификата является субъект вышестоящего сертификата, которым тот подписан.

Важный момент: каждое дополнение подписано уникальным конечным сертификатом, но почти всегда эти конечные сертификаты подписаны одним и тем же промежуточным сертификатом.

Примечание автора: исключение — очень старые дополнения. В то время использовались различные промежуточные сертификаты.

Этот промежуточный сертификат вызвал проблемы: каждый сертификат действителен в течение определённого периода. До или после этого периода сертификат недействителен, и браузер не будет использовать дополнения, подписанные этим сертификатом. К сожалению, срок действия промежуточного сертификата истёк 4 мая в 4 часа утра.

Последствия проявились не сразу. Firefox проверяет подписи установленных дополнений не постоянно, а примерно раз в 24 часа, причём время проверки индивидуально для каждого пользователя. В результате, у некоторых людей проблемы возникли сразу же, у некоторых гораздо позже. Мы впервые узнали о проблеме примерно в тот момент, когда истёк срок действия сертификата, и сразу начали искать решение.

Снижаем ущерб

Как только мы поняли, что случилось, то попытались не допустить ухудшения ситуации.

Во-первых, прекратили принимать и подписывать новые дополнения. Нет смысла использовать для этого просроченный сертификат. Оглядываясь назад, я бы сказал, что можно было бы оставить всё как есть. Сейчас приём дополнений возобновлён.

Во-вторых, немедленно разослали исправление, которое предотвратило ежесуточную проверку подписей. Таким образом, мы спасли тех пользователей, у которых браузер за последние сутки ещё не успел проверить дополнения. Сейчас это исправление отозвано, необходимости в нём больше нет.

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

Теоретически, решение проблемы выглядит просто: создаём новый действительный промежуточный сертификат и переподписываем каждое дополнение. К сожалению, это не сработает:

• мы не можем быстро переподписать 15 тысяч дополнений разом, система не рассчитана на такую нагрузку
• после того, как подпишем дополнения, обновлённые версии нужно доставить пользователям. Большинство дополнений устанавливается с серверов Mozilla, поэтому в ближайшие сутки 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 часов после обнаружения проблемы. Как человек, который присутствовал на совещаниях, могу сказать, что в этой сложной ситуации люди работали очень усердно и впустую было потрачено совсем немного времени.

Очевидно, что всего этого вообще не должно было произойти. Явно стоит скорректировать наши процессы, чтобы снизить вероятность подобных инцидентов и облегчить исправление последствий.

На следующей неделе мы опубликуем официальный post-mortem и список изменений, которые намереваемся внести. Пока что поделюсь своими мыслями. Во-первых, должен быть лучший способ отслеживать состояние того, что является потенциальной бомбой замедленного действия. Нужно быть уверенными, что мы не окажемся в ситуации, когда одна из них внезапно сработает. Мы ещё прорабатываем детали, но, как минимум, требуется провести учёт всех подобных вещей.

Во-вторых, нужен механизм быстрой доставки обновлений пользователям, даже тогда, когда — особенно когда — всё остальное не работает. Было здорово, что мы смогли использовать систему «исследований», но это несовершенный инструмент и он обладает некоторыми нежелательными побочными эффектами. В частности, мы знаем, что у многих пользователей включено автоматическое обновление, но они предпочли бы не участвовать в исследованиях (признаюсь, у меня они тоже отключены!). В то же время нам требуется способ прислать обновления пользователям, но, какой бы ни была внутренняя техническая реализация, пользователи должны иметь возможность подписаться на обновления (включая оперативные исправления), но отказаться от всего остального. Кроме того, канал обновления должен быть более отзывчивым, чем сейчас. Даже 6 мая ещё были пользователи, которые не воспользовались ни исправлением, ни новой версией. Над этой проблемой уже работали, но случившееся показало, насколько она важна.

Наконец, мы присмотримся к архитектуре безопасности дополнений, чтобы убедиться, что она обеспечивает должный уровень безопасности с минимальным риском что-то сломать.

На следующей неделе мы рассмотрим результаты более тщательного анализа случившегося, а пока буду рад ответить на вопросы по электронной почте: [email protected]

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