Комментарии 15
Также разница в том, что публичная часть ключа в паре ключей для SSH неизменна, а сертификат (публичную часть ключа участника PKI) можно перевыпустить в любой момент.
Тут неверно в случае использования RSA как алгоритма генерации публичного и приватного ключа. В случае SSH и постоянной пары ключей открытый ключ статичен, если же пару пересоздать, понадобится заменить authorized key на сервере, что в принципе соответствует авторизации ещё одного пользователя (проверка доверия в ключах отсутствует). Сертификат можно и перевыпустить, но ключ в нем будет тот же самый, если взять тот же запрос. Т.е. сертификат не есть публичная часть ключа, а удостоверение о том, что владелец закрытого ключа от данного публичного является "Васей Пупкиным" (о котором информация в том же сертификате), подписанное центром сертификации ("Полуэктом").
А так — довольно чОтко расписано.
В этом случае серверам требуется рассылать ещё CRL-ку, у которой по-хорошему должен быть короткий срок жизни.
Действительно, очень незаметно написали.
Возможно, вы не сталкивались с такой необходимостью, а в моей практике это очень сильно зацепило.
Теперь инфраструктуру без CRL не строю, обжёгся один раз — хватит.
Попробую по порядку:
Что за публичная часть ключа? Нет такой части ключа. Вообще нет такого термина в 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 хуже платного?
Заметим, чот я не говорил, что сертификаты от 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».
В чем суть 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, кторый подписал сертификат сервера — чтобы мы могли его проверить с помощью этого доверенного сертификата. Поправьте, если не прав.
Обратимся к документации (с вашего позволения, я переведу):
И сервер, и клиент аутентифицируют друг друга, сначала проверяя, что предоставленные ими сертификаты были подписаны главным удостоверяющим центром, и только потом проверяя остальную информацию из сертификатов, такую как CN и тип сертификата (клиент или сервер).
Про PKI «на пальцах» за 10 минут