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

Original author: Eric Rescorla
  • Translation
Об авторе. Эрик Рескорла — технический директор группы Firefox в Mozilla

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

Для справки: расширения и их подпись


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

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

Подпись работает через предустановленный «корневой сертификат» Firefox. Он хранится в автономном режиме в аппаратном модуле безопасности (HSM). Каждые несколько лет он используется для подписания нового «промежуточного сертификата», который хранится в онлайне и используется в процессе подписания. Когда расширение представлено для подписи, мы генерируем новый временный «сертификат конечного объекта» (end-entity certificate) и подписываем его с помощью промежуточного сертификата. Затем сертификат конечного объекта используется для подписи расширения. Визуально это выглядит следующим образом:



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

Важным моментом здесь является то, что каждое дополнение подписывается собственным сертификатом конечного объекта, но почти у всех аддонов один и тот же промежуточный сертификат (несколько очень старых дополнений были подписаны другим промежуточным звеном). Именно здесь возникла проблема: у каждого сертификата есть фиксированный срок действия. До или после этого окна сертификат не будет принят, и расширение, подписанное этим сертификатом, не может быть загружено в Firefox. К сожалению, промежуточный сертификат, который мы использовали, истёк 4 мая после 1:00 UTC, и сразу же каждое дополнение, которое подписано этим сертификатом, стало непроверяемым и не могло быть загружено в Firefox.

Хотя срок действия всех дополнений истёк около часа ночи, последствия ощутились не сразу. Причина в том, что Firefox не постоянно проверяет дополнения на валидность. Они проверяются примерно каждые 24 часа, причём время проверки отличается для каждого пользователя. В результате, некоторые люди испытали проблемы сразу, некоторые — гораздо позже. Мы в Mozilla впервые узнали о проблеме около 18:00 PST в пятницу 3 мая и сразу собрали команду, чтобы исправить ситуацию.

Ограничение ущерба


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

Во-первых, мы отключили подписание новых дополнений. В тот момент это было разумно, потому что подпись ставил недействительный сертификат. Оглядываясь назад, кажется, что можно было и оставить эту функцию, но оказалось, что она также конфликтует со смягчением «жёсткая прошивка даты», которую мы обсудим ниже (хотя в конечном итоге мы её не использовали). Поэтому хорошо, что мы сохранили этот вариант. Итак, подписание новых дополнений теперь отложено.

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

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


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

  1. Расширений очень много (более 15 000), и служба не оптимизирована для массовой подписи, поэтому просто повторное подписание каждого дополнения займёт больше времени, чем мы хотели.
  2. После того, как дополнения подписаны, пользователям будет необходимо получить новое дополнение. Некоторые размещены на серверах Mozilla, и Firefox обновит их в течение 24 часов, но пользователям придётся вручную обновлять любые аддоны, которые установлены из других источников, что очень неудобно.

Вместо этого мы сосредоточились на попытке разработать исправление, которое бы исправляло ситуацию практически без ручного вмешательства со стороны пользователей.

Рассмотрев ряд подходов, мы быстро сошлись на двух основных стратегиях, которые мы проводили параллельно:

  1. Патч Firefox для изменения даты, используемой для проверки сертификата. В этом случае существующие дополнения волшебным образом снова заработают, но потребуется доставка новой сборки Firefox.
  2. Сгенерировать новый действительный сертификат и каким-то образом убедить Firefox принять его вместо существующего, просроченного.

Мы не были уверены, что именно сработает, поэтому решили проводить работы параллельно и внедрить первое, что будет похоже на рабочее решение. В конце дня мы завершили деплой второго исправления — нового сертификата, который я опишу более подробно.

Сертификат на замену


Как упоминалось выше, здесь нужно было выполнить два основных шага:

  1. Создать новый действительный сертификат.
  2. Удалённо установить его в Firefox.

Чтобы понять, почему это работает, вам нужно знать немного больше о том, как Firefox проверяет дополнения. Само дополнение поставляется в виде пакета файлов, который включает цепочку сертификатов, используемую для его подписания. В результате аддон независимо проверяется, если известен корневой сертификат, который настраивается в Firefox во время сборки. Однако, как я уже сказал, промежуточный сертификат был сломан, поэтому дополнение на самом деле не поддавалось проверке.

