Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 45
Кстати, а никто из энтузиастов таким образом не родил поддерживаемый сообществом самоподписанный кросс-сертификат? Желательно с разными вариантами подмножеств: черный список, только ru-su-рф, только сайты и их ресурсы перешедшие на root CA Минцифры. Удобно же - тот же Минцифры, только принудительно ограниченный нужной зоной.
Кстати, а никто из энтузиастов таким образом не родил поддерживаемый сообществом самоподписанный кросс-сертификат?
А какие основания доверять такому сертификату, выпущенному каким-то совершенно левым автором, не задумывались? Может, поэтому энтузиасты свой энутузиазм придерживают, а сообщество тех, кому-таки оказалось невтерпёж, не поддерживает ?
Ха-ха, самое смешное, что оснований доверять сертификату МинЦифры тоже не больше, чем вот такому самоподписному, от котором я выше писал.
Кто захочет, тот поставит, кто не захочет, пройдёт мимо.
Не всем ведь подряд вкатываться в криптографию и умело играть с созданием приватно-публичных ключей, попутно разбираясь с тонкостью настроек всех этих TLS. Я лично понятия не имею, как это делать... А защититься от MitM на ТСПУ хочется.
Я пока не нашел сайта, который был поддерживал подключение по ГОСТ и имел сертификат, подписанный актуальными корневыми Минцифры
думается не там ищите, т.к. подключение по ГОСТ требует помимо браузера поддерживающего ГОСТ еще и установку "платного" криптопровайдера и сейчас это будут какие-то л.к., а не популярные сайты. Год назад приходилось резко внедрять в рабочей среде браузер с поддержкой ГОСТ, КриптоПро, сертификаты для входа в личные кабинеты с сертификатом выпущенным именно Минцифрой, для себя тогда нашлось какое-то самоуспокоение установки КриптоПро без его покупки из-за фразы
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'ы, но это требования к тем самым сайтам, на которых такой гибрит бывает нужен.
Яндекс браузер для организаций ещё поддерживает гост
Все эти решения с проверкой прозрачности, переподписованием - жутко неудобно. Не каждый технарь захочет в этом всем разбираться, а про обычных людей я, вообще, молчу. Нужно решение, которое одной кнопкой будет ограничивать зоны действия сертификатов. Ждем более простых решений. А пока их нет, второй браузер с локальными сертификатами частично решает проблему.
Я пока не нашел сайта, который был поддерживал подключение по ГОСТ и имел сертификат, подписанный актуальными корневыми Минцифры.
Тогда как можно говорить
О доверии к отечественным сертификатам
???
Большинство отечественных сертификатов - не ГОСТовские.
Т. е. твердя об импортозамещении в 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-ами и выпущенными сертификатами? И где почитать, что запросы на выпуск конечных сертификатов ногами носят на флэшке?
Я пока не нашел сайта, который был поддерживал подключение по ГОСТ и имел сертификат, подписанный актуальными корневыми Минцифры.
Корневой тоже от 2022 года :( Та же проблема, что и в статье про госуслуги.
По такой логике вообще любой сертификат в хранилище корневых сертификатов подвергают нас риску MiTM.
Ну без CT логов по сути так оно и есть.
формально да, подвергают, для борьбы с этим риском придумали CTlog, который в статье пытаются проверять. MITMный серт если попадет в такой лог - это ЗАШКВАР на весь мир сразу, потому что лог обязан быть публичным, а если не попадет, то браузер ему доверия не построит, потому что не прописан в публичных логах.
а если не попадет, то браузер ему доверия не построит, потому что не прописан в публичных логах.
Это касается CA из поставки браузера или системного хранилища. Для пользовательских CA они не проверяются
MITMный серт если попадет в такой лог
Так а как из лога узнать, что он не настоящий и его выпуском занимался товарищ майор?
Ну собственно их три: Yandex Agate Log, VK NCA Log, The Ministry of Digital Development and Communications Log
Т.е. журнал ведут 3 госкомпании и ни одного независимого участника. Как теперь поверить, что с журналами не проводят махинаций?
Смотря, каких махинаций. Лог похож на блокчейн, удалить или изменить что-то там нельзя (без перестройки всего лога).
Ну т.е. как бы в принципе, если всем вообще пофиг на эти логи, и никто их никогда не мониторит, то держатель лога может чудить по своему усмотрению.
Именно. Для достоверности нам нужны наблюдатели с копией всего лога и частым сравнением. А их нет. Без них блокчейно-подобный журнал - лишь обычный журнал с очень cpu-intensive изменениями в старых записях.
Для достоверности нам нужны наблюдатели с копией всего лога и частым сравнением
Нет, и копий не надо, и частых сравнений. Достаточно архивировать периодически Signed Tree Head.
Вообще, я бы пошел другим путем. В браузеры бы добавил сущность “контейнер для сертификатов”, а у него уже могут быть правила активации. Если правила активации не выполнены, то контейнера как бы не существует и всех сертификатов в нем тоже. В правила можно задавать ip-based, region-based, name-based - ограничения и разрешения. Контейнерами можно не пользоваться - т.е. просто пользоваться каким-то контейнером по-умолчанию “all”, который активен всегда.
Тогда мы не пытаемся как-то видоизменить под себя инфраструктуру криптографии (ибо весь мир не захочет ее менять, тут у нас локальные проблемы на несколько процентов населения планеты). Но при этом получаем контролируемую изоляцию “подозрительных” сертификатов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О доверии к отечественным сертификатам и о проверке российских CT логов