Тут плохо прям все. У меня подгорает, когда так некомпетентно рассказывают о важных вещах.
Попробую по порядку:
Что за публичная часть ключа? Нет такой части ключа. Вообще нет такого термина в PKI. Вы используете этот термин в статье в двух значениях: сертификат и публичный ключ. Но даже это не синонимы.
Также разница в том, что публичная часть ключа в паре ключей для SSH неизменна, а сертификат (публичную часть ключа участника PKI) можно перевыпустить в любой момент.
Во-первых сертификат можно перевыпустить не заменяя ключевую пару. Во вторых сертификат не является публичным ключом.
Полуэкт, получив мой запрос и имея обе части ключа CA (здесь — ca.key и ca.crt), выпускает для меня сертификат
На самом деле для подписи сертификата нужен только закрытый ключ.
В чем «фишка» PKI? Отвечаю. Дело в том, что в этой цепочке фишка просто отсутствует. А называется она — CRL (Cerificate Revocation List).
CRL — это один из инструментов, который используется в PKI для достижения самой важной цели — организации доверия. Очевидно, что главная «фишка» в том, что не надо доверять каждому открытому ключу отдельно, а достаточно доверять УЦ, который удостоверяет соответствие открытого ключа и набора информации из, как выразился автор, «небольшой анкеты».
Let's Encrypt — бесплатный проект, которому склонны доверять многие, но я бы очень хорошо подумал, какие ресурсы и при каких обстоятельствах защищать их сертификатами.
Вот почему? Какие риски вы видите? И чем они отличаются, если использовать платный сертификат?
Эти ребята договорились с другими ребятами таким образом, что последние предустанавливают сертификаты (публичные части ключей, т.е. ca.crt из прошлого примера) этих CA в свои браузеры. То есть о PKI как таковой речи быть не может. Просто все договорились верить определенным компаниям.
Да, производители ОС и браузеров решают, каким УЦ они доверяют. Что вы хотите сказать фразой «о PKI как таковой речи быть не может»?
sheknitrtch, а как может быть связано распространение менеджеров паролей и замена их на аутентификацию с использованием закрытого ключа?
Кстати, рекомендую вам ознакомиться с FIDO U2F.
InstaHeat, некоторые известные мне промышленные серверы аутентификации предоставляют доступ к ресурсу в режиме реверс-прокси и предоставляют функционал SSO. Подключаетесь с любого устройства к этому серверу, а он уже откроет для вас остальные сайты с подставленными учетными данными. Такой облачный менеджер паролей получается.
Сейчас зарегистрироваться не получилось. Выскакивает сообщение:
«Необходимо заполнить поле «Согласие на обработку персональных данных».»
Само согласие теперь добавили в форму регистрации полным текстом.
Пока на хабр не напишешь об уязвимости, никто ничего делать не хочет. А теперь похоже засуетились.
Вы правы, никто, конечно, не подбирает код, так как он обычно представляет собой рандом, а не алгоритм. Возможность дублировать симку это один из основных способов украсть СМС. Позитив технолоджи тоже регулярно напоминают, что СМС нельзя использовать для аутентификации, например, из-за уязвимостей в протоколе SS7.
saipr, спасибо за статью.
Кажется тут есть некоторое противоречие. Сначала вы пишите:
Для демонстрации в качестве СКЗИ мы будем использовать облачный токен PKCS#11.
А в конце:
гражданин должен подписывать его сам с помощью только у него хранимого закрытого ключа
Так должен ли по вашему мнению закрытый ключ быть физически у пользователя?
Я слежу за развитием облачной подписи и мне совсем не нравится то, что происходит сейчас у нас. Если в западных странах облачная подпись — уже принятый стандарт, то у нас она пока в серой зоне законодательства. То есть по сути нет никаких запретов, а значит использовать можно. Но если там есть, например, требования строгой аутентификации при доступе к своему облачному токену, то отечественные решения грешат какими-то совсем не укладывающимися в голове уязвимостями. Кто-то предлагает использовать только пароль для аутентификации. Другие сервисы облачной подписи добавляют одноразовые СМС-коды, которым нет доверия уже достаточно давно. Видел даже решения, в которых одноразовый код в СМС — единственный фактор аутентификации пользователя.
По моему это просто кошмар. Для меня это звучит как подмена стойкой асимметричной криптографии на простой пароль или, что еще хуже, СМС-код. Даже в вашем облачном решении, насколько я понимаю, используется по сути два пароля (пароль и PIN). В итоге, если сегодня я смогу относительно удобно зайти на сайт госуслуг с облачным токеном, то завтра моей усиленной квалифицированной электронной подписью может оказаться подписан договор продажи машины/квартиры.
Вот-вот. В паре километров от Новой Москвы года 2-3 назад яйцевидный ОПСОС задумал ставить вышку сотовой связи. Жители бухтели, так как близость конструкции пугала как внешним видом (40 метров), так и возможным излучением. Но инженеры рассказали, как все будет хорошо и все проблемы со связью и интернетом пропадут. В итоге большинством проголосовали за установку. Поставили. Удивлению не было предела, когда оказалось, что на этой вышке вообще нет интернета. Только голос.
Насколько я помню, для собственно входа на терминальный сервер не нужно включать использование локальных устройств/карт. Это нужно только, когда вы хотите пробросить карту в терминальную сессию для использования ее внутри удаленного рабочего стола.
1. Закрытый и открытый ключи ЧЕГО вы предлагаете внести в центр сертификации? И вообще как это «внести закрытый и открытый ключ в центр сертификации»?
2. Что значит опубликован наружу? Зачем? В действительности доступен должен быть только список отзыва — CRL и/или OCSP-респондер.
Смотрите мой ответ ниже.
Конечно, вы можете использовать сертификат для любого домена. Важно понимать, что PKI может быть любой, не обязательно MSCA как в статье. Все, что вам нужно — настроить контроллеры домена:
1. Контроллеры домена должны доверять УЦ (то, о чем вы написали)
2. У самих контроллеров домена должны быть сертификаты, выпущенные этим УЦ. Это в статье опущено, так как если УЦ MSCA и сам находится в домене(что, как вы понимаете, не всегда так), то он автоматически выпускает сертификаты для всех контроллеров своего домена. В противном случае их надо просто выпустить вручную.
Спасибо за настоящие аргументы.
А не осталось ли у вас чеклиста, по которому выбирали вариант доступа? Хотелось бы посмотреть на остальные плюсы и минусы обоих способов.
Насколько я помню, есть строгие ограничения по таймингу ответа процессинга при оплате картой. Тогда полагаю, что порядок должен быть другой: сначала вы списываете деньги со счета, а потом уже зачисляете, если система решает, что платеж целевой. Поправьте, если я ошибаюсь.
Кстати, есть такой сайт: https://howsecureismypassword.net/ Насколько я вижу тут все в js. И никакой отправки на сервер нет.
Он правда проверяет по 10 000 распространенных паролей.
Попробую по порядку:
Что за публичная часть ключа? Нет такой части ключа. Вообще нет такого термина в PKI. Вы используете этот термин в статье в двух значениях: сертификат и публичный ключ. Но даже это не синонимы.
Во-первых сертификат можно перевыпустить не заменяя ключевую пару. Во вторых сертификат не является публичным ключом.
На самом деле для подписи сертификата нужен только закрытый ключ.
CRL — это один из инструментов, который используется в PKI для достижения самой важной цели — организации доверия. Очевидно, что главная «фишка» в том, что не надо доверять каждому открытому ключу отдельно, а достаточно доверять УЦ, который удостоверяет соответствие открытого ключа и набора информации из, как выразился автор, «небольшой анкеты».
Вот почему? Какие риски вы видите? И чем они отличаются, если использовать платный сертификат?
Да, производители ОС и браузеров решают, каким УЦ они доверяют. Что вы хотите сказать фразой «о PKI как таковой речи быть не может»?
Кстати, рекомендую вам ознакомиться с FIDO U2F.
«Необходимо заполнить поле «Согласие на обработку персональных данных».»
Само согласие теперь добавили в форму регистрации полным текстом.
Пока на хабр не напишешь об уязвимости, никто ничего делать не хочет. А теперь похоже засуетились.
Кажется тут есть некоторое противоречие. Сначала вы пишите:
А в конце:
Так должен ли по вашему мнению закрытый ключ быть физически у пользователя?
Я слежу за развитием облачной подписи и мне совсем не нравится то, что происходит сейчас у нас. Если в западных странах облачная подпись — уже принятый стандарт, то у нас она пока в серой зоне законодательства. То есть по сути нет никаких запретов, а значит использовать можно. Но если там есть, например, требования строгой аутентификации при доступе к своему облачному токену, то отечественные решения грешат какими-то совсем не укладывающимися в голове уязвимостями. Кто-то предлагает использовать только пароль для аутентификации. Другие сервисы облачной подписи добавляют одноразовые СМС-коды, которым нет доверия уже достаточно давно. Видел даже решения, в которых одноразовый код в СМС — единственный фактор аутентификации пользователя.
По моему это просто кошмар. Для меня это звучит как подмена стойкой асимметричной криптографии на простой пароль или, что еще хуже, СМС-код. Даже в вашем облачном решении, насколько я понимаю, используется по сути два пароля (пароль и PIN). В итоге, если сегодня я смогу относительно удобно зайти на сайт госуслуг с облачным токеном, то завтра моей усиленной квалифицированной электронной подписью может оказаться подписан договор продажи машины/квартиры.
2. Что значит опубликован наружу? Зачем? В действительности доступен должен быть только список отзыва — CRL и/или OCSP-респондер.
Смотрите мой ответ ниже.
1. Контроллеры домена должны доверять УЦ (то, о чем вы написали)
2. У самих контроллеров домена должны быть сертификаты, выпущенные этим УЦ. Это в статье опущено, так как если УЦ MSCA и сам находится в домене(что, как вы понимаете, не всегда так), то он автоматически выпускает сертификаты для всех контроллеров своего домена. В противном случае их надо просто выпустить вручную.
А не осталось ли у вас чеклиста, по которому выбирали вариант доступа? Хотелось бы посмотреть на остальные плюсы и минусы обоих способов.
Он правда проверяет по 10 000 распространенных паролей.