Но оказывается, что когда Firefox пытается проверить расширение, он не ограничивается использованием только сертификатов в самом расширении. Вместо этого он пытается создать допустимую цепочку сертификатов, начиная с сертификата конечного объекта и продолжая до корневого каталога. Алгоритм сложный, но на высоком уровне вы начинаете с сертификата конечного объекта, а затем находите сертификат, субъект которого равен издателю сертификата конечного объекта (т. е. промежуточного сертификата). В простом случае это только промежуточное звено, поставляемое с надстройкой, но это может быть любой сертификат, о котором знает браузер. Если мы можем удалённо добавить новый, действительный сертификат, Firefox также попытается построить такую цепочку. На рисунке ниже показана ситуация до и после установки нового сертификата.



После установки нового сертификата Firefox имеет два варианта проверки цепочки сертификатов: использовать старый недействительный сертификат (что не сработает) или использовать новый действительный сертификат (что сработает). Важной особенностью здесь является то, что новый сертификат имеет то же имя субъекта и открытый ключ, что и старый сертификат, так что его подпись на сертификате конечного объекта действительна. К счастью, Firefox достаточно умён, чтобы попробовать оба способа, пока не найдёт рабочий, поэтому расширение снова становится действительным. Обратите внимание, что это та же логика, которую мы используем для проверки сертификатов TLS, поэтому это относительно хорошо понятный код, который мы смогли использовать (читатели, знакомые с WebPKI, поймут, что так работает перекрёстная сертификация).

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

Normandy и система исследований


По иронии, решением проблемы стал специальный тип расширения под названием system add-on (SAO). Для исследований аудитории (Studies) ранее мы разработали систему под названием Normandy, которая умеет поставлять SAO пользователям Firefox. Эти SAO автоматически выполняются в браузере пользователя. Хотя они обычно используются для проведения экспериментов, но также обладают широким доступ к внутренним API в Firefox. В этом случае важно, что они могут добавить в базу сертификатов новые сертификаты, которые Firefox использует для проверки расширений (техническое примечание: мы не добавляем сертификат с какими-то специальными привилегиями; он получает свои привилегии за счёт подписи корневым сертификатом. Мы просто добавляем его в пул сертификатов, которые могут использоваться Firefox. Таким образом, мы не добавляем новый привилегированный сертификат в Firefox).

Итак, решение здесь — создать SAO, который делает две вещи:

  1. Устанавливает новый сертификат, который мы сделали.
  2. Заставляет браузер повторно проверить каждое дополнение, чтобы активировать те, которые отключились.

Но подождите, скажете вы. Дополнения не работают, как же заставить работать SAO? Ну, мы подпишем его новым сертификатом!

Собрать всё воедино… и почему так долго?


Итак, теперь у нас есть план: выпустить новый сертификат, чтобы заменить старый, построить системное дополнение, чтобы установить его в Firefox, и развернуть его в Normandy. Мы начали работу примерно с 18:00 PST в пятницу 3 мая, а отправили исправление в Normandy примерно в 2:44 ночи, то есть менее чем через 9 часов, а затем потребовалось ещё 6-12 часов, прежде чем большинство пользователей его получили. На самом деле это очень хороший старт, но я видел в твиттере ряд вопросов, почему мы не смогли сделать это быстрее. Существует ряд шагов, которые отнимают много времени.

Во-первых, потребовалось некоторое время для выдачи нового промежуточного сертификата. Как я уже упоминал выше, корневой сертификат находится в аппаратном модуле безопасности, который хранится в автономном режиме. Это хорошая практика безопасности, так как вы очень редко используете корневой сертификат, и поэтому хотите хранить его в безопасности. Но очевидно, это несколько неудобно, когда нужно выдать новый сертификат в чрезвычайной ситуации. Во всяком случае, одному из наших инженеров пришлось ехать в безопасное место, где хранится HSM. Затем было несколько фальстартов, когда мы не смогли выдать правильный сертификат, и каждая попытка стоила часа или двух тестирования, прежде чем мы точно понимали, что делать.

Во-вторых, разработка системы занимает некоторое время. Концептуально всё очень просто, но даже простые программы требуют некоторой осторожности, и мы действительно хотели убедиться, что не ухудшили ситуацию. И перед отправкой SAO нужно было его протестировать, а это отнимает время, особенно с учётом того, что его нужно подписать. Но система подписи была отключена, поэтому нам пришлось искать обходные пути.

Наконец, как только SAO был готов к отправке, потребовалось время на развёртывание. Клиенты Firefox проверяют обновления Normandy каждые 6 часов, и, конечно, многие клиенты находятся в автономном режиме, поэтому распространение апдейта для всех пользователей Firefox прошло не мгновенно. Однако, на данный момент большинство получили апдейт и/или новый релиз, который мы выпустили позже.

