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

Уведомление

Icon
Error

33 Страницы«<2930313233>
Опции
К последнему сообщению К первому непрочитанному
Offline chomper  
#301 Оставлено : 28 мая 2014 г. 9:44:32(UTC)
chomper

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

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

Поблагодарили: 9 раз в 6 постах
Я думаю, было бы интересно услышать мнение Юрия Маслова на эту тему, учитывая, что по адресу http://q.cryptopro.ru доступны все самоподписанные сертификаты УЦ ООО "КРИПТО-ПРО" :)
Offline MCR  
#302 Оставлено : 28 мая 2014 г. 11:13:24(UTC)
MCR

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

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

Сказал(а) «Спасибо»: 57 раз
Поблагодарили: 11 раз в 8 постах
Автор: Sergey M. Murugov Перейти к цитате
Автор: Zloy Strelok Перейти к цитате
В то же время сложно обеспечить исключительно доверенное распространение корневого. Так его можно получить имея доступ к компьютеру с установленным сертификатом или от пользователя УЦ. А вот если обеспечить целостность корневого в определенном УЦ источнике и всех отсылать к нему (что в принципе и делается), то в итоге пользователю сложно будет подложить ложные корневые и серт.


Попробую повторить ещё разок.
1. Сетевая (не защищённая) загрузка самоподписанных (т.е. ни чем не защищённых) подвержена атаки на навязывание ложной информации. Если хотите можете этот риск принять, только если что случится, и дело дойдёт до суда, вы вряд ли выкрутитесь, поскольку проблема очевидна. При такой загрузке целостность обеспечить просто невозможно, поскольку не ясен вопрос - целостность чего обеспечивать? Ложного сертификата или истинного - они оба целые и не битые.
2. Доверенное распространение совсем не сложно обеспечить, тут уже пару раз предлагались решения: распространять вместе с СКЗИ, распространять вместе с получением персонального сертификата, явное-личное обращение в УЦ, ГУЦ и т.д.
3. Самое правильное - ничего не выдумывать и следовать международным стандартам и опыту. Мы вот тут в лёгкую без всяких глубоких исследований выяснили, что построенный PKI квалифицированный домен в РФ подвержен целому ряду атак, такой дырявой реализации я не видел ни где в Европе. В свете этого совсем не удивительно, что банки шарахаются от квалифицированных сертификатов как черт от ладана, что понятно, там деньги по сети летают и реальные риски, которые можно подсчитать в рублях. Об этом, в частности очень долго говорили, кто был слышал, на секции «Безопасность национальной платежной системы: как создать атмосферу доверия к компонентам инфраструктуры применения электронных подписей?» ИНФОФОРУМА-2014 в январе которую вел Тимур Аитов.


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

PKI не сразу строился. А сломать можно все что угодно при желании.
Offline Sergey M. Murugov  
#303 Оставлено : 28 мая 2014 г. 16:04:56(UTC)
Sergey M. Murugov

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

Группы: Участники
Зарегистрирован: 18.06.2008(UTC)
Сообщений: 230
Откуда: Москва

Сказал(а) «Спасибо»: 2 раз
Поблагодарили: 40 раз в 28 постах
Автор: MCR Перейти к цитате
Насчет банков утверждение довольно спорное.
На мой взгляд, не нужно нагнетать обстановку, а просто правильно проверять сертификаты и обеспечить пространство доверия.

У банков - однозначно нет доверия к аккредитованной ветки по многим причинам и кривизна реализации и ответственность УЦ и их неуправляемо огромное количество.
Про остальное, так я не против - "давайте жить долго и счастливо", только как это реализовать то?
И попутно, что вы называете "правильно проверять сертификаты"? Просто вам для сведения, в РФ даже при сертификации не проводят испытаний на корректность построения цепочки сертификации, нет методик таких проверок. Единственное что есть нормального по миру так это у НИСТа, достаточно полно прописано поведение прикладного уровня с учётом RFC 5280. Там книжка листов в 300 - описание самой методики и тестов штук 250 и тестового материала порядка 700 криптообъектов. Вот пройдя тестирование по такой методики, только после этого можно говорить о "правильно проверять сертификаты". Повторю, наше СКЗИ эти тесты не проходят.
Автор: MCR Перейти к цитате
Суть проста – загрузили из доверенного источника сертификат с помощью которого проверяете список и проверяете им потом все списки, не перекачивая каждый раз. Разве это сложно? Тогда и подмену списка, о которой вы пишите произвести будет нельзя.

