Проблема устаревших корневых сертификатов. На очереди Let's Encrypt и умные телевизоры



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

    Корневой сертификат — сердце центра сертификации. Он буквально встроен в вашу ОС или браузер, он физически присутствует на вашем устройстве. Его не поменяешь со стороны сервера. Нужно принудительное обновление ОС или встроенного ПО на устройстве.

    Специалист по безопасности Скотт Хельме (Scott Helme) пишет, что основные проблемы возникнут у центра сертификации Let's Encrypt, потому что сегодня это самый популярный ЦС в интернете, а его корневой сертификат скоро «протухнет». Смена корня Let's Encrypt назначена на 8 июля 2020 года.

    Конечные и промежуточные сертификаты удостоверяющего центра (CA) доставляются клиенту с сервера, а корневой сертификат у клиента уже есть, поэтому с помощью этой коллекции сертификатов можно построить цепочку и аутентифицировать веб-сайт.

    Проблема заключается в том, что у каждого сертификата есть срок действия, после чего он нуждается в замене. Например, с 1 сентября 2020 года в браузере Safari планируют ввести ограничение на срок действия серверных TLS-сертификатов максимум 398 дней.

    Это значит, что всем нам придётся заменять серверные сертификаты по крайней мере каждые 12 месяцев. Это ограничение распространяется только на сертификаты сервера, оно не распространяется на корневые сертификаты CA.

    Сертификаты CA регулируются другим набором правил, поэтому имеют разные ограничения на срок действия. Очень часто встречаются промежуточные сертификаты со сроком действия 5 лет и корневые сертификаты со сроком службы даже 25 лет!

    С промежуточными сертификатами обычно нет проблем, потому что они поставляются клиенту сервером, который сам гораздо чаще меняет свой собственный сертификат, так что просто в ходе этой процедуры заменяет и промежуточный. Его довольно легко заменить вместе с сертификатом сервера, в отличие от корневого сертификата CA.

    Как мы уже говорили, корневой CA встроен непосредственно в само клиентское устройство, в ОС, в браузер или другое программное обеспечение. Изменение корневого CA веб-сайт не может контролировать. Здесь требуется обновление на клиенте, будь то обновление ОС или софта.

    Некоторые корневые CA существуют уже очень давно, речь о 20-25 годах. Скоро некоторые из самых старых корневых CA приблизятся к концу своей естественной жизни, их время почти истекло. Для большинства из нас это вообще не будет проблемой, потому что CA создали новые корневые сертификаты, и они уже много лет распространяются по всему миру в обновлениях ОС и браузеров. Но если кто-то очень давно не обновлял ОС или браузер, это своего рода проблема.

    Такая ситуация возникла 30 мая 2020 года в 10:48:38 GMT. Это точное время, когда протух корневой сертификат AddTrust от центра сертификации Comodo (Sectigo).

    Он использовался для перекрёстной подписи, чтобы обеспечить совместимость с устаревшими устройствами, в хранилище которых нет нового корневого сертификата USERTrust.

    К сожалению, проблемы возникли не только в устаревших браузерах, но и в небраузерных клиентах на базе OpenSSL 1.0.x, LibreSSL и GnuTLS. Например, в телевизионных приставках Roku, сервисе Heroku, в приложениях Fortinet, Chargify, на платформе .NET Core 2.0 под Linux и многих других.

    Предполагалось, что проблема затронет только устаревшие системы (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9 и т.п.), поскольку современные браузеры могут задействовать второй корневой сертификат USERTRust. Но по факту начались сбои в сотнях веб-сервисов, которые использовали свободные библиотеки OpenSSL 1.0.x и GnuTLS. Безопасное соединение перестало устанавливаться с выводом ошибки об устаревании сертификата.

    Следующий — Let's Encrypt


    Ещё один хороший пример предстоящей смены корневого CA — центр сертификации Let's Encrypt. Ещё в апреле 2019 года они планировали перейти с цепочки Identrust на собственную цепочку ISRG Root, но этого не произошло.



    «Из-за опасений по поводу недостаточного распространения корня ISRG на устройствах Android мы решили перенести дату перехода к собственному корню с 8 июля 2019 года на 8 июля 2020 года», — сказано в официальном сообщении Let's Encrypt.

    Дату пришлось перенести из-за проблемы, которую называют «распространением корня» (root propagation), а точнее, отсутствием распространения корня, когда корневой CA не слишком широко распространён на всех клиентах.

    Сейчас Let's Encrypt использует перекрёстно подписанный промежуточный сертификат с цепочкой до корня IdenTrust DST Root CA X3. Этот корневой сертификат был выдан ещё в сентябре 2000 года и истекает 30 сентября 2021 года. До этого времени Let's Encrypt планирует перейти на собственный самоподписанный корень ISRG Root X1.



    Корень ISRG выпущен 4 июня 2015 года. После этого начался процесс его утверждения в качестве центра сертификации, который завершился 6 августа 2018 года. С этого момента корневой CA был доступен всем клиентам через обновление операционной системы или программного обеспечения. Всё, что нужно было сделать, — это установить обновление.

    Но в этом и проблема.

    Если ваш мобильный телефон, телевизор или другое устройство не обновлялось два года — как оно узнает о новом корневом сертификате ISRG Root X1? А если его не установить в системе, то все серверные сертификаты Let's Encrypt ваше устройство признает недействительными, как только Let's Encrypt перейдёт на новый корень. А в экосистеме Android много устаревших устройств, которые давно не обновлялись.


    Экосистема Android

    Вот почему Let's Encrypt отложил переход к собственному корню ISRG и всё ещё использует промежуточное звено, которое спускается к корню IdenTrust. Но переход в любом случае придётся сделать. И датой смены корня назначено 8 июля 2020 года.

    Для проверки, что на вашем устройстве (телевизор, приставка или другой клиент) установлен корень ISRG X1, откройте тестовый сайт https://valid-isrgrootx1.letsencrypt.org/. Если не появляется предупреждение безопасности, то обычно всё в порядке.

    Let's Encrypt не единственный, кому предстоит решить проблему с переходом на новый корень. Криптографию в интернете начали использовать чуть более 20 лет назад, так что как раз сейчас наступает момент окончания действия многих корневых сертификатов.

    С такой проблемой могут столкнуться владельцы умных телевизоров, которые много лет не обновляли программное обеспечение Smart TV. Например, новый корень GlobalSign R5 Root выпущен в 2012 году, и после некоторые старые Smart TV не могут построить цепочку к нему, потому что этот корневой CA у них просто отсутствует. В частности, эти клиенты не могли установить защищённое соединение с сайтом bbc.co.uk. Чтобы решить проблему, админам BBC пришлось пойти на хитрость: они построили для этих клиентов альтернативную цепочку через дополнительные промежуточные сертификаты, задействуя старые корни R3 Root и R1 Root, которые ещё не протухли.

    www.bbc.co.uk (Leaf)
    GlobalSign ECC OV SSL CA 2018 (Intermediate)
    GlobalSign Root CA - R5 (Intermediate)
    GlobalSign Root CA - R3 (Intermediate)

    Это временное решение. Проблема никуда не уйдёт, если не обновить клиентское ПО. Умный телевизор — это по сути ограниченный в функциональности компьютер под Linux. И без обновлений его корневые сертификаты неизбежно протухнут.

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

    Кстати, в этом проблема, почему некоторые крупные медиаплатформы не могут использовать современные автоматизированные центры сертификации типа Let's Encrypt, пишет Скотт Хельме. Для умных ТВ они не подходят, и количество корней слишком мало, чтобы гарантировать поддержку сертификата на устаревших устройствах. В противном случае ТВ просто не сможет запустить современные стриминговые сервисы.

    Последний инцидент с AddTrust показал, что даже крупные IT-компании бывают не готовы к тому, что у корневого сертификата заканчивается срок действия.

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




    Дата-центр «Миран»
    Решения для аренды и размещения ИТ-инфраструктуры

    Комментарии 55

      +1

      А что там слышно про TLS без CA на базе DNSSEC?

        0
        Даже если взлетит, будет та же проблема при замене KSK-2017 на следующий. В 2017 уже переносили замену на 2018, потому что никто не был готов. И это при том, что на сегодняшний день, положа руку на сердце, DNSSEC массово не используется (по крайней мере, в не-opportunistic режиме), так что мало что могло поломаться. К следующей замене, если DNSSEC «взлетит», будет та же проблема с необновляемыми IoT-devices.
          0

          Ну на IoT нормальные люди сидят на сертификатах с PKP, то-есть с валидацией ключа без chain/CA...

            0
            Не могу уловить ход вашей мысли. Мы всё ещё говорим о IoT-телевизорах, проверяющих TLS-сертификат через TLSA-запись в DNSSEC?
        +2
        Интересно, поможет ли перевести время на год назад на таких устройствах.
          +4
          Тогда телевизор не примет сертификат сайта, ведь он «еще не начал действовать».
            0
            Это если у нового сертификата начальная дата не от рождества христова.
              0
              Какие-то CA выдают такие сертификаты?
                0
                Надеюсь что нет. Но для решения проблемы старых устройств, почему нет. Каких то проблем с безопасностью я от этого не вижу.
          +18
          Подтвердил проблему у себя на Android 5. Обновлений от вендора нет. Решение:

          • Качаем новый сертификат c https://letsencrypt.org/certificates/,
          • конвертируем PEM → DER, чтобы понял даже Android, как-то так:
            wget -O - 'https://letsencrypt.org/certs/isrgrootx1.pem.txt' \
            | openssl x509 -in - -inform PEM -outform DER -out isrgroot.der
          • переносим полученный файл на Android-устройство;
          • на нём же: Настройки → Безопасность → Установка с SD-карты, выбираем файл с сертификатом, озаглавливаем по вкусу, добавляем в хранилище;
          • PROFIT!
            +2
            Жаль, что сотни уязвимостей на пятом андроиде так легко не пофиксить :)
              +1
              Тем не менее, надеюсь, решение пригодится не только пользователям пятака. )
              +3
              первые два пункта для владельцев венды:
              • запустить certmgr.msc
              • открыть trusted root CA/certificates/ISRG Root X1
              • перейти на вкладку details
              • нажать кнопку copy to file
              • формат DER (расширение файла .cer)
              • ввести имя файла
                0

                А на винде зачем? По моему, сертификаты продолжают обновляться даже для Vista. Или я что-то путаю?

                  0
                  чтобы закинуть сертификат на планшет
                0
                У меня на планшете amazon fire hd на 5 андроиде сайт открывается файрфоксом нормально, на хроме показывает ошибку сертификата. Скопировал файлик .der в корень SD-карты и внутренной памяти, попытался установить сертификат через Security & Privacy / Credential storage / Install from SD Card, но что-то не находит его: Certificate file was not found

                Upd: получилось, нужно было расширение .crt
                  0
                  Блин, забыл, съел у меня .der или всё-таки .crt, а перепроверять лениво. Да и комментарий уже не поправишь… х)

                  P. S. FF, наверно, свои сертификаты таскает.
                    0
                    Да, FF свои сертификаты таскает. В результате никаких проблем с шифрованием или сертификатами даже на очень старых версиях браузера и даже на Windows XP в качестве ОС — нет.

                    В отличии от Хрома и многих других браузеров, которые уже многие сайты открывать отказываются.
                  0
                  Можно вместо конвертирования, качать сразу на телефон и там же переименовать *.pem.txt в *.pem ;) По крайней мере на 6-м Андроиде — ок.
                    0
                    Это первое, что я попробовал. На моём девайсе не прокатило )
                    Главное, что выход нашёлся )
                    0

                    А вот начиная с 6 (или 7) такое не прокатит. Там такому корню будут доверять только приложения, настроенные доверять. Обмануть это тоже возможно, но лишь от рута, вручную или через модуль Magisk

                      +1
                      конвертируем PEM → DER, чтобы понял даже Android

                      Два моих старых «дажеандроида», 4.4 и 6.0, напрочь отказались принимать в формате DER (файл серым цветом, недоступен для выбора), а в формате PEM — пожалуйста. В общем, не забываем про метод тыка.

                      Имеется побочный эффект — при установленном пользовательском сертификате система требует запароленную разблокировку экрана.
                        0
                        Когда идея приложений, таскающих с собой свой собственный CA bundle, уже не кажется забавной…

                        А метод, как всегда, на острие науки.
                      +5
                      Спросил это в комментах к оригиналу на HackerNews, но не получил внятного ответа, так что спрошу и тут.

                      Зачем корневым сертификатам в принципе иметь ограниченный срок действия? Какую проблему это решает? Если бы они были бессрочными, какие от этого были бы другие проблемы?

                      На ум приходит только потенциальная компрометация приватного ключа, но если ключ утёк сейчас, а сертификат истекает через 5 лет, это в смысле безопасности всё равно никак не поможет.
                        +10
                        Не уверен что дам правильный ответ, но самый простой: за 25 лет методы шифрования сильно уходят вперед и то, что 25 лет назад было надёжным, становится подбираемым. Поэтому сделали такое ограничение, что бы принудить всех переходить на более новые технологии. Может быть, в текущей ситуации, когда скорость развития железа упала, это станет не так актуально.
                          +10
                          Зачем корневым сертификатам в принципе иметь ограниченный срок действия?
                          Да ни зачем, просто когда придумывали всю эту хрень никто об этом не думал :)
                            +1

                            Помимо утечки приватного ключа, есть ещё соображения нагрузки на ключ. Утрированно: подписывается обычно хеш от документа, а значений хеш-функции — конечно много. Соответственно, с течением времени условная Ева будет узнавать, как подписывать всё большее и большее число хешей, и будет увеличиваться вероятность того, что в это число войдёт и хеш нужного Еве документа.


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


                            В случае асимметричной криптографии возникают и более видимые проблемы. Скажем, в схеме Эль-Гамаля, стойкость обеспечивается (предполагаемои) трудностью задачи дискретного логарифмирования — буквально, нам сложно вычислить приватный ключ по публичному. Но задача-то эта решаема, и даже вполне очевидным способом — пусть и за долгое (на данном этапе развития технологий) время. Но ограниченное. И ключевую пару дольше этого времени использовать нельзя.

                            –4

                            Решение одно — выкинуть PKI на помойку, вместе с DAP, LDAP, X.500 и прочими миазмами энтерпрайза.

                              +4

                              А LDAP-то за что?

                                –5
                                Выше четко написано — миазм энтерпрайза.
                                  +5

                                  Оскорбительный эпитет — это не аргумент. Чтобы использовать его в качестве аргумента — надо сначала доказать, что "миазм энтерпрайза" — это всегда плохо, и подлежит обязательному выкидыванию.

                                    –5
                                    Там все красное. Не поняли иронию, бывает.
                              0
                              Выкинули повсеместно возможность сказать «да я вижу что сертификат протух но мне похер» теперь имеем то что имеем.
                                0

                                Ну на телевизорах и прочих ИоТ этого никогда и не было, как и у сокетов которые открывают мобильные приложения… ну а на старых андроедах в браузерах оно никуда не делось.


                                Ну и смысла в TLS особо нет с этой кнопкой

                                  +3

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

                                    0
                                    если только не уверены, что на той стороне такой игнорирующий подпись клиент
                                    Не обязательно же игнорировать подпись, можно игнорировать только дату.
                                    0
                                    Вот уже года два как выкинули. И в статье речь о том что вот скоро протухнут корневые прописанные в не очень но уже старых андроедах с броузерами уже без этой кнопки.
                                    Об этих устройствах речь.
                                    Более старые, думаю, отвалятся по размеру ключа в новых сертификатах.
                                  0
                                  Означает ли это что в сети отвалится много старых девайсов?
                                  Не каждый пользователь смартфона или даже пк будет обновлять сертификаты.
                                    0
                                    Вопрос тут ещё в том, как цепочка сертификатов составляется — т.е. как создается соответсвтвие с сертификатом выпустившего/перекрестно-подписавшего CA.
                                    Если бы везде она проверялась как в Windows, начиная с XP — по отпечатку ключа — то проблему протухания корневых сертификатов можно было бы обойти: выпускать новый сертификат с тем же ключом. Я сам такое проделывал в инфраструктуре PKI на базе чистой Windows.
                                    Но вот за другие платформы я ничего сказать не знаю.
                                      0
                                      Так смысл ограничения срока действия сертификатов ведь именно в том, чтобы ключ сменить. Для защиты от подбора ключа всякими спецслужбами вероятного противника. Если ключ оставить тем же самым, можно сразу сертификаты с бесконечным сроком действия выпускать.
                                        +1
                                        Дык, об увеличении срока действия корневого сертификата надо было думать заранее, а не подумали. Бывает.
                                        А используются сертификаты часто там, где угрозами от спецслужб можно пренебречь. Упомянутые в статье устройства практически все относятся к этому классу. Ну, к примеру, какой ущерб будет от того, что некто сможет подсмотреть в процессе передачи на «умный» телевизор и так общедоступный поток вещания упомянутой в статье BBC?
                                      0

                                      А какие для web есть альтернативы авторизации по сертификатам?

                                        +1

                                        Да здравствует HTTP. Можно смотреть по user-agent: если понятно, что устройство старое, то отдать ответ по HTTP, иначе перенаправить на HTTPS.

                                          +2

                                          В случае такой реализации будет возможно произвести mitm атаку. Прослушивающему будет достаточно вклиниться в запрос и подменить User-Agent

                                            0

                                            Зависит от того, что важнее: скрытность или доступность. Думаю, для медиасервисов важнее доступность. В случае надобности шифрование можно обеспечить собственной (для сервиса) парой открытого и закрытого ключа с бесконечным сроком действия.

                                              0
                                              ваш клиент умеет в https и по его user-agent это видно. он посылает запрос серверу на подключение https. но находится некий MITM который подменяет ВАШ useragent на нужный этому MITM и к серверу приходит запрос с useragent древнего девайса.
                                              сервер думает, что ваш клиент не умеет в https и отдаёт данные по http, что может расшифровать MITM.

                                              а теперь представьте, что ваш клиент это умный телевизор с какой-нибудь платной подпиской на стриминговый сервис. понятно, что есть выходы из этой ситуации и костыли (виртуальные карты, некие свои прмоежуточные устройства, etc), но это уже не реализует предложенное вами решение.
                                                0

                                                Я понимаю, что это не защитит от MITM; предложение из моего первого комментария защитит только в случае, когда попытка MITM атаки происходит после установки соединения с сервером (подразумеваю, что получив 1 раз редирект на HTTPS клиент не будет больше отправлять HTTP какое-то время) и только на устройствах, которые поддерживают HTTPS.


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

                                            0

                                            В век всеобщего HSTS не прокатит.

                                              0

                                              Это, также как и наличие HTTPS, определяется сервером, с которым связываешься

                                                0

                                                Конечно. Но оно кешируется браузером. И TTL кеша часто выставлен в дикую цифру типа 1 год. И в течении этого времени браузер HTTP даже не попробует.


                                                Плюс есть HSTS Preload — с ним еще хуже.

                                                  0

                                                  Конечно, сейчас уже поздно исправлять. Это надо продумывать заранее.

                                              +1

                                              Считаю, что заголовок User-Agent — вредный, его следует отменить. Нарушает приватность, подталкивает к клоакингу и показу содержимого с User-Agent только из белого списка.

                                                0

                                                С этим можно бороться на клиентской стороне. Возьмите исходники какого-нибудь открытого браузера, измените user-agent, соберите и пользуйтесь или распространяйте.

                                                  0
                                                  Хром уже начал — при включенном флаге chrome://flags/#freeze-user-agent в строке User-Agent упоминается Windows 10, даже при работе на Linux.
                                                0
                                                Ошибусь ли я, если скажу, что умные телевизоры и прочая редко ходят браузером по сайтам, подписанным Let's Encrypt, а все больше используют приложения Youtube, Netflix и др., сертификаты для которых подписаны (скорее всего) другими CA?

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                Самое читаемое