Все помнят цепочки сертификатов и условия соблюдения доверительных отношений. Сегодня об этом.
Сегодня прилетела одна “очень интересная задача”. Пользователям понадобился сайт: https://fgiscs.minstroyrf.ru/ - какой-то там ФГИС ЦС.
Поскольку сертификат недоверенный, то был послан Google Chrome следом за кораблём. Сертификат недоверенный, буржуйский фаервол шлёт туда же, да и отечественный Касперский не пускает.
Поехали копать сертификаты. Google Chrome последних версий показывает такую картинку:
В промежуточных/доверенных ЦС нет сертификата ни Russian Trusted Sub CA, ни Russian Trusted Root CA. Они выданы The Ministry of Digital Development and Communications с СОС на Ростелекоме и прочем.
Вспоминаем, что перед началом специальной экономической операции, говорили об отечественном ЦС, который будет поддерживаться отечественными браузерами.
Решено, включаем песочницу, начинаем смотреть на отечественные браузеры на “вражеских” движках.
Выбор пал на три отечественных браузера, качаем последние версии:
Sputnik версии 5.6.6280.0
Chromium GOST версии 100.0.4896.88
Yandex версии 22.3.3.852.31573
Sputnik поставляется в виде многотомного самораспаковывающегося 7zip архива с ЭЦП, выданного SPUTNIKLAB LLC. Выдан “вражеским ” Digicert.
Устанавливаем Sputnik, переходим на интересующий нас сайт.
Смотрим сертификаты ПК. Там всё по аналогии с Google Chrome. Сертификатов нет, подключение не защищено. В настройках ничего сверх настроек Google Chrome нет.
Выбросили, запускаем новый экземпляр песочницы.
Устанавливаем Chromium GOST, там всё по аналогии со Sputnik, не удивлюсь если Sputnik собирается на базе Chromium GOST. Запускаем новый экземпляр песочницы
Качаем Yandex браузер, загрузили веб инсталлятор, что-то пошло не так во время установки, предложил скачать офлайн инсталлер, скачали.
С ЭЦП инсталлятора та же история. Использовать свои ЦС для подписания ПО нельзя, т.к. в Windows им нет доверия. По-прежнему используем импортных производителей. Есть SHA-1 и SHA-256, выданные GlobalSign
Инсталлятор задаёт побольше вопросов, ставит с собой Алису (наверняка поэтому и побольше Sputnik-а весит). От неё можно и отказаться, но зачем – ставим в дефолте. Запускаем, открываем требуемый сайт. Видим закрытый замочек.
Интересно, идём в подробнее, видим интересное состояние
Т.е. мы доверяем Russian Trusted Sub CA, но про Russian Trusted Root CA ничего не понятно, смотрим подробности сертификата. Видим всё ту же картинку, что и с Google Chrome
Идём в хранилище сертификатов. Оказывается, прилетел в промежуточные ЦС Russian Trusted Sub CA, но нигде нет Russian Trusted Root CA. Странно, что Yandex позволяет доверять сайту с недоверенным RootCA и судя по описанию, доверяет данному сайту только на основании доверия к промежуточному CA. Не уверен, что это не баг/фича, но так быть не должно.
При декрипте трафика импортным фаерволом по прежнему возникают ошибки, что естественно. А вот Kaspersky в Windows Sandbox влазить не захотел, ну и пусть, пока не определена стратегия по работе с такого рода сервисами, нечего туда ходить.
Из того, что замечено в дистрибутивах данных браузеров. Настроена и включена по умолчанию поддержка сертификатов по ГОСТ Р 34.12 2015. Сделана она через КриптоПро. В Yandex и Chromium GOST ставится/снимается галочка и включена по-умолчанию. Sputnik таких вольностей не позвояет и включает её без возможности отключения (может через какие-то доппараметры и можно, но в юзер интерфейсе не видно)
Выводов не будет, обзоров кнопочек в браузерах так же. Вопрос, как работать с данными сервисами по-прежнему открыт. Доверять непонятному ЦС, который может выпустить (и скорее всего уже выпустил) сертификаты всех популярных сервисов, абсолютно не хочется. Скорее всего пойдём по пути отдельных виртуалок для работы с такими сервисами, да и наверняка стоит посмотреть на “отечественные” ОС, которые будут крутиться в отдельных сетях.
Комментарии (19)
aborouhin
28.04.2022 16:06+2Я у себя ещё несколько лет назад для использования российских ЭЦП и доступа к гос. системам завёл отдельную виртуалку на домашнем сервере, где ничем другим не занимаюсь, хожу на неё по RDP (через VPN, само собой). И там уже бесстрашно ставлю все эти мутные сертификаты, криптопровайдеры, плагины и иже с ними, особо не вдаваясь в подробности.
Заодно решается проблема доступа к ключам ЭЦП - и токен с собой таскать не надо, и рисковать копированием приватных ключей ЭЦП в реестр "боевого" ноута, используемого постоянно для разных нужд, - тоже (а последняя ЭЦП юр. лица от ФНС с токена в реестр, несмотря на все заклинания, так и не скопировалась - только на обычную флэшку).
Vitalley
28.04.2022 16:39+3В связи с последними событиями, все сертификаты стали мутными - сам институт сертификации нарушен.
Mnemonic0 Автор
28.04.2022 17:00+4Если вы пришли в чужую песочницу, там насрали, а вас за это не выпороли, а отобрали лопатку, которой вы говно закопали - это не значит, что продавцы лопаток плохие. Это значит, что продавцы лопаток не хотят, чтобы вы его прятали при помощи их лопаток.
Если у вас напрашивается вывод: буду пользоваться своей, то это не правильно. Вывод должен быть: не буду срать в чужой песочнице.
Mikeoldfield
28.04.2022 16:31У меня в компании куча разных площадок для госзакупок (44 и 223 ФЗ), поставок, тендеров и прочей мути .
У одного через Яндекс работало, у другого только через IE, у третьего только Хром. Я так и не понял этого прикола, ведь у всех с AD через GPO устанавливается одинаковый набор программ, настроек и т.д.
Не знаю, что там у автора со Спутником, но версия с сайта ЕИС теперь стоит у всех, т.к. прекрасно работает у всех и везде, включая и указанный ФГИС.
saipr
28.04.2022 17:01Да, про это писано переписано:
Первое, доступ к порталам не должен зависеть от типа операционной системы и используемого криптопровайдера.
Второе, отечественные ОС должны иметь в своем составе браузеры с поддержкой ГОСТ-ового https.
Третье, отечественные ОС должны иметь в своем составе почтовые клиенты с поддержкой ГОСТ (подписание/шифрование).
Четвертое, отечественные ОС должны иметь в своем составе средства электронной подписи и шифрования
Пятое, отечественные ОС должны иметь поддержку токенов/смарткарт PKCS#11 с поддержкой российской криптографии.
Вот если этот минимум будет реализован, то можно говорить об отечественных ОС типа Linux.
А то не так давно был в одном министерстве, а там увидел уникальное импортозамещение: им предложили некий отечественный Линукс, в нем запустили виртуалку с Windows и со всеми прибамбасами, которые в Министерстве используются на Винде были, и сказали можно рапортовать об импортозамещении. Надеюсь, мой последний абзац не станет руководством к действию.Но воз и нынче там!
ky0
28.04.2022 23:03Первое, доступ к порталам не должен зависеть от типа операционной системы и используемого криптопровайдера.
Можно, имхо, ограничиться вашим первым пунктом — и не городить местечковых велосипедов, воспользовавшись мудрым эмпирическим правилом «не изобретать свою криптографию просто так».
Уточню, что «просто так» — это пока нет объективных причин считать «неотечественную» криптографию к чему-то уязвимой или существенно проигрывающей по каким-то параметрам (скорость и т. п).
ifap
28.04.2022 17:11+1О, наконец вижу первый реальный сайт, где этот самопал реально используется. Забавно, что на https://minstroyrf.ru используется сертификат Sectigo, а ниже пытаются пропихнуть самопальщину, видимо, из соображений: никуда не денетесь, придется ставить Яндекс.Chromium.
Т.е. мы доверяем Russian Trusted Sub CA, но про Russian Trusted Root CA ничего не понятно
Это нормально, браузер и не должен знать про все существующие в природе промежуточные сертификаты. Он должен мочь построить цепочку от конечного сертификата к доверенному (известному ему) корневому.
Mnemonic0 Автор
28.04.2022 17:19+1Там немного по другому. minstroyrf.ru редиректит на minstroyrf.gov.ru, который выдан Sectigo.
Но ведь Russian Trusted Sub CA не является корневым сертификатом, а промежуточным, который выдан уже Russian Trusted Root CA, который является недоверенным.
ifap
28.04.2022 18:49Точно, проглядел.
Судя по Вашим скринам, цепочка такая: сертификат fgiscs.minstroyrf.ru ссылается на промежуточный сертификат Russian Trusted Sub CA, который в свою очередь ссылается на корневой Russian Trusted Root CA. Последний известен браузеру, т.е. браузер ему доверяет. Это нормально.
Mnemonic0 Автор
28.04.2022 19:30Да, да, нормально. Только нормальным такое поведение считает только Yandex
ivan386
29.04.2022 08:36+1Russian Trusted Root CA на сколько я понимаю браузеру не известен. На обоих скринах на нём стоит красный кружок с крестом. А Russian Trusted Sub CA известен так как его добавили в хранилище доверянных сертификатов.
Mnemonic0 Автор
29.04.2022 08:52Да, именно так. После установки Yandex прилетел промежуточный сертификат. Но только в Yandex конечный сертификат считается верным. В то время как остальные браузеры, даже с этим сертификатом фэйлят цепочку, потому как рутовому недоверяют, что верно.
EnterSandman
28.04.2022 19:07У меня сейчас другая проблема
Есть сертификаты со списками отзывов - указаны два домена откуда их брать. Один локальный вида qwerty.local, второй - росказны.
Но незадача - росказна закрыла к себе доступ с ip, которые по некоторых публичных листов не принадлежат к РФ и теперь онлайн проверка на отзыв валится.
Оффлайн - надо ручками подсовывать раз в неделю свежие CRL
Конечно, придуманы костыли, но блин..
Mnemonic0 Автор
28.04.2022 19:32Прокси с ИП в РФ. Благо для crl-ов используется http и сложностей особо нет.
suslayer
29.04.2022 14:31+2Не совсем понятно что хотел донести автор... В чем конкретно претензия/вопрос? Как работать? Установить корневой сертификат и работать.
Russian Trusted Root CA (https://www.gosuslugi.ru/tls) появился как результат сомнительных действий других УЦ - https://habr.com/ru/news/t/653923/ как то надо было обеспечивать доступность сервисов в текущих условиях.
Russian Trusted Root CA подписан ЭП, с использованием сертификата Минцифры 00c9b3f794000000000586 http://reestr-pki.ru/cdp/guc_gost12.crt можете ему не доверять
Данные сертификаты по умолчанию включены в установщик КритоПРО начиная с версии
2022-02-16 КриптоПро CSP 5.0.12417 Osiris
installer: Добавлен корневой ГОСТ-сертификат Минцифры России от 2022 года (CPCSP-12658).
installer: Добавлен корневой RSA-сертификат Минцифры России от 2022 года (CPCSP-12675).
installer: Добавлен корневой ГОСТ-сертификат НУЦ (CPCSP-12675).Есть даже специальный чатик для обсуждения данных сертификатов https://t.me/RussianTLS
ifap
30.04.2022 22:53Russian Trusted Root CA подписан ЭП, с использованием сертификата Минцифры
Russian Trusted Root CA - самоподписанный aka самозаверенный сертификат. Хотите я Вам десяток таких нагенерирую, тоже от имени The Ministry of Digital Development and Communications, и они будут ничуть не менее/более самоподписаны.
vesper-bot
ЕМНИП это фича — если цепочка доверия прослеживается до trusted root certs, сертификат доверенный. И неважно, какого точно типа серт, запиханный в корни — самоподписанный или нет. А то, что с дистром запихали в доверенные именно Sub CA — скорее всего, они не верят, что не придется перепиливать с нуля всю PKI, либо считают текущую цепочку доверия тестовой. Ну или как вариант, тупо боятся, что по корневому сертификату кто-то сумеет восстановить закрытую часть и его не расшаривают. (Это может иметь смысл, если серт ГОСТовый, там вроде как энтропии сильно меньше, чем в RSA, пусть и алгоритм типа более стойкий)
Mnemonic0 Автор
Так история про то, что серт не корневой, а промежуточный является доверенным. В то время, как корневой доверенным так и не является. Yandex браузер считает, что всё ОК, по доверию к промежуточному сертификату можно судить о доверии к конечному сертификату. Другие - так не считают. Нельзя доверять сертификату, если хоть один из сертификатов в цепочке не является доверенным.
В всякие буржуйские фаерволы ещё требуют, чтобы цепочки CRL проверялись сервисом и подтягивались автоматически.