Что значит проверяете именно им, на чём сделана подпись тем и проверяют или вы предлагаете уйти от унификаций PKI и написать свою фактически транспортную систему? Может проще сделать как правильно и по стандарту , а не заниматься самоделками на коленке?
Автор: MCR Перейти к цитате
Перекачивать каждый раз корневой УЦ самоподписанный по сети никто не заставляет. Можно и создать свой список доверенных УЦ и ориентироваться на него.

Таки его и укладывать в TSL ни кто не заставлял, на кой его туда кладут то???
Автор: MCR Перейти к цитате
PKI не сразу строился. А сломать можно все что угодно при желании.

Я бы по другому предложение построил. Ни кто не мешает и ранее не мешал сделать всё правильно, чтобы не было ни дыр ни надобности в переделывании. Мне кажется, что в РФ PKI-строительством занимаются беспричинно и чрезмерно долго. Пора уже начинать использовать эту вспомогательную систему в реальных процессах, а мы всё законы переписываем, да дыры латаем.

Offline Юрий  
#304 Оставлено : 29 мая 2014 г. 7:03:35(UTC)
Юрий

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

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 675
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 3 раз
Поблагодарили: 95 раз в 68 постах
Почитал несколько последних постов.
Если здесь обсуждается вопрос доверия к скаченным данным то решение для этой проблемы было найдено лет N-дцать назад: публикация хэшей файлов на доверенном сайте.
С уважением,
Юрий Строжевский
Offline Sergey M. Murugov  
#305 Оставлено : 29 мая 2014 г. 9:31:54(UTC)
Sergey M. Murugov

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

Группы: Участники
Зарегистрирован: 18.06.2008(UTC)
Сообщений: 230
Откуда: Москва

Сказал(а) «Спасибо»: 2 раз
Поблагодарили: 40 раз в 28 постах
Автор: Юрий Перейти к цитате
Почитал несколько последних постов.
Если здесь обсуждается вопрос доверия к скаченным данным то решение для этой проблемы было найдено лет N-дцать назад: публикация хэшей файлов на доверенном сайте.

1. Тут обсуждали несколько не то, а именно, обсуждалось, что неправильно защищать нечто секретом, производным от защищаемого объекта.
2. Исходно обсуждалась ошибка в структуре TSL списка, когда внутрь его был помещён самоподписанный сертификат ГУЦа - якорь доверия ко всему в домене РФ, и что эта ошибка может привести к удачной атаки на весь домен.
3. Ваша мысль в целом правильная - надо разносить в стороны секреты. Только в приложении к данной ситуации, надо не хэши где то выкладывать, а удалить самоподписанный сертификат из TSL и распространять такой TSL как это делается и сейчас, а самоподписанный сертификат ГУЦа распространять иными способами (как ранее говорилось в ветке, при продаже СКЗИ, при получении пользовательского сертификата в УЦ и т.д.)
4. В ваших словах не совсем понятно, что такое "доверенный сайт", какие к нему требования, какой транспорт, что нужно сделать, чтобы считать что он доверенный, вот например, www.gosuslugi.ru - это доверенный сайт или нет? Если - да, то почему?
Offline MCR  
#306 Оставлено : 29 мая 2014 г. 10:10:48(UTC)
MCR

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

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

Сказал(а) «Спасибо»: 57 раз
Поблагодарили: 11 раз в 8 постах
Автор: Sergey M. Murugov Перейти к цитате

Автор: MCR Перейти к цитате
Насчет банков утверждение довольно спорное.
На мой взгляд, не нужно нагнетать обстановку, а просто правильно проверять сертификаты и обеспечить пространство доверия.

