Comments 64
Кстати, а никто из энтузиастов таким образом не родил поддерживаемый сообществом самоподписанный кросс-сертификат? Желательно с разными вариантами подмножеств: черный список, только ru-su-рф, только сайты и их ресурсы перешедшие на root CA Минцифры. Удобно же - тот же Минцифры, только принудительно ограниченный нужной зоной.
Кстати, а никто из энтузиастов таким образом не родил поддерживаемый сообществом самоподписанный кросс-сертификат?
А какие основания доверять такому сертификату, выпущенному каким-то совершенно левым автором, не задумывались? Может, поэтому энтузиасты свой энутузиазм придерживают, а сообщество тех, кому-таки оказалось невтерпёж, не поддерживает ?
Ха-ха, самое смешное, что оснований доверять сертификату МинЦифры тоже не больше, чем вот такому самоподписному, от котором я выше писал.
Кто захочет, тот поставит, кто не захочет, пройдёт мимо.
Не всем ведь подряд вкатываться в криптографию и умело играть с созданием приватно-публичных ключей, попутно разбираясь с тонкостью настроек всех этих TLS. Я лично понятия не имею, как это делать... А защититься от MitM на ТСПУ хочется.
Доверие - штука субъективная. Вы, вот, почему-то не доверяете совсем, многие другие - доверяют (и MitM им пофиг), а я, подобно автору недавней статьи, доверяю ограниченно: для доменных имен сайтов в зоне .ru - доверяю (те, кто контролируют ТСПУ, могут получить с этих сайтов любую информацию безо всякого MitM), в остальном - нет.
ru, su, рф недостаточно — есть ещё, например, .moscow и .москва
Я пока не нашел сайта, который был поддерживал подключение по ГОСТ и имел сертификат, подписанный актуальными корневыми Минцифры
думается не там ищите, т.к. подключение по ГОСТ требует помимо браузера поддерживающего ГОСТ еще и установку "платного" криптопровайдера и сейчас это будут какие-то л.к., а не популярные сайты. Год назад приходилось резко внедрять в рабочей среде браузер с поддержкой ГОСТ, КриптоПро, сертификаты для входа в личные кабинеты с сертификатом выпущенным именно Минцифрой, для себя тогда нашлось какое-то самоуспокоение установки КриптоПро без его покупки из-за фразы
https://cryptopro.ru/products/chromium-gost
В качестве криптопровайдера мы рекомендуем использовать КриптоПро CSP. Для работы с защищёнными соединениями не требуется покупка лицензии КриптоПро CSP
Я полазил по некоторым л.к. Там все плохо с цепочками доверия: в корне что попало будет. Хотелось найти что-то, что использует официальные корневые сертификаты...
del
Я активно работаю с этими сертами. Можно поставить и на nginx и его форк, НО задолбаешся с OPENSSL, одновременно openssl поддерживающий ГОСТ и нормальный работают только в КриптоПро, собрать "всеядную" систему крайне сложно. А на гос.сайты сейчас пришло требование наличия 2х параллельных сертов RSA + ГОСТ оба из Минцифры. В чистом яндекс откроется только RSA с цепочка и доверия там всё хорошо, если админ сайта фулчейн правильно собрал(сайт + sub + CA). А вот если стоит КриптоПро + плагин для браузера, тогда на том же сайте можно увидеть ГОСТ (и алгоритм "Кузнечик") и с цепочка и доверия тоже всё хорошо + проверка на отзыв серта.
Извините, конечно, но рассказы про стрррашные сложности с openssl мне напоминают такие же триллеры про собственную почту, которая никогда никуда не придёт без аЦЦкого неизвестно чего. Почему-то у меня ни малейших проблем с двумя сертами (ГОСТ и RSA) в nginx или angie не возникает, как и с собственным почтовиком. Делается за 10 минут с перекуром и просто работает.
Вот, например, докерфайл для nginx с ГОСТ и RSA:
FROM registry.astralinux.ru/library/astra/ubi17-nginx1280:1.7.9
ENV TZ="Europe/Moscow"
ENV PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && \
echo $TZ > /etc/timezone && \
apt-get -o Acquire::GzipIndexes=false update && \
apt-get install --no-install-recommends --no-install-suggests -y libgost-astra && \
ln -sf /dev/stdout /var/log/nginx/access.log && \
ln -sf /dev/stderr /var/log/nginx/error.log && \
mkdir -p /etc/nginx/ &&\
apt-get remove --purge --auto-remove -y && \
rm -rf /var/lib/apt/lists/*
EXPOSE 80 443
STOPSIGNAL SIGQUIT
CMD ["nginx", "-g", "daemon off;"]
А вот к нему README.md:
### nginx-gost-astra
По сути взят официальный базовый образ Astra+nginx и выполнено `apt-get install libgost-astra`.
Пример конфигурации nginx для работы с ГОСТ и RSA параллельно:
```
server {
listen 80;
server_name santa.nn;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl;
server_name santa.nn;
ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
ssl_certificate /etc/nginx/ssl/santa_gost.crt;
ssl_certificate_key /etc/nginx/ssl/santa_gost.key;
ssl_certificate /etc/nginx/ssl/santa.crt;
ssl_certificate_key /etc/nginx/ssl/santa.key;
ssl_prefer_server_ciphers on;
ssl_ciphers GOST2012-GOST8912-GOST8912:GOST2001-GOST89-GOST89:ECDH+AESGCM:ECDH+AES256:ECDH+AES128:ECDH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS;
}
```
Пользуйтесь, если кому надо. Да, на базе astra'ы, но это требования к тем самым сайтам, на которых такой гибрит бывает нужен.
Яндекс браузер для организаций ещё поддерживает гост
ViPNet CSP бесплатный. Такое же сертифицированное СКЗИ, как и КриптоПро CSP и поддерживает те же алгоритмы ГОСТового шифрования.
Все эти решения с проверкой прозрачности, переподписованием - жутко неудобно. Не каждый технарь захочет в этом всем разбираться, а про обычных людей я, вообще, молчу. Нужно решение, которое одной кнопкой будет ограничивать зоны действия сертификатов. Ждем более простых решений. А пока их нет, второй браузер с локальными сертификатами частично решает проблему.
Я пока не нашел сайта, который был поддерживал подключение по ГОСТ и имел сертификат, подписанный актуальными корневыми Минцифры.
Тогда как можно говорить
О доверии к отечественным сертификатам
???
Большинство отечественных сертификатов - не ГОСТовские.
Т. е. твердя об импортозамещении в IT, в святая святых в криптографии продолжает использоваться западная криптография. Ну этим все сказано.
Еще руки не дошли, еще не все тендеры закрыты. Вот как проголодаются, так за перепиливание криптографии возьмутся.
Юзаешь западную ОС - получаешь западную криптографию ) А для повсеместной ГОСТ крипты в .ru зоне, нужно что бы все по умолчанию юзали АРМ, серверные и мобильные рашн ОС, где криптопровайдер будет встроен и бесплатен... Ну а пока юзаем rsa)
Я пока не нашел сайта, который был поддерживал подключение по ГОСТ и имел сертификат, подписанный актуальными корневыми Минцифры.
В Telegram-канале RussianTLS, ссылка на который есть на https://www.gosuslugi.ru/landing/tls, пишут, что пока для сертификатов ГОСТ от Минцифры доступны не все способы выпуска, и SCT в них не добавляются:
> планируется ACME расширить на работу с ГОСТом?
Не в ближайшее время точно. У нас выпуск гост через воздушный зазор.
Для ГОСТ из-за наличия воздушного зазора пре-сертификаты в CTLOG не публикуются, а сами сертификаты не содержат SCT-метки.
Простите, конечно, деревенского, но что такое "воздушный зазор"?
air gap. нет подключения к защищенной сети извне. перенос информации, как правило, через съемный носитель (флешка?)
Собирают запросы на выпуск сертификатов, пишут на флэшку (кроме шуток), ногами несут флшку в охряняемую дядькой с пистолетом с комнату без интернета, суют в компьютер с корневым ключом, подписывают, несут флэшку обратно и рассылают результат запросившим.
Во-первых, древность дикая. И поэтому выпуск занимает несколько дней.
Во-вторых, вызывает вопросы по безопасности, так как присутсвует физическая флэшка с запросами и выпущенными сертификатами, которую можно украсть/скопировать, тем более, что её физически перемещают. А если, например не очистят после? А её точно чистят? Короче офигенно безопасно с точки хрения организаторов, но очень плохо с точки зрения пользователей.
В-третьих, ничего не мешает к этому прикрутить CTLOG. Просто записи о запросе и выпуске будут разнесены по времени. Так что это всё отмазки и кривые руки.
Мда. Если они действительно через такой древний способ (хорошо, хоть не на дискетах носят) добавляют эти сертификаты, то имхо на основном домашнем компьютере в принципе лучше не иметь ПО с отечественными сертификатами (без изоляции)...
Собирают запросы на выпуск сертификатов, пишут на флэшку (кроме шуток), ногами несут флшку в охряняемую дядькой с пистолетом с комнату без интернета, суют в компьютер с корневым ключом, подписывают, несут флэшку обратно и рассылают результат запросившим. Во-первых, древность дикая. И поэтому выпуск занимает несколько дней.
У вас хорошее воображние, но… Во-первых, корневым ключом подписываются не конечные сертификаты, а сертификаты промежуточных выпускающих центров сертификации (ЦС), которые уже, в свтю очередь подписывают конечные сертификаты. И если вы посмотрите, что предлагает скачать Минцифры, то увидите, что таковой у них есть (и в принципе, сертифкат промежуточного ЦС при правильной организации PKI можно даже не качать: место, откуда его можно скачать прописяывается в расширении AIA всех выпущенных им сертификатов). Таких сертификатов промежуточных ЦС немного, перевыпускаются они редко, риск утечки их секретного ключа вполне управляем: достаточно в случае утечки добавить утекший сертификат промежуточного ЦС в CRL… Поэтому сомнительно, что нафантазированная вами процедура используется для выпуска конечных сертификатов. И задержка с выпуском, скорее всего, связан с необходимостью проверки того, что запросивший - действительно тот, за кого он себя выдает. И ЕМНИП у традиционных ЦС (не LetsEncrypt - Verisign и пр.) запрос в 00-е тоже обрабатывался довльно замаетное время.
А вот для выпуска сертификатов промежуточных выпускающих ЦС, которые подписывать должен корневой ЦС, такая процедура вполне оправдана - потому что в случае утечки секретного ключа корневого сертификата последствия устранить куда труднее: для этого его нужно будет удалить на всех оконечных устройствах.
Во-вторых, вызывает вопросы по безопасности, так как присутсвует физическая флэшка с запросами и выпущенными сертификатами, которую можно украсть/скопировать, тем более, что её физически перемещают. А если, например не очистят после? А её точно чистят? Короче офигенно безопасно с точки хрения организаторов, но очень плохо с точки зрения пользователей.
Вопросов не возникает - потому что на этой “флэшке” ничего секретного быть не должно. Запросы на сертификат вы можете сгенерировать себе хоть сами (в Windows для этого используется certreq.exe), а выпущенные конечные сертификаты часто доступны публично (в частности, для работы TLS они обязательно доступны: свой сертификат сервер в процессе согласования соединения шлёт). Секретных ключей конечных сущностей там, при правильной организации PKI, быть не должно - для подписывания они чисто технически совершенно не требуются.
В-третьих, ничего не мешает к этому прикрутить CTLOG. Просто записи о запросе и выпуске будут разнесены по времени.
А вот CTL прикрутить технически действительно, наверное, можно: хотя там свои криптопротоколы, и хотя GOST среди них нет (по крайней мере в RFC 9162 я его не видел), но, AFAIK, с протоколом, используемым для подписи сертифката протокол для CTL не связан. Что этому мешает организационно - не знаю и не интересуюсь: пусть Яндекс сам над сценариями использования своего браузера думает, в моих сценариях использования я проверкой по CTL не пользуюсь, как излишней.
вызывает вопросы по безопасности, так как присутсвует физическая флэшка с запросами и выпущенными сертификатами, которую можно украсть/скопировать, тем более, что её физически перемещают
Присоединяюсь к комментатору выше, в чём вопросы безопасности с CSR-ами и выпущенными сертификатами? И где почитать, что запросы на выпуск конечных сертификатов ногами носят на флэшке?
Первичный выпуск УКЭП ГД в Центробанке (для ЮЛ регулируемых ЦБ). Генерируешь Ключ и запрос на своей стороне, файл запроса записываешь на флешку, ГД идет с флешкой в Центробанк, на этой же флешке получает выпущенный сертификат, передает флешку/серт, связываешь с ключом, профит. Детально изложено на сайте УЦ ЦБ в инструкции (12 стр.) https://www.cbr.ru/Content/Document/File/131446/instructions_obtaining_certificate_person_certificate_issuing_point.pdf
Запрос и сертификат, это публичная информация. Только ключ не должен покидать контролируемую среду.
Я пока не нашел сайта, который был поддерживал подключение по ГОСТ и имел сертификат, подписанный актуальными корневыми Минцифры.
Корневой тоже от 2022 года :( Та же проблема, что и в статье про госуслуги.
По такой логике вообще любой сертификат в хранилище корневых сертификатов подвергают нас риску MiTM.
Ну без CT логов по сути так оно и есть.
формально да, подвергают, для борьбы с этим риском придумали CTlog, который в статье пытаются проверять. MITMный серт если попадет в такой лог - это ЗАШКВАР на весь мир сразу, потому что лог обязан быть публичным, а если не попадет, то браузер ему доверия не построит, потому что не прописан в публичных логах.
а если не попадет, то браузер ему доверия не построит, потому что не прописан в публичных логах.
Это касается CA из поставки браузера или системного хранилища. Для пользовательских CA они не проверяются
MITMный серт если попадет в такой лог
Так а как из лога узнать, что он не настоящий и его выпуском занимался товарищ майор?
Вот только на сколько я правильно помню, то браузер не проверяет сам CTLog, он проверяет только подпись от CTLog, которая по факту является просто обещанием от CTLog что "сертификат получил, обещаю опубликовать его в течении N-часов".
Если и CA и CTLog контролируют одни и те же люди, ничто не помешает выдать полностью валидный сертификат и при этом нигде его не засветив.
Ну собственно их три: Yandex Agate Log, VK NCA Log, The Ministry of Digital Development and Communications Log
Т.е. журнал ведут 3 госкомпании и ни одного независимого участника. Как теперь поверить, что с журналами не проводят махинаций?
Смотря, каких махинаций. Лог похож на блокчейн, удалить или изменить что-то там нельзя (без перестройки всего лога).
Ну т.е. как бы в принципе, если всем вообще пофиг на эти логи, и никто их никогда не мониторит, то держатель лога может чудить по своему усмотрению.
Именно. Для достоверности нам нужны наблюдатели с копией всего лога и частым сравнением. А их нет. Без них блокчейно-подобный журнал - лишь обычный журнал с очень cpu-intensive изменениями в старых записях.
Для достоверности нам нужны наблюдатели с копией всего лога и частым сравнением
Нет, и копий не надо, и частых сравнений. Достаточно архивировать периодически Signed Tree Head.
Мне думается, что в таком случае можно будет определить только факт измененности. А для определения “что изменили” (в частности, с какой записи начали переписывать) нужно все же хранить весь лог.
Само собой. Но в адекватной вселенной после такого переписывания лога он идет в мусорку вместе с издателем.
Это в адекватной. Давайте вообразим, что сегодня мы получили пруф подделки CT-лога и...? Хабр негодует, гики массово сносят "сувенирные" серты даже из своих контейнеров, отдельных профилей браузеров и прочих огороженных пространств. На этом всем, ширнармассы продолжают жрать кактус, даже не особо всхлипывая, так как по зомбоящику им не раскажут доходчиво об инциденте и его значении.
А этот инцидент имеет значение? По моему, CTL - это пятое колесо в телеге PKI (потому что владелец корневого ЦС уже отвечает за всё, что подписал и он, и другие ЦС, сртификаты которых им подписаны), и непонятно почему создатели Яндекс-браузера придают ему какое-то значение. Разве что, используют как костыль?
Лог похож на блокчейн, удалить или изменить что-то там нельзя (без перестройки всего лога).
Но всегда можно что-то добавить - никакой блокчейн от этого сам по себе не защищен.И если все три госкомпании подчиняются одному центру принятия решений – что, на самом деле, не факт, потому как владельцы разных CTL могут подчиняться разным “бульдогам под ковром”, более известным как “башни”, – то они дружно скажут “так и было”. Но вот противоречия между разными башнями так вылезут наружу, да.
Так мы МИТМ на VK не боимся, они и без митма все данные сдадут. А вот если в лог минцифры добавится сертификат на google.com (чтобы узнать, что вы там ищете) - у всех появятся вопросы.
Дык, если такой сертификат - в цепочке сертификатов с корнем от Минцифры - кто-то выпустит и начнет использовать - это почти наверняка будет замечено и на том же Хабре редакция обязательно опубликкет про это новость. А заметить такое несложно - я подобное замечал, помню.
Лично я сохранил в памяти эпизод, когда именно я глядел на чей-то (уже точно не помню) сертифкат от Let’s Encrypt в точности как те пограничники в Интербеллуме на польский паспорт, что описано Маяковским в стихе о советском паспорте - типа, откуда это и чо это за (ну, я про этот ЦС узнал далеко не сразу).
Ну, а как принудительно ограничить область действия сертификатов (Минцифры или кого ещё) - про это свосем недавно была статья на Хабре. Так что пользц от CTL я не вижу, равно как и повышенного основания доверять его владельцу по сравнению с владельцем корневого ЦС.
Ну так и с чем вы спорите? Суть атаки МИТМ: тщ майор сговаривается с вашим билайном, и билайн конкретно для вас выдает подписанный минцифрой гугл.ком в рамках ОРМ. Если вы проморгали, логов нет, ваши поиски слились в следственный отдел, билайн перестал выдавать левый сертификат, никто ничего не заметил. Если логи все-таки есть - то даже если вы проморгаете такое событие, то его след останется в логах и его принесут как новость на хабр.
Вообще, я бы пошел другим путем. В браузеры бы добавил сущность “контейнер для сертификатов”, а у него уже могут быть правила активации. Если правила активации не выполнены, то контейнера как бы не существует и всех сертификатов в нем тоже. В правила можно задавать ip-based, region-based, name-based - ограничения и разрешения. Контейнерами можно не пользоваться - т.е. просто пользоваться каким-то контейнером по-умолчанию “all”, который активен всегда.
Тогда мы не пытаемся как-то видоизменить под себя инфраструктуру криптографии (ибо весь мир не захочет ее менять, тут у нас локальные проблемы на несколько процентов населения планеты). Но при этом получаем контролируемую изоляцию “подозрительных” сертификатов.
В хроме это уже есть и даже статья (https://habr.com/ru/articles/1066372/) на хабре была месяц назад. Я даже навайбкодил для себея простое gui приложение для контроля списков сайтов, ради которых chrome вспоминает, что есть серт минцифры. Мне очень странно, что все упорно продолжают игнорировать этот способ.
Навайбокдил утилиту для генерации самоподписанного сертификата и powershell скрипта для установки в винде - https://github.com/umatrix81/certsru
(а самый известный https://crt.sh/ — так по‑моему вообще сдох)
Он не сдох, но чтобы получить с него информацию (а не всевозможные виды ошибок 500 и 404) нужно потанцевать с бубном, почитать молитву, по обновлять страницу определенное количество раз с определенной частотой в определенное время суток и секунд в минуте.
Для хрома все уже придумано и даже не требует установки серта минцифры куда-либо.
О доверии к отечественным сертификатам и о проверке российских CT логов