Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error
158 Страницы«<1617181920>»
Информация Chromium + ГОСТ
Опции
К последнему сообщению К первому непрочитанному
Предыдущая тема Следующая тема
Offline Harmattan  
#171 Оставлено : 12 августа 2018 г. 11:02:55(UTC)
Harmattan

Статус: Участник

Группы: Участники
Зарегистрирован: 30.07.2018(UTC)
Сообщений: 13
Российская Федерация
Откуда: Киров

Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 2 раз в 2 постах
Автор: basid Перейти к цитате
Автор: Harmattan Перейти к цитате
P.S. На Windows 10 соединение доверенное, а на lubuntu x64 нет. Корневые сертификаты стоят:
Списки отзывов установлены на обоих системах? Обновляются?


Специально ничего не ставил ни на Windows, ни на lubuntu.

CDP : http://crl.roskazna.ru/crl/ucfk.crl
CDP : http://crl.fsfk.local/crl/ucfk.crl
CDP : http://rostelecom.ru/cdp/guc.crl
CDP : http://reestr-pki.ru/cdp/guc.crl
Скачиваю все:

Пытаюсь ставить в mroot:

Со страницы отозванных сертификатов казначейства качаются тоже неимпортируемые: http://crl.roskazna.ru/
Вверх
Offline basid  
#172 Оставлено : 12 августа 2018 г. 13:12:56(UTC)
basid

Статус: Активный участник

Группы: Участники
Зарегистрирован: 21.11.2010(UTC)
Сообщений: 1,098

Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 151 раз в 136 постах
Автор: Harmattan Перейти к цитате
Пытаюсь ставить в mroot:
А подумать?
В иерархии ГУЦ в корневых находится только сам ГУЦ. Сейчас у ГУЦ два таких сертификата - для ГОСТ-2001 и ГОСТ-2012.
Всё остальное, включая сертификаты аккредитованных УЦ, сертификаты ИС# ГУЦ и списки отзыва устанавливается в промежуточные (ca).

P.S.
Да, я в курсе, что у аккредитованных УЦ есть корневые сертификаты, которые устанавливаются в root, но их требуется всё меньше и меньше.
Вверх
Offline Harmattan  
#173 Оставлено : 12 августа 2018 г. 14:15:10(UTC)
Harmattan

Статус: Участник

Группы: Участники
Зарегистрирован: 30.07.2018(UTC)
Сообщений: 13
Российская Федерация
Откуда: Киров

Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 2 раз в 2 постах
Автор: basid Перейти к цитате

Всё остальное, включая сертификаты аккредитованных УЦ, сертификаты ИС# ГУЦ и списки отзыва устанавливается в промежуточные (ca).
Вверх
Offline basid  
#174 Оставлено : 12 августа 2018 г. 18:45:36(UTC)
basid

Статус: Активный участник

Группы: Участники
Зарегистрирован: 21.11.2010(UTC)
Сообщений: 1,098

Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 151 раз в 136 постах
Автор: Harmattan Перейти к цитате

P.S.
"Если ничего не помогает - прочтите, наконец, инструкцию".
Вверх
Offline Дмитрий Пичулин  
#175 Оставлено : 12 августа 2018 г. 23:34:55(UTC)
pd

Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 1,496
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 35 раз
Поблагодарили: 466 раз в 333 постах
Автор: basid Перейти к цитате
Автор: Harmattan Перейти к цитате

P.S.
"Если ничего не помогает - прочтите, наконец, инструкцию".

Ошибка реально есть, проверено, не связано с доверием, при прочих равных на Unix всё равно ERR_CERT_COMMON_NAME_INVALID.

Значит на Unix есть дополнительный код для этой проверки, которого нет для Windows, и это мы вылечим.
Знания в базе знаний, поддержка в техподдержке
Вверх
WWW
Offline basid  
#176 Оставлено : 13 августа 2018 г. 5:59:10(UTC)
basid

Статус: Активный участник

Группы: Участники
Зарегистрирован: 21.11.2010(UTC)
Сообщений: 1,098

Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 151 раз в 136 постах
Дело не в ошибке - есть и есть. Всяко бывает.
Дело в подходе - фигачится пачка команд и ... Всё.
Ни тебе проделать по шагам и проанализировать каждый, ни документацию прочесть ...
Вверх
Offline Дмитрий Пичулин  
#177 Оставлено : 13 августа 2018 г. 19:19:46(UTC)
pd

Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 1,496
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 35 раз
Поблагодарили: 466 раз в 333 постах
Автор: Дмитрий Пичулин Перейти к цитате
Ошибка реально есть, проверено, не связано с доверием, при прочих равных на Unix всё равно ERR_CERT_COMMON_NAME_INVALID.

Значит на Unix есть дополнительный код для этой проверки, которого нет для Windows, и это мы вылечим.

Выяснилось, что никакого дополнительного кода нет и ошибка касается не всех сайтов, а именно zakupki.gov.ru.

Оказалось, что в сертификате сайта zakupki.gov.ru всё таки присутствует subjectAltName с URL-ID, но он равен "0", что в соответствии со строгой проверкой по RFC 6125, трактуется как наличие поля URL-ID, поэтому сопоставление с CN запрещается.

Чтобы всё таки увидеть зелёный свет в поле с адресом zakupki.gov.ru придётся отключить строгий режим на уровне CSP на Unix-системах.

