[ON] Устаревание корневого сертификата AddTrust привело к сбоям в системах с OpenSSL и GnuTLS

Обсуждение новостей, соответствующих тематике форума

Модератор: Модераторы разделов

Ответить
Аватара пользователя
rssbot
Бот
Сообщения: 6002
ОС: gnu/linux

[ON] Устаревание корневого сертификата AddTrust привело к сбоям в системах с OpenSSL и GnuTLS

Сообщение rssbot »

30 мая истёк 20-летний срок действия корневого сертификата AddTrust, который применялся для формирования перекрёстной подписи (cross-signed) в сертификатах одного из крупнейших удостоверяющих центров Sectigo (Comodo). Перекрёстная подпись позволяла обеспечить совместимость с устаревшими устройствами, в хранилище корневых сертификатов которых не был добавлен новый корневой сертификат USERTRust.
Изображение


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

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

Например, возникли проблемы с доступом к некоторым репозиториям пакетов в Debian и Ubuntu (apt стал выдавать ошибку проверки сертификата), стали завершаться сбоем обращения из скриптов при помощи утилит "curl" и "wget", наблюдаются ошибки при использовании Git, нарушилась работа платформы потокового вещания Roku, перестали вызываться обработчики Stripe и DataDog, начали возникать крахи в приложениях Heroku, перестали подключаться клиенты OpenLDAP, фиксирутся проблемы с отправкой почты на серверы SMTPS и SMTP со STARTTLS. Кроме того наблюдаются проблемы в различных Ruby-, PHP- и Python-скриптах, использующих модуль с http-клиентом. Из браузеров проблема затрагивает Epiphany, в котором перестали загружаться списки блокировки рекламы. Программы на языке Go проблеме не подвержены, так как в Go предлагается собственная реализация TLS.

Предполагалось, что проблема затрагивает старые выпуски дистрибутивов (включая Debian 9, Ubuntu 16.04, RHEL 6/7) в которых используются проблемные ветки OpenSSL, но проблема проявилась также при работе пакетного менеджера APT в актуальных выпусках Debian 10 и Ubuntu 18.04/20.04, так как APT использует библиотеку GnuTLS. Суть проблемы в том, что многие TLS/SSL-библиотеки разбирают сертификат как линейную цепочку, в то время как в соответствии с RFC 4158 сертификат может представлять ориентированный распределённый циклический граф с несколькими якорями доверия, которые нужно учитывать. О данной недоработке в OpenSSL и GnuTLS было известно уже много лет. В OpenSSL проблема была устранена в ветке 1.1.1, а в GnuTLS остаётся неисправленной.

В качестве обходного пути устранения сбоя предлагается удалить из системного хранилища сертификат "AddTrust External CA Root" (например, удалить из /etc/ca-certificates.conf и /etc/ssl/certs, а затем запустить "update-ca-certificates -f -v"), после чего OpenSSL начинает нормально обрабатывать перекрёстно подписанные сертификаты с его участием. При использовании пакетного менеджера APT на свой страх и риск можно отключить для отдельных запросов проверку сертификатов (например, "apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false").

Для блокирования проблемы в Fedora и RHEL предлагается добавить сертификат AddTrust в чёрный список:

Код:

trust dump --filter "pkcs11:id=%AD%BD%98%7A%34%B4%26%F7%FA%C4%26%54%EF%03%BD%E0%24%CB%54%1A;type=cert" \
› /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
update-ca-trust extract


Но данный способ не работает для GnuTLS (например, продолжает выдаваться ошибка проверки сертификата при запуске утилиты wget).

На стороне сервера можно изменить порядок перечисления сертификатов в цепочке доверия, отправляемых сервером к клиенту (если связанный с "AddTrust External CA Root" сертификат будет убран из списка, то проверка клиентом пройдёт успешно). Для проверки и генерации новой цепочки доверия можно использовать сервис whatsmychaincert.com. Компания Sectigo также предоставила альтернативный перекрёстно подписанный промежуточный сертификат "AAA Certificate Services", который будет действовать до 2028 года и позволит сохранить совместимость со старыми версиями ОС.

Дополнение: Проблема также проявляется в LibreSSL.


Источник: https://www.opennet.ru/opennews/art.shtml?num=53061
(opennet.ru, основная лента)
Последний раз редактировалось rssbot 31.05.2020 13:01, всего редактировалось 3 раза.
Причина: Updated upstream
Спасибо сказали:
Ответить