Comments 15
Также разница в том, что публичная часть ключа в паре ключей для SSH неизменна, а сертификат (публичную часть ключа участника PKI) можно перевыпустить в любой момент.
Тут неверно в случае использования RSA как алгоритма генерации публичного и приватного ключа. В случае SSH и постоянной пары ключей открытый ключ статичен, если же пару пересоздать, понадобится заменить authorized key на сервере, что в принципе соответствует авторизации ещё одного пользователя (проверка доверия в ключах отсутствует). Сертификат можно и перевыпустить, но ключ в нем будет тот же самый, если взять тот же запрос. Т.е. сертификат не есть публичная часть ключа, а удостоверение о том, что владелец закрытого ключа от данного публичного является "Васей Пупкиным" (о котором информация в том же сертификате), подписанное центром сертификации ("Полуэктом").
А так — довольно чОтко расписано.
Раз уж заговорили, что ключ может быть украден — следует упомянуть о возможности отзыва сертификата. (openssl ca -revoke).
В этом случае серверам требуется рассылать ещё CRL-ку, у которой по-хорошему должен быть короткий срок жизни.
В этом случае серверам требуется рассылать ещё CRL-ку, у которой по-хорошему должен быть короткий срок жизни.
Отзыву сертификатов и CRL посвящен целый абзац. Тут или я «незаметно» написал, или вы невнимательно читали ;)
Тут плохо прям все. У меня подгорает, когда так некомпетентно рассказывают о важных вещах.
Попробую по порядку:
Что за публичная часть ключа? Нет такой части ключа. Вообще нет такого термина в PKI. Вы используете этот термин в статье в двух значениях: сертификат и публичный ключ. Но даже это не синонимы.
Во-первых сертификат можно перевыпустить не заменяя ключевую пару. Во вторых сертификат не является публичным ключом.
На самом деле для подписи сертификата нужен только закрытый ключ.
CRL — это один из инструментов, который используется в PKI для достижения самой важной цели — организации доверия. Очевидно, что главная «фишка» в том, что не надо доверять каждому открытому ключу отдельно, а достаточно доверять УЦ, который удостоверяет соответствие открытого ключа и набора информации из, как выразился автор, «небольшой анкеты».
Вот почему? Какие риски вы видите? И чем они отличаются, если использовать платный сертификат?
Да, производители ОС и браузеров решают, каким УЦ они доверяют. Что вы хотите сказать фразой «о PKI как таковой речи быть не может»?
Попробую по порядку:
Что за публичная часть ключа? Нет такой части ключа. Вообще нет такого термина в PKI. Вы используете этот термин в статье в двух значениях: сертификат и публичный ключ. Но даже это не синонимы.
Также разница в том, что публичная часть ключа в паре ключей для SSH неизменна, а сертификат (публичную часть ключа участника PKI) можно перевыпустить в любой момент.
Во-первых сертификат можно перевыпустить не заменяя ключевую пару. Во вторых сертификат не является публичным ключом.
Полуэкт, получив мой запрос и имея обе части ключа CA (здесь — ca.key и ca.crt), выпускает для меня сертификат
На самом деле для подписи сертификата нужен только закрытый ключ.
В чем «фишка» PKI? Отвечаю. Дело в том, что в этой цепочке фишка просто отсутствует. А называется она — CRL (Cerificate Revocation List).
CRL — это один из инструментов, который используется в PKI для достижения самой важной цели — организации доверия. Очевидно, что главная «фишка» в том, что не надо доверять каждому открытому ключу отдельно, а достаточно доверять УЦ, который удостоверяет соответствие открытого ключа и набора информации из, как выразился автор, «небольшой анкеты».
Let's Encrypt — бесплатный проект, которому склонны доверять многие, но я бы очень хорошо подумал, какие ресурсы и при каких обстоятельствах защищать их сертификатами.
Вот почему? Какие риски вы видите? И чем они отличаются, если использовать платный сертификат?
Эти ребята договорились с другими ребятами таким образом, что последние предустанавливают сертификаты (публичные части ключей, т.е. ca.crt из прошлого примера) этих CA в свои браузеры. То есть о PKI как таковой речи быть не может. Просто все договорились верить определенным компаниям.
Да, производители ОС и браузеров решают, каким УЦ они доверяют. Что вы хотите сказать фразой «о PKI как таковой речи быть не может»?
Позвольте, я не буду отвечать на ваши вопросы. Почему? Перечитайте еще раз название статьи и постскриптум.
Тем не менее спасибо за обоснованную и справедливую критику. Ваше мнение очень важно для нас :)
Тем не менее спасибо за обоснованную и справедливую критику. Ваше мнение очень важно для нас :)
Понимаю, к чему вы клоните. Но я негодую не из-за подачи материала, а из-за фактических ошибок. Вот например, вам проще называть и открытый ключ и сертификат термином «публичная часть ключа». Но это некорректно. Потому, что нет никаких частей ключа. И даже если предположить, что вы называете этим термином открытый ключ ключевой пары, то в других предложениях вы этим же термином называете сертификат. А сертификат != открытый ключ. Вы можете таким «упрощением» запутать читателя и него будут ложные представления о рассмотренном материале.
В моем комментарии было не так много вопросов, в основном я указываю на ошибки, не задавая вопросы. Если так будет проще, то давайте я соберу вопросы, на которые мне хотелось бы услышать ваш ответ:
1. Чем сертификат от Let's Encrypt хуже платного?
2. Что вы хотите сказать фразой «о PKI как таковой речи быть не может»?
Игнорирование вопросов, это, конечно, ваше право.
В моем комментарии было не так много вопросов, в основном я указываю на ошибки, не задавая вопросы. Если так будет проще, то давайте я соберу вопросы, на которые мне хотелось бы услышать ваш ответ:
1. Чем сертификат от Let's Encrypt хуже платного?
2. Что вы хотите сказать фразой «о PKI как таковой речи быть не может»?
Игнорирование вопросов, это, конечно, ваше право.
То, что вы называете фактическими ошибками, вы называете справедливо. Но статья предназначается для сильно начинающих. Такие утрирования я ввел намеренно, чтобы упростить понимание — думаю, вы согласитесь, что лучше примера с SSH сложно что-то придумать. Если человек всерьез озаботится изучением материала (на что, надеюсь, кого-то может сподвигнуть эта статья, а может быть и ваши комментарии), он и без меня поймет разницу. А если не озаботится, ему не будет большой разницы в таких нюансах, но, надеюсь, будет хотя бы видимость big picture. В любом случае я не считаю, что после прочтения такого «некомпетентного рассказа» с кучей «фактических ошибок» мир для потенциального читателя перестанет быть прежним.
Заметим, чот я не говорил, что сертификаты от Let's Encrypt какие-то «бракованные» (пунктом ниже я пишу, что шифровать трафик можно и самоподписанным сертификатом). Я лишь написал, что лично я бы хорошо подумал. Поэтому отвечаю на ваш вопрос со своей точки зрения, почему их сертификаты могли бы не подойти лично мне. Итак:
Речь идет о «тех ребятах, которые договорились». Как можно назвать инфраструктурой множество сущностей (я про ОС, браузеры, почтовые клиенты и пр.), которые по своему разумению могут доверять или не доверять разным CA (добавлять или удалять соответствующие сертификаты)? В лучшем случае это некий mesh из разных PKI в рамках каждого CA. Солидные дяди называют это «global SSL ecosystem».
1. Чем сертификат от Let's Encrypt хуже платного?
Заметим, чот я не говорил, что сертификаты от Let's Encrypt какие-то «бракованные» (пунктом ниже я пишу, что шифровать трафик можно и самоподписанным сертификатом). Я лишь написал, что лично я бы хорошо подумал. Поэтому отвечаю на ваш вопрос со своей точки зрения, почему их сертификаты могли бы не подойти лично мне. Итак:
- Let's Encrypt предоставляют сертификаты только с базовой степенью верификации владельца (Domain Validation).
- Let's Encrypt не сделают меня своим доверенным CA, чтобы браузеры доверяли моему CA так же, как их.
- Let's Encrypt не предоставляют wildcard сертификаты (ОК-ОК, на момент написания ;).
- Let's Encrypt не предоставляют Code Signing сертификаты.
2. Что вы хотите сказать фразой «о PKI как таковой речи быть не может»?
Речь идет о «тех ребятах, которые договорились». Как можно назвать инфраструктурой множество сущностей (я про ОС, браузеры, почтовые клиенты и пр.), которые по своему разумению могут доверять или не доверять разным CA (добавлять или удалять соответствующие сертификаты)? В лучшем случае это некий mesh из разных PKI в рамках каждого CA. Солидные дяди называют это «global SSL ecosystem».
Насчет Let's Encrypt согласен — риски от его использования точно такие же, как если у нас сертификат от Comodo, Digicert and Symantec…
В чем суть SSL-сертификатов? В том — чтобы данные между Вашим браузером и WEB-сервером шифровались в процессе передачи.
Чем отличаются самоподписанные сертификаты от платных или бесплатных (Let's Encrypt) с точки зрения пользователя браузера? В удобстве и статусе проверки сертификата (зеленый, красный, зеленый с названием компании и т.д.) Т.е. это маркер, сообщающий — все хорошо или не совсем хорошо. Его можно проигнорировать, а можно пойти и посмотреть на сертификат WEB-сервера (т.е. сделать следующий шаг).
Можно ли осуществить атаку на сертификат? Да — можно. На любое SSL соединение можно осуществить атаку (на стороне клиента, на стороне сервера, на канале — вопрос только в сложности).
Вывод — никакой разницы между Let's Encrypt или платным сертификатом нет с точки зрения безопасности.
Вывод личный — не доверяйте никакому CA — если Вам важны данные, которые Вы вводите в форму (например, логин и пароль от Банк-Клиента) — всегда перед этим проверяйте предъявленный сертификат, даты, цепочку доверия и сравнивайте с прошлым входом)… так как всегда есть вероятность (не нулевая), что в данный момент Ваше SSL соединение уже Bump-нуто.
В чем суть SSL-сертификатов? В том — чтобы данные между Вашим браузером и WEB-сервером шифровались в процессе передачи.
Чем отличаются самоподписанные сертификаты от платных или бесплатных (Let's Encrypt) с точки зрения пользователя браузера? В удобстве и статусе проверки сертификата (зеленый, красный, зеленый с названием компании и т.д.) Т.е. это маркер, сообщающий — все хорошо или не совсем хорошо. Его можно проигнорировать, а можно пойти и посмотреть на сертификат WEB-сервера (т.е. сделать следующий шаг).
Можно ли осуществить атаку на сертификат? Да — можно. На любое SSL соединение можно осуществить атаку (на стороне клиента, на стороне сервера, на канале — вопрос только в сложности).
Вывод — никакой разницы между Let's Encrypt или платным сертификатом нет с точки зрения безопасности.
Вывод личный — не доверяйте никакому CA — если Вам важны данные, которые Вы вводите в форму (например, логин и пароль от Банк-Клиента) — всегда перед этим проверяйте предъявленный сертификат, даты, цепочку доверия и сравнивайте с прошлым входом)… так как всегда есть вероятность (не нулевая), что в данный момент Ваше SSL соединение уже Bump-нуто.
@nmk2002, а не подскажете статью или может даже книгу, где PKI, ключи, сертификаты, pem, csr и прочие штуки описываются компетентно, конкретно и в то же время понятно человеку, который не собирается стать специалистом по ИБ, но которому может понадобиться сделать что-то на практике: выписать сертификат для https, или может научиться использовать рутокен в связке с KeePass? Применительно к последнему, я вот заглянул в документацию и осознал, что не понимаю, что значит "выписать сертификат на ключевую пару".
Можете пройти этот курс: https://intuit.ru/studies/courses/110/110/info
Это намного больше, чем требуется для бытового понимания, но чего-то другого предложить не могу.
ca.crt — сертификат нашего CA, чтобы OpenVPN клиент предъявил его серверу, чтобы тот сопоставил его с приватной частью, которая лежит у него, и убедился, что сертификат подписывал именно он, а не кто-то другой.
— а разве это так работает? Я всегда думал, что ca.crt в данном случае, доверенный сертификат того CA, кторый подписал сертификат сервера — чтобы мы могли его проверить с помощью этого доверенного сертификата. Поправьте, если не прав.
Вы правы, спасибо за дополнение. Я просто не остановился на этом моменте, чтобы не усложнять, и, поскольку речь шла о файлах на клиентской стороне, описал только привычную картину: клиент подключается к серверу, поэтому очевидно, что сервер должен проверить, «честный» ли это клиент (аналогично аутентификации по PSK). Но также и клиент должен убедиться, что сервер принадлежит его PKI — сертификат сервера подписан тем же СА, что и его собственный.
Обратимся к документации (с вашего позволения, я переведу):
Обратимся к документации (с вашего позволения, я переведу):
И сервер, и клиент аутентифицируют друг друга, сначала проверяя, что предоставленные ими сертификаты были подписаны главным удостоверяющим центром, и только потом проверяя остальную информацию из сертификатов, такую как CN и тип сертификата (клиент или сервер).
Sign up to leave a comment.
Про PKI «на пальцах» за 10 минут