У банков - однозначно нет доверия к аккредитованной ветки по многим причинам и кривизна реализации и ответственность УЦ и их неуправляемо огромное количество.
Про остальное, так я не против - "давайте жить долго и счастливо", только как это реализовать то?
И попутно, что вы называете "правильно проверять сертификаты"? Просто вам для сведения, в РФ даже при сертификации не проводят испытаний на корректность построения цепочки сертификации, нет методик таких проверок. Единственное что есть нормального по миру так это у НИСТа, достаточно полно прописано поведение прикладного уровня с учётом RFC 5280. Там книжка листов в 300 - описание самой методики и тестов штук 250 и тестового материала порядка 700 криптообъектов. Вот пройдя тестирование по такой методики, только после этого можно говорить о "правильно проверять сертификаты". Повторю, наше СКЗИ эти тесты не проходят.

Ниши СКЗИ самые СКЗИстые СКЗИ в мире.
Мы (а точнее 8 КГБ СССР) создали свой криптоалгоритм, создали свой специальный ДСЧ (в отличии от используемого на западе уязвимого ДСЧ.
Определили содержание сертификатов, и включаем туда столько информации, сколько вряд ли включается где-то за рубежом.
Может быть, необходимо уже переходить к обеспечению доверия к этой среде?
Важно просто научится наконец доверять PKI РФ среде, и постепенно бороться с угрозами. Сразу побороть все угрозы один разом не получится.
Под «правильно проверять» подразумевал одну простую вещь - не строить всю цепочку проверки на доказательствах, которые подгружаются откуда-то динамически, где мы не можем гарантировать целостность , достоверность информации. Сами доказательства важно получать из определенных доверенных источников. Доверенные источники и способы получения определяются от вероятного размера ущерба и вероятности угрозы. Не правильно в этом смысле везде использовать один и тот же метод передачи.

Автор: Sergey M. Murugov Перейти к цитате

Автор: MCR Перейти к цитате
Суть проста – загрузили из доверенного источника сертификат с помощью которого проверяете список и проверяете им потом все списки, не перекачивая каждый раз. Разве это сложно? Тогда и подмену списка, о которой вы пишите произвести будет нельзя.

Что значит проверяете именно им, на чём сделана подпись тем и проверяют или вы предлагаете уйти от унификаций PKI и написать свою фактически транспортную систему? Может проще сделать как правильно и по стандарту , а не заниматься самоделками на коленке?

Транспортная система в лице так называемых специализированных операторов связи уже существует. Сергей, вам также должно быть известно, что стандарт – это документ высокого уровня. И не только от него зависит правильность реализации, а в большей степени от тех, кто будет претворять его положения в жизнь. Как уже писал выше, двигаться нужно постепенно.
Автор: Sergey M. Murugov Перейти к цитате

Автор: MCR Перейти к цитате
Перекачивать каждый раз корневой УЦ самоподписанный по сети никто не заставляет. Можно и создать свой список доверенных УЦ и ориентироваться на него.

Таки его и укладывать в TSL ни кто не заставлял, на кой его туда кладут то???

Думаю, наверняка на это смогут ответить только авторы. Как вариант, например, можно сравнить имеющийся у себя (полученным из какого-то доверенного источника, который для нас является таковым) с вложенным и понять можно ли доверять такому списку или нет.

Автор: Sergey M. Murugov Перейти к цитате


Автор: MCR Перейти к цитате
PKI не сразу строился. А сломать можно все что угодно при желании.

Я бы по другому предложение построил. Ни кто не мешает и ранее не мешал сделать всё правильно, чтобы не было ни дыр ни надобности в переделывании. Мне кажется, что в РФ PKI-строительством занимаются беспричинно и чрезмерно долго. Пора уже начинать использовать эту вспомогательную систему в реальных процессах, а мы всё законы переписываем, да дыры латаем.

Надеюсь в свете последних тенденций, массовое использование не за горами.
Время и особенности реализации есть некая национальная особенность, в которой многое отражается, как в зеркале.

Отредактировано пользователем 29 мая 2014 г. 10:20:20(UTC)  | Причина: Не указана

Offline Юрий  
#307 Оставлено : 29 мая 2014 г. 10:12:36(UTC)
Юрий

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

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 675
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 3 раз
Поблагодарили: 95 раз в 68 постах
Автор: Sergey M. Murugov Перейти к цитате
Автор: Юрий Перейти к цитате
Почитал несколько последних постов.
Если здесь обсуждается вопрос доверия к скаченным данным то решение для этой проблемы было найдено лет N-дцать назад: публикация хэшей файлов на доверенном сайте.

1. Тут обсуждали несколько не то, а именно, обсуждалось, что неправильно защищать нечто секретом, производным от защищаемого объекта.
2. Исходно обсуждалась ошибка в структуре TSL списка, когда внутрь его был помещён самоподписанный сертификат ГУЦа - якорь доверия ко всему в домене РФ, и что эта ошибка может привести к удачной атаки на весь домен.
3. Ваша мысль в целом правильная - надо разносить в стороны секреты. Только в приложении к данной ситуации, надо не хэши где то выкладывать, а удалить самоподписанный сертификат из TSL и распространять такой TSL как это делается и сейчас, а самоподписанный сертификат ГУЦа распространять иными способами (как ранее говорилось в ветке, при продаже СКЗИ, при получении пользовательского сертификата в УЦ и т.д.)
4. В ваших словах не совсем понятно, что такое "доверенный сайт", какие к нему требования, какой транспорт, что нужно сделать, чтобы считать что он доверенный, вот например, www.gosuslugi.ru - это доверенный сайт или нет? Если - да, то почему?

1. Полностью согласен;
2. Для того, чтобы помещать внутрь TSL что угодно достаточно скажем на сайте Минсвязи иметь историю изменения TSL вместе с хэшами этих списков;
3. Передавать через Интернет можно что угодно. Достаточно чтобы у пользователя, который скачивает данные, было доверие к странице, на которой написаны значения хэшей скачиваемых данных;
4. "Доверенный сайт" - сайт, к которому у данного пользователя в данный момент есть доверие :) Это как доверенный сертификат, только для сайтов :) И также как и для доверенных сертификатов положение с доверием отдельного данного пользователя может измениться в любой момент;
С уважением,
Юрий Строжевский
Offline Юрий Маслов  
#308 Оставлено : 30 мая 2014 г. 16:49:46(UTC)
Юрий Маслов

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

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