Отключение строгой проверки по RFC 6125 на Linux:
Код:
sudo /opt/cprocsp/sbin/amd64/cpconfig -ini "\config\Parameters" -add bool "Rfc6125_NotStrict_ServerName_Check" true

Отключение строгой проверки по RFC 6125 на MacOS:
Код:
sudo /opt/cprocsp/sbin/cpconfig -ini "\config\Parameters" -add bool "Rfc6125_NotStrict_ServerName_Check" true

Отредактировано пользователем 13 августа 2018 г. 19:20:21(UTC)  | Причина: Не указана

Знания в базе знаний, поддержка в техподдержке
Вверх
WWW
thanks 2 пользователей поблагодарили pd за этот пост.
Harmattan оставлено 13.08.2018(UTC), nickm оставлено 13.08.2018(UTC)
Offline Harmattan  
#178 Оставлено : 13 августа 2018 г. 19:46:37(UTC)
Harmattan

Статус: Участник

Группы: Участники
Зарегистрирован: 30.07.2018(UTC)
Сообщений: 13
Российская Федерация
Откуда: Киров

Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 2 раз в 2 постах
Автор: Дмитрий Пичулин Перейти к цитате

Отключение строгой проверки по RFC 6125 на Linux:
Код:
sudo /opt/cprocsp/sbin/amd64/cpconfig -ini "\config\Parameters" -add bool "Rfc6125_NotStrict_ServerName_Check" true



Спасибо. Теперь всё отлично.
Вверх
Offline basid  
#179 Оставлено : 14 августа 2018 г. 6:25:31(UTC)
basid

Статус: Активный участник

Группы: Участники
Зарегистрирован: 21.11.2010(UTC)
Сообщений: 1,098

Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 151 раз в 136 постах
Автор: Дмитрий Пичулин Перейти к цитате
Оказалось, что в сертификате сайта zakupki.gov.ru всё таки присутствует subjectAltName с URL-ID, но он равен "0"
Тогда, вероятно, есть ошибка в сообщении по "F12 -> Security", т.к. SAN не "missing", а "not match site URL".
Или как?
Вверх
Offline two_oceans  
#180 Оставлено : 14 августа 2018 г. 8:13:19(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
Я очень благодарен, что разработчики в этой теме все же прислушались к пользователям, однако предчувствую рано или поздно к этому еще вернется разговор, RFC никуда не делся. Поэтому все же адресую вопрос про "корректный MiTM".

Автор: basid Перейти к цитате
Автор: two_oceans Перейти к цитате
Если действительно доверяем УЦ, то непонятно зачем потом сертификат под микроскопом разглядывать и создавать себе лишнюю работу.
Вас немного не туда заносит.

RFC2818 - про соответствие полей сертификата сервера и полей HTTP-запроса.
"Наглое поведение разработчиков хрома" - некорректная интерпретация этого сАмого RFC этими самыми разработчиками.

Делать "корректный MiTM" RFC2818 не мешает - у меня включена проверка шифрованного трафика антивирусом, поэтому я "несколько в теме" Angel
Может быть и "немного не туда заносит", согласен. У меня тоже была включена проверка трафика антивирусом, но антивирус на половину сертификатов сайтов начал ругаться как на недоверенные (в том числе сайты самого произодителя антивируса), потому пришлось отключить проверку - вероятно тоже была внедрена проверка SAN в антивирусе.

Для "корректный MiTM" Вы или антивирус добавили сертификат антивируса в список доверенных УЦ ОС или браузера? Если да, противоречия с моим предыдущим постом не вижу - так как "корректный MiTM" произведен с Вашего согласия и цепочка сертификатов не нарушена, заменен "доверенный" УЦ. И браузер никак не может эту проблему обнаружить и адресовать, не обращаясь к альтернативному списку доверенных УЦ. Моя мысль в ключе - не нужно пытаться обнаружить принципиально необнаружимые проблемы.

В целом, с моей точки зрения, сопоставление CN/SAN с HTTP было нужно когда УЦ не гарантировал соответствие владельца сертификата и владельца сайта. Однако времена изменились - появились политики DV OV EV, которые опираются на проверку УЦ владельца домена по DNS, при этом браузер при проверке опирается на тот же DNS/hosts, доверяет безусловно прокси-серверам, ничего не может сделать с перехватом соединения антивирусом или изменением маршрута сети. Браузер сможет проверить только последний отрезок зашифрованного соединения, а доходит ли этот отрезок до сервера - огромный вопрос. Сопоставление CN/SAN с HTTP браузером совершенно не отвечает на этот вопрос.

Подкину для размышления разработчикам браузеров еще идею: для сертификатов ГОСТ автоматически считать совпадение ОГРН в сертификате сайта и ОГРН в сертификате УЦ (не корневого, а последнего в цепочке перед сертификатом сайта) как аналог пройденных проверок на EV и соответствие имени сайта. Это разом решит проблемы с сертификатами большинства госсайтов и позволит отображать имя ведомства в адресную строку.

Отредактировано пользователем 14 августа 2018 г. 8:15:45(UTC)  | Причина: Не указана
Вверх
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest
158 Страницы«<1617181920>»
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.

Privacy Policy | Форум YAF.NET | YAF.NET © 2003-2024, Yet Another Forum.NET