Последние шаги


Хотя системный аддон, развёрнутый через систему Studies, должен исправить ситуацию у большинства пользователей, он дошёл не до всех. В частности, для нескольких типов пользователей требуется другой подход:

  • Пользователи, отключившие телеметрию или исследования.
  • Пользователи Firefox для Android (Fennec), где у нас нет исследований.
  • Пользователи последующих сборок Firefox ESR, которые не подпишутся на телеметрические отчеты.
  • Пользователи, которые находятся за HTTPS MiTM-прокси, потому что наши системы установки аддонов принудительно закрепляют ключи для этих соединений, что конфликтует с прокси.
  • Пользователи очень старых сборок Firefox, до которых система Studies не может достучаться.

Мы ничего не можем сделать с последней группой — им придётся обновиться до новой версии Firefox, потому что старые версии обычно имеют довольно серьёзные неисправленные уязвимости безопасности. Мы знаем, что некоторые люди остались на старых версиях Firefox, потому что хотят запускать расширения старого стиля, но многие из них теперь работают с более новыми версиями Firefox. Для других групп мы разработали патч для Firefox, который установит новый сертификат после обновления. Он также выпущен как новая версия Firefox «с точкой», поэтому люди должны её получить — и, вероятно, уже получили — через обычный канал обновления. Если у вас есть билд из нисходящего потока, вам нужно дождаться обновления от мейнтейнера.

Мы признаём, что ничто из этого не является совершенным. В частности, в некоторых случаях пользователи теряют данные, связанные с аддонами (например, расширение типа «контейнеры с несколькими учётными записями»).

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

Уроки


Во-первых, я хочу сказать, что команда здесь проделала удивительную работу: они разработали и отправили исправление менее чем за 12 часов с момента первоначального отчёта. Как человек, который присутствовал на собрании, где это произошло, я могу сказать, что люди работали невероятно усердно в трудной ситуации и что очень мало времени было потрачено впустую.

С учётом сказанного, очевидно, что это не идеальная ситуация, и такое вообще не должно было случиться. Нам явно нужно скорректировать наши процессы, чтобы уменьшить вероятность этого и подобных инцидентов и облегчить их исправление.

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

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

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

На следующей неделе мы опубликуем результаты более тщательного анализа этой ситуации.
Support the author
Share post

Similar posts