Поблагодарили: 36 раз в 25 постах
Приветствую, коллеги!

Позвольте встрять. Я правильно понимаю, что тут идёт речь о корневых сертификатах аккредитованных УЦ? Если да, то не могу понять сути спора. Какие ложные сертификаты вместо истинных корневых?! У нас односторонняя кросс-сертификация. И цепочка сертификатов заканчивается не самоподписанным корневым сертификатом аккредитованного УЦ, а корневым ГУЦа. Поэтому если Вы этот корневой ГУЦа будете распространять довереннмы образом, то смело размещайте по адресу http://q.cryptopro.ru все самоподписанные сертификаты!
С уважением,
КРИПТО-ПРО
Offline Zloy Strelok  
#309 Оставлено : 30 мая 2014 г. 19:10:49(UTC)
Zloy Strelok

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

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

Сказал «Спасибо»: 51 раз
Поблагодарили: 30 раз в 22 постах
Автор: Юрий Маслов Перейти к цитате
Приветствую, коллеги!

Позвольте встрять. Я правильно понимаю, что тут идёт речь о корневых сертификатах аккредитованных УЦ? Если да, то не могу понять сути спора. Какие ложные сертификаты вместо истинных корневых?! У нас односторонняя кросс-сертификация. И цепочка сертификатов заканчивается не самоподписанным корневым сертификатом аккредитованного УЦ, а корневым ГУЦа. Поэтому если Вы этот корневой ГУЦа будете распространять довереннмы образом, то смело размещайте по адресу http://q.cryptopro.ru все самоподписанные сертификаты!


Вроде с этого спор и начался - что корневой гуц есть в tls списке кроссертификатов минкомсвязи.. и этот список им же подписан )
Offline Uatto  
#310 Оставлено : 4 июня 2014 г. 8:11:05(UTC)
Uatto

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

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

Сказал(а) «Спасибо»: 6 раз
Поблагодарили: 1 раз в 1 постах
Извиняюсь, но может кто-нибудь объяснить, почему "цепочка сертификатов заканчивается не самоподписанным корневым сертификатом аккредитованного УЦ, а корневым ГУЦа"? Сертификат УЦ то самоподписанный, и им подписываются сертификаты пользователей УЦ. Как цепочка может заканчиваться не на нем?
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest
33 Страницы«<2930313233>
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.