Comments 39

    +1
    «эмитент»
    Я бы сказал «издатель». Забавно, как раз сегодня днём перевёл этот текст, но пока отшлифовывал формулировки, вы успели раньше :) (и лучше).

    Время было бы удобнее перевести в московское, автор начинает с UTC, а потом внезапно перескакивает на PST:

    4 мая после 1:00 UTC (4 мая, 4 утра по МСК) — сертификат протух
    3 мая, 18:00 PST (4 мая, 4 утра по МСК) — разработчики получают сигнал о проблеме
    4 мая, 2:44 PST (4 мая, 12:44 по МСК) — исправление начинает распространяться среди пользователей

    Остаётся открытым вопрос, почему не было настроено никакого уведомления разработчикам о том, что важный сертификат скоро «протухнет».
      0
      Могу предположить:
      1. разработчики не должны иметь к этому доступа в принципе — не их зона ответственности.
      2. Поставленная 1-3-5-10 лет назад напоминалка о том, что серт протухнет не сработает по массе причин. У меня единственная безотказная напоминалка — юзвери. Благо, что мало, некритично и быстро решается.
        0
        Можно скриптик в крон повесить, который будет выкачивать из хранилища все серты, и проверять в них даты. Надеюсь, где-нибудь в CI Мозиллы что-нибудь такое сделают.
          0
          Да какой скрипт. Уверен, что у Мозиллы есть система мониторинга, а любая система мониторинга умеет такие проверки — сам недавно прикручивал на Prometheus через blackbox_exporter.
      +1
      Из за моего недопонимания. Как наличие цифровой подписи мешает подписать вредоносное дополнение? Я к тому, что скорей всего, все происходит автоматически, и что мешает выпустить обновления дополнения с джаваскриптом майнером?
        +3
        Автоматика срабатывает на откровенное говно + с недавних пор запрещено обфусцировать JS (минифицировать можно). И можно легко отозвать подпись у просочившегося, но обнаруженного позже вредоноса, после чего потоньше настроить под его особенности автоматическую проверку.

        Во времена, когда требование подписи отсутствовало, для малвари был рай земной: кладём дополнение в профиль (для записи в AppData, где лежит профиль браузера, права администратора не нужны) и крутим рекламу пользователю. Пришлось сначала внедрить подписывание, а потом сделать его в Windows неотключаемым (грязные хаки в расчёт не берём: если пользователь настолько заморочился, то он либо знает, что делает, либо сам себе злобный буратино). В Linux и macOS проверка отключается через настройки, потому что там вопрос не стоит так остро.

        Впрочем, большинство пользователей, применяющих грязные хаки не знают, что Mozilla давно уже выпускает небрендированные стабильные сборки, которые позволяют ставить какие угодно дополнения, и ломать себе браузер своими руками вовсе не нужно…
          +1
          Так а какая политика приемки дополнений в магазин firefox? По идее и без всяких сертификатов, модерирование (автоматика) должны откидывать хлам. Опять же, вроде как сертификат и не нужен.
            +1
            Сертификат позволяет быстро забанить уже установленное у пользователей вредоносное дополнение. Достаточно его отозвать и запушить всем пользователям обновлённый revocation list.

            Кроме того, без сертификата, как я написал, малварь просто поставит дополнение локально, в обход «магазина». Пришлось бы отказаться от возможности ставить дополнения из любых других источников, что существенно хуже, чем необходимость подписывать. А так разработчик может подписать дополнение, но распространять его, скажем, через Github или свой сайт.
              0
              Кроме того, без сертификата, как я написал, малварь просто поставит дополнение локально, в обход «магазина».

              Имеете ввиду на сторонних сайтах? Но там же запрос пользователю идет. Или мы про случай, когда пользователь не разобрался и клацнул «ок»
                +1
                Я про случай, когда ваш ПК подхватил вирус и этот вирус просто положил своё вредоносное дополнение в ваш профиль на жёсткий диск. Вы вообще ничего не устанавливали, а дополнение уже у вас бы появилось и начало делать своё черное дело.

                Именно про это упоминает Эрик в своём блоге, в 2015 такой сценарий был популярным. Неопытные пользователи, помню, приходили в Википедию и жаловались, что у них поверх «Википедии» реклама, которую, как оказывалось, им крутила малварь.
                  –4
                  И ради такой мелочи надо было усложнять жизнь разработчикам?

                  Не проще ли добавить в браузер примитивное антивирусное поведение — проверку по сигнатурам любого исполняемого браузером кода, с выводом юзеру предупреждения: «мы тут фигню обнаружили. Банеры в википедии крутит. Если вы ее сами поставили в здравом уме — то ок. а если нет — давайте ее грохнем?» И базу раз в неделю обновлять. Не надо ничего подписывать — не надо ничего отзывать.
                    +1

                    Думаю, "засунуть в браузер антивирус" — это точно не "проще".

                      –2
                      Ну да — это настолько сложно что в 90е такого под ДОС было как грязи и влезало на дискету… А тут целый браузер весом с 10 операционных систем который из исходников сутками собирается — куда там примитивную проверку кода перед выполнением добавить…
                      0
                      И ради такой мелочи надо было усложнять жизнь разработчикам?
                      И ради такой мелочи, как разработчики (сравним кол-во разработчиков с кол-вом пользователей), нужно усложнять жизнь пользователям?

                      К тому же, это негативно сказывалось на аудитории. Пользователь ведь в последнюю очередь подумает на вирус. В первую очередь он грешит на сайт (я лично видел жалобы, что Википедия, якобы крутит рекламу, оказалось… да — вирусня на стороне пользователя) и на браузер.

                      Да что там… в этом году видел пользователя, у которого угнали пароль от ICQ и злоумышленник пользовался аськой параллельно с хозяином (а т.к. в аське теперь синхронизация истории, то переписка со второй сессии появлялась и в первой сессии). Так хозяин в первую очередь пришёл к нам, разработчикам месседжера, жаловаться, что у нас баг из-за которого он видит чужую переписку. То, что у него вирусов на ПК, как у собаки блох (что и подтвердилось + в личном кабинете обнаружилась вторая сессия) ему в голову не пришло.
                        –2
                        А чем это усложняет жизнь пользователям? Пока как раз смешным процентам файрфокс пользователей, усложняет жизнь гугление как им запустить свое любимое расширение в своей любимой версии браузера. И тупое отваливание систем подписей, потому, что всем пофигу на срок действия сертификатов.

                        Так хозяин в первую очередь пришёл к нам, разработчикам месседжера

                        А какого черта вы «разработчики мессенджера» запихали туда логин из 100500-ти разных мест одновременно, если у тех кто действительно _разработал_ этот мессенджер — такой ФИГНИ не было, и 2я попытка залогиниться выкидывала предыдущую сессию? Сначала создали дыру в безопасности размером с кратер Джомолунгмы. Потом на каких то единичных раздолбаях, поимели с этой дыры проблемы. Но я думаю ничего — все правильно делаете! Скоро совсем «помянем» этот ваш «мессенджер», бо все «нормальные клиенты» у него еще в декабре отвалились.
                  0
                  Даже с сертификатом можно публиковать без магазина. Публикуем, скачиваем, удаляем из магазина. Как минимум при удалении разработчиком никакие подписи не отзываются. В итоге подпись есть, всё ставится штатно, код уже никто проверять не будет — удалено ведь.
                    0
                    Публиковаться и удаляться не нужно вовсе, дополнение можно распространять без публикации. Я себе так парочку интересных дополнений из Chrome Web Store перетащил, например.

                    Никто не заявлял, что эта схема защищает идеально, да и идеальной защиты нет. Например, когда кастомным поискам запретили давать такие же имена, как дефолтным (т.е., нельзя добавить кастомный поиск с именем Google), разработчики прямо сказали, что они знают, что кастомный поиск можно назвать Gооgle (кириллические «о»), но если разработчики малвари начнут это массово эксплуатировать, тогда и будем решать проблемы по мере их поступления, а пока без нужды закручивать гайки не стоит.
                      0
                      Не совсем понял идею — если изменить код расширения, подпись же зафейлится. В чем тогда профит?
                      Или оно не по коду подпись считает? А нафига она тогда нужна?
                        0
                        Да нет никакого профита. Чтобы установить дополнение большинству пользователей (неважно, как: разместив ссылку на сайте, по которой пользователь кликнет; напрямую положив дополнение в профиль) — нужно отправить файл на автоматическое тестирование, после которого его подпишут (или не подпишут).
                  0
                  Кстати, обфусцировать можно, но надо в этом случае просто предоставить исходный код.
                    +1
                    Вот за что я обожаю Мозиллу, так это за то, что «всё для пользователя»! А не для прибыли. Поэтому и готов терпеть неудобства, которые при таком подходе — временные.
                  –1
                  Все эти манёвры со сменой интерфейса, отвалом старых дополнений при переходе на новый движок, а теперь ещё и отвал дополнений на актуальных версиях достал просто дико. Так что у мозилы минус 1 пользователь с десятилетним стажем.
                    +1
                    А на что перешли, если не секрет? Потому что в интерфейс Chrome не так давно внесли изменения, а Edge вообще на другой движок мигрирует.
                      –3
                      Перешёл как раз таки на хром, т.к. на планшете и смартфоне по умолчанию стоит хром. Пробовал ставить лису на мобильные устройства, но на нексус 5 и 7 она просто не юзабельная из-за постоянных подлагиваний. Я долго сидел на фаерфоксе, но последние изменения и недавнее падение дополнений подтолкнули в сторону хрома.
                        0
                        Я — на Вивальди. Движок хрома, но интерфейс круче. Плюс кастомизоция, и лучше отношение к пользователям со стороны компании. С мозилы ушел, когда отвалились нужные мне дополнения. Аналогов, кстати — так и не нашел, пришлось обходными путями…

                        Например, кто-то знает дополнение (хоть хром, хоть мозила) которое перезагружает текщую страницу при изменении определённого файла на локальном диске?
                          0
                          вы пытаетесь решить проблему неправильным инструментом. Например есть вот такая штука www.browsersync.io
                      +1
                      Мы ничего не можем сделать с последней группой — им придётся обновиться до новой версии Firefox, потому что старые версии обычно имеют довольно серьёзные неисправленные уязвимости безопасности. Мы знаем, что некоторые люди остались на старых версиях Firefox, потому что хотят запускать расширения старого стиля, но многие из них теперь работают с более новыми версиями Firefox.

                      Угу, поставьте версии новее 54 на WinXP.

                      В данном случае не стоило изначально держать пользователей за дебилов. И в ситуации когда проверку на валидность сертификат не проходит дать штатную возможность пользователю использовать аддон на свой страх и риск.
                        +1
                        Да работает все нормально на 54. И подписи отключить можно аж 2-мя методами и сертификат их новый вручную всунуть — короче очередная дежурная ерунда…
                          0
                          Буквально в пятницу присутствовал при попытке установки. 51 встает, 54 требовал Win7.
                          Обращаю внимание «штатно» это значит через меню а не мутные схемы типа about:config, девелоперские сборки и тому подобное.
                          Так же обращаю внимание что использовать аддон с невалидным сертификатом сильно не тоже самое что отлючить валидацию сертификатов аддонов полностью.

                          Вот про вручную всунуть их новый сертификат это интересно, где почитать?
                            +1
                            Под XP последний 52.9.0esr

                            Сертификат всовывается в виде PEM файла в Настройки/Дополнительные/Cертификаты/Просмотр сертификатов/Центры сертификации/Импортировать.

                            pem файл был в прошлой статье habr.com/ru/post/450478/#comment_20120068
                              0
                              Мы ничего не можем сделать с последней группой — им придётся обновиться до новой версии Firefox

                              Под XP последний 52.9.0esr

                              О чем и речь. Может и хотели бы но не смогут.
                              Сертификат всовывается в виде PEM файла в Настройки/Дополнительные/Cертификаты/Просмотр сертификатов/Центры сертификации/Импортировать.

                              Отлично. Жаль конечно что дополнительно все равно придется шаманствовать с about:config и консолью. Но хоть так.
                                0
                                Я одного не понимаю. Почему при просмотре этого сертификата мозилла пишет «Could not verify this certificate because the issuer is unknown». Если я правильно понял статью, то утверждается, что этот промежуточный сертификат подписан корневым сертификатом Mozilla, открытый ключ (?) которого захардкоден в любой бинарник ff, распространяемый мозиллой.

                                Ситуация имеет место на xp, 52.9.0
                          0
                          В сухом остатке — все люди, которые надеялись на расширения для поддержания приватности в тот момент когда были отключены все расширения, частично дали увязать все аккаунты на разных сайтах между собой.
                          А также Мозилла избавилась массово от необходимости поддерживать относительно старые ESR.
                          Ну и обосновывая тем что они в будущем могут накосячить также как и в этот раз, они явно намекают что будут заставлять всех пользоваться только последними версиями браузера.
                          но в то же время мы должны иметь возможность пушить обновления

                          туманно.
                            0
                            А также Мозилла избавилась массово от необходимости поддерживать относительно старые ESR.
                            Старые ESR и так никто не поддерживал. Текущая ESR — 60.6, только она и поддерживается. Если сейчас, допустим, обнаружится критическая уязвимость безопасности, которая актуальна для всей ветки 60.x, то обновление получит лишь 60.6, а более старые (60.5, например) — нет. Поддержка 60.5 закончилась ровно в момент выпуска 60.6.

                            Короче, ESR — это про сохранение неизменным лишь первого числа в версии. И «длительная поддержка» относится как раз к 60-й версии в целом. Никто не отменял необходимость каждые несколько месяцев мигрировать с 60.1 → 60.2 → 60.3 → 60.3.1 и так далее. Эти подверсии и есть исправления безопасности.
                            –9
                            Спасибо за сбой, благодаря нему наконец то перешел с лисы на другой браузер и нисколько не жалею.
                              +3
                              Держите нас в курсе.
                              –2
                              Всё в стиле google (или yandex с кинопоиском), из разряда — вы обязательно обновитесь и будете потребоять наше говно, какое бы оно уродское не было.
                              Использую 56.0.2, уже весьма испорченную нововведениями версию, но с поддержкой LEGACY и буду использовать до последнего. Пусть юзают свои смузийные «высеры» сами. Кстати половина LEGACY плагинов осталась рабочая. Ничего сейчас подредактируем (на крайняк немного поправим исходный код) и будем использовать дальше те плагины которые люди разрабатывали и поддерживали годами своими силами.
                              Удачи эФФективным манагерам…

                                +1
                                Этой проблемы бы не существовало, если пользователям оставили бы возможность отключать проверку сертификатов на свой страх и риск. Хотя бы строчкой в about:config. Но нет, давайте лучше считать пользователей младенцами и принимать решения за них. xpinstall.signatures.required в настройках имеется, но система его игнорирует…
                                  0
                                  У меня друг из-за этого перешел на хром, и назад уже его не вернуть. А я просто обновил на новую версию и все заработало.

                                  Only users with full accounts can post comments. Log in, please.