Comments 29
У меня остался один вопрос: зачем в данной системе использовать именно сертификат, когда из всех полей сертификата реально можно использовать только одно — публичный ключ? Поясню почему нельзя использовать другие поля сертификата: закрытый и публичный ключ генерирует сам пользователь, хэш сумма вычисляется только от общего массива получившегося сертификата. Таким образом в данной системе могут быть миллионы сертификатов выданных, например, Владимиру Владимировичу Путину. Или Биллу Гейтсу. Так что пока считаю, что в данной чудесной системе можно обойтись и без PKI — просто использовать массив публичного ключа.
Фактически эта система будет работать но в рамках одного ресурса — к примеру доступ к части корпоративного сайта, там где эти сертификаты будут генерироваться и выдаваться лицом которое может проверить личность будущего владельца сертификата. Что собственно не редкость в банковской сфере и гос.
В глобальных системах это реализовать сложно по причинам вышеуказанным, хотя в маштабах страны это реализовать возможно но врятли гос. структура согласиться делиться такими данными с тем-же ВК, не говоря уже о мелких ресурсах.
В глобальных системах это реализовать сложно по причинам вышеуказанным, хотя в маштабах страны это реализовать возможно но врятли гос. структура согласиться делиться такими данными с тем-же ВК, не говоря уже о мелких ресурсах.
> Фактически эта система будет работать
Вообще-то — уже работает.
> но в рамках одного ресурса — к примеру доступ к части корпоративного сайта, там где эти сертификаты будут
> генерироваться и выдаваться лицом которое может проверить личность будущего владельца сертификата.
Вы говорите о простом использовании клиентских сертификатов, с верификацией через CA.
Здесь же в качестве верификатора выступает распрёделённый глобальный блокчейн.
И сертификаты самоподписаные, то есть создаются без участия СА.
> В глобальных системах это реализовать сложно по причинам вышеуказанным,
EMCSSL — глобальная система. В ней реализовано. Сгенерите сертификат — и идите на любой сайт, который EMCSSL поддерживает, наример pool.emercoin.com. Хотя конечно в рамках какой-либо организации это тоже можно использовать.
> хотя в маштабах страны это реализовать возможно но врятли гос. структура согласиться делиться такими данными
> с тем-же ВК, не говоря уже о мелких ресурсах.
А EMCSSL не требует участия третьего лица. Вы захотели обзавестись сертификатом — скачиваете скрипты, и генерите локально. От воли гос. структур тут ничего не зависит.
Вообще-то — уже работает.
> но в рамках одного ресурса — к примеру доступ к части корпоративного сайта, там где эти сертификаты будут
> генерироваться и выдаваться лицом которое может проверить личность будущего владельца сертификата.
Вы говорите о простом использовании клиентских сертификатов, с верификацией через CA.
Здесь же в качестве верификатора выступает распрёделённый глобальный блокчейн.
И сертификаты самоподписаные, то есть создаются без участия СА.
> В глобальных системах это реализовать сложно по причинам вышеуказанным,
EMCSSL — глобальная система. В ней реализовано. Сгенерите сертификат — и идите на любой сайт, который EMCSSL поддерживает, наример pool.emercoin.com. Хотя конечно в рамках какой-либо организации это тоже можно использовать.
> хотя в маштабах страны это реализовать возможно но врятли гос. структура согласиться делиться такими данными
> с тем-же ВК, не говоря уже о мелких ресурсах.
А EMCSSL не требует участия третьего лица. Вы захотели обзавестись сертификатом — скачиваете скрипты, и генерите локально. От воли гос. структур тут ничего не зависит.
Ах вот оно что — сертификаты самоподписаные. Тогда тем более нет никакой (вообще) причины использовать именно сертификаты. Если у вас возникает проблема с использованием публичного/приватного ключа при создании коммуникаций в браузере, то вполне вероятно написать самостоятельное расширение.
Ага… Написать самостоятельное расширение для каждого браузера… Потом для всех веб-серверов… Потом проверить безопасность BAN-логикой… Потом сделать это стандартом…
По-моему, Вы предлагаете снова пройти путь стандарта X.509. Зачем?
Чем Вам сертификаты не угодили — стандартные, провереные, поддерживаемые всеми браузерами и WEB-серверами?
По-моему, Вы предлагаете снова пройти путь стандарта X.509. Зачем?
Чем Вам сертификаты не угодили — стандартные, провереные, поддерживаемые всеми браузерами и WEB-серверами?
> зачем в данной системе использовать именно сертификат, когда из всех полей сертификата реально можно использовать только одно — публичный ключ?
Ещё используются Serial, СN и UID.
> Поясню почему нельзя использовать другие поля сертификата: закрытый и публичный ключ генерирует сам пользователь, хэш сумма вычисляется только от общего массива получившегося сертификата.
Утверждение неверно. Сертификат не содержит закрытого ключа. Смотрите пример сертификатата — где тут приватный ключ?
> Таким образом в данной системе могут быть миллионы сертификатов выданных, например, Владимиру Владимировичу Путину.
Да. Но только первый из них, кто загрузил в NVS — захватывает соответствующий Serial ID. Другие сертификаты с тем же Serial отвергаются. Этим обеспечивается уникальность Serial как userID.
> Так что пока считаю, что в данной чудесной системе можно обойтись и без PKI — просто использовать массив публичного ключа.
Я не понимаю, что это такое «массив публичного ключа». Но если Вы его сможете загрузить в браузер безо всяких дополнительный plugins, и чтоб браузер его предьявлял когда и кому надо, и чтоб его все WEB-сервера при установлении TLS-сессии понимали — тогда наверное можно сделать что-то эдакое по Вашему, да.
Ещё используются Serial, СN и UID.
> Поясню почему нельзя использовать другие поля сертификата: закрытый и публичный ключ генерирует сам пользователь, хэш сумма вычисляется только от общего массива получившегося сертификата.
Утверждение неверно. Сертификат не содержит закрытого ключа. Смотрите пример сертификатата — где тут приватный ключ?
> Таким образом в данной системе могут быть миллионы сертификатов выданных, например, Владимиру Владимировичу Путину.
Да. Но только первый из них, кто загрузил в NVS — захватывает соответствующий Serial ID. Другие сертификаты с тем же Serial отвергаются. Этим обеспечивается уникальность Serial как userID.
> Так что пока считаю, что в данной чудесной системе можно обойтись и без PKI — просто использовать массив публичного ключа.
Я не понимаю, что это такое «массив публичного ключа». Но если Вы его сможете загрузить в браузер безо всяких дополнительный plugins, и чтоб браузер его предьявлял когда и кому надо, и чтоб его все WEB-сервера при установлении TLS-сессии понимали — тогда наверное можно сделать что-то эдакое по Вашему, да.
В общем ещё раз — в данной системе используется простейший режим создания подписей на основе уникальности пары «публичный-закрытый ключ». Сертификаты тут использованы только для того, чтобы упростить их использование в браузере. Из всего сертификата используется только массив публичного ключа. Какое-либо использование подобных «сертификатов» в PKI просто невозможно.
> В общем ещё раз — в данной системе используется простейший режим создания подписей на основе уникальности пары «публичный-закрытый ключ»
А безопасное https через TLS-соединение с Вашей точки зрения не создаётся, да.
> Сертификаты тут использованы только для того, чтобы упростить их использование в браузере.
Потому что они стандартные, безопасные и используются всеми. И именно посредством них устанавливается https.
А безопасное https через TLS-соединение с Вашей точки зрения не создаётся, да.
> Сертификаты тут использованы только для того, чтобы упростить их использование в браузере.
Потому что они стандартные, безопасные и используются всеми. И именно посредством них устанавливается https.
Безопасное TLS соединение создаётся когда сертификат является доверенным. Ваши же сертификаты являются самоподписанными и доверенными их считать изначально невозможно. Для осуществления установления доверия к подобным сертификатам нужно будет провести очень большой комплекс процедур. И пока я считаю, что этот «комплекс процедур» будет существенно больше по затратам, чем стандартная модель PKI.
Ещё раз: Довереность создаётся не стандартным способом, посредством подписывания у СА, а посредством загрузки хеша сертификата в децентрализованый и довереный блокчейн. В этом и состоит новизна технологического решения.
Насчёт «очень большой комплекс процедур» — это на сервере держать кошелёк, который и поддерживает актуальную базу довереных сертификатов. Больше это по затратам, чем покупать сертификаты у СА — это вопрос финансовый, а не технологический. И каждый его решает по своему, в ту или иную пользу. HashCoin, например решил, что EMCSSL для него лучше чем использование внешнего CA.
Насчёт «очень большой комплекс процедур» — это на сервере держать кошелёк, который и поддерживает актуальную базу довереных сертификатов. Больше это по затратам, чем покупать сертификаты у СА — это вопрос финансовый, а не технологический. И каждый его решает по своему, в ту или иную пользу. HashCoin, например решил, что EMCSSL для него лучше чем использование внешнего CA.
Доверенный сертификат или нет в PKI определяется доверием к корневому сертификату цепочки сертификатов для данного пользовательского сертификата. Понятие «доверенный блокчейн» мне понятно слабо. Как я понял из статьи этот блокчейн может однозначно подтвердить только то, что серийный номер сертификата уникален.
У вас в статье есть вот такое выражение:
Как сервер проверяет, что именно этот сертификат был сгенерирован для системы emcssl, при условии, что клиентский сертификат самоподписанный?
Сервер, получив сертификат, вначале проверяет подпись сертификата. Успешная проверка подписи доказывает, что сертификат был сгенерирован для системы emcssl.
Как сервер проверяет, что именно этот сертификат был сгенерирован для системы emcssl, при условии, что клиентский сертификат самоподписанный?
Корневой CA-каталог, включающий секретный ключ, входит в дистрибутив системы. То есть то, что в обычном СА является секретом — здесь секретом не является. И на этом открытом СА любой участник может подписать свой сертификат. По сути, это сделано только для совместимости с текущей системой сертфиикатов, типа заглушки. Реальная валидация проводится через блокчейн.
Так сертификат пользователя самоподписанный или нет?
Пользователь сам подписывает сертификат на CA-ключе, который есть у него локально.
Поэтому, формально говоря, сертификат самоподписаный.
Но CA-ключ не абы какой, а из дистибутива EMCSSL.
Вот техническое описание технологнии EMCSSL: habrahabr.ru/post/257605
Поэтому, формально говоря, сертификат самоподписаный.
Но CA-ключ не абы какой, а из дистибутива EMCSSL.
Вот техническое описание технологнии EMCSSL: habrahabr.ru/post/257605
Мда. Самоподписанным называется сертификат, у которого поля «issuer» и «subject» являются одинаковыми и у которого подпись самого сертификата выполнена с использованием закрытого ключа, соответствующего публичному ключу из данного сертификата. А ваша схема уже формально использует «удостоверяющий центр».
Будем считать, что я ошибся, называя сертификат самоподписаным.
Ну тогда я вам расскажу, как работает ваша система. Всё работает по стандартной схеме PKI: есть один удостоверяющий центр и множество пользовательских сертификатов. Так как сертификат пользователя генерируется самим пользователем, то возникает проблема — отсутствие уникальности серийных номеров сертификатов. Данную проблему вы решаете использованием блокчейна. Так что блокчейн у вас тут крайне второстепенная вещь, которая просто обеспечивает формальные требования к пользовательским сертификатам. Доверенное TLS у вас действительно возникает, но вот только потому, что вы добавляете корневой сертификат вашего так сказать «удостоверяющего центра» в доверенные. То есть выполняете формальные требования.
Однако думаю, что возможны различные претензии к вашим пользовательским сертификатам, вызванные тем, что генерируются они самим пользователем. Так основная претензия будет к качеству генерируемых ключей — при генерации ключей с помощью УЦ возможно использование «правильных алгоритмов» генерации и правильных параметров к ним, а вот при генерации на стороне пользователя с этим уже могут возникнуть сложности. Ну и опять же я до сих пор утверждаю, что в ваших сертификатах полезной нагрузкой является только публичный ключ. На все остальные поля сертификата можно закрывать глаза.
Однако думаю, что возможны различные претензии к вашим пользовательским сертификатам, вызванные тем, что генерируются они самим пользователем. Так основная претензия будет к качеству генерируемых ключей — при генерации ключей с помощью УЦ возможно использование «правильных алгоритмов» генерации и правильных параметров к ним, а вот при генерации на стороне пользователя с этим уже могут возникнуть сложности. Ну и опять же я до сих пор утверждаю, что в ваших сертификатах полезной нагрузкой является только публичный ключ. На все остальные поля сертификата можно закрывать глаза.
Также в вашей системе возможна ситуация, когда пользователь изготавливает себе сертификат удостоверяющего центра. И таким образом может начать сам устанавливать политики использования выпущенных сертификатов и другие ограничения. Или сделать очень длинную цепочку сертификатов (скажем в 1000 промежуточных удостоверяющий центров) и создавать тем самым возможные проблемы для «certificate verification engines».
Кстати, ответьте, пожалуйста, на мой вопрос в этой теме.
Кстати, ответьте, пожалуйста, на мой вопрос в этой теме.
Вы неверно поняли. В блокчейне, помимо Serial, хранится ещё и хеш самого сертификата. Поэтому если Вы сгенерируете сертификат с моим Serial=f1551313530859ce, загрузите в свой браузер, и пойдёте на pool.emercoin.com, то сервер Ваш сертификат отвергнет, так как его хеш не будет совпадать с хранящимся в блокчейне.
Фиктивный CА сделан исключительно для совместимости со стандарным механизмом проверки сертификатов, и его приватный ключ секретом не является. Основная проверка пользователя происходит при сравнении хешей.
> утверждаю, что в ваших сертификатах полезной нагрузкой является только публичный ключ.
Утверждение неверно. Ещё совершенно необходим Serial, который идентифицирует пользователя.
И ещё опционально используются другие поля — CN, UID, EMAIL. Но не суть важно.
Даже если Ваше высказывание было бы правдой — ну и что из того следует?
X.509 сертификат взят за основу именно из-за стандартности и распространённости. Его все понимают — как браузеры,
так и веб-сервера. Что не надо городить своих стандартов и костылей в виде плагинов для всего мира.
А что какие-то поля не используются… Ну наверняка в Ваших сертификатах тоже не используются поля OU1..OU4. И будем из того трагедию создавать, и утверждать о неприменимости X.509 в https?
Фиктивный CА сделан исключительно для совместимости со стандарным механизмом проверки сертификатов, и его приватный ключ секретом не является. Основная проверка пользователя происходит при сравнении хешей.
> утверждаю, что в ваших сертификатах полезной нагрузкой является только публичный ключ.
Утверждение неверно. Ещё совершенно необходим Serial, который идентифицирует пользователя.
И ещё опционально используются другие поля — CN, UID, EMAIL. Но не суть важно.
Даже если Ваше высказывание было бы правдой — ну и что из того следует?
X.509 сертификат взят за основу именно из-за стандартности и распространённости. Его все понимают — как браузеры,
так и веб-сервера. Что не надо городить своих стандартов и костылей в виде плагинов для всего мира.
А что какие-то поля не используются… Ну наверняка в Ваших сертификатах тоже не используются поля OU1..OU4. И будем из того трагедию создавать, и утверждать о неприменимости X.509 в https?
Наш диалог мне всё больше напоминает вот эту цитату с bash.im.
Понимаете, давным-давно жили умные люди. И захотелось им чтобы было общее хранилище для всех цифровых идентификаторов пользователей. И придумали они стандарт X.500 — и возрадовались. Также были другие умные люди, которые решили, что стандарт X.500 уж больно сложен. И придумали они LDAP (Lightweight Directory Access Protocol), который был проще. Также умные люди придумали ещё один стандарт — X.509, дабы служил он для достоверной передачи сведений о пользователях и достоверной идентификации оных.
А потом, лет эдак через 20, появился чудесный продукт — EMCSSL. И придумали для этого продукта базу данных — «доверенный блокчейн». И хранила она пары «имя-значение» и были эти пары однозначно привязаны к пользователю. С сертификатами в этом продукте решили не заморачиваться, и использовали сильно обрезанные сертификаты из X.509.
А теперь по существу. Вашему «доверенный блокчейну» даже до упрощённых реализаций «X.500 directory» — как до Луны пешком. Все ваши «инновации» и «улучшение SSL» достигаются просто дополнительным уровнем проверки по вашей базе данных («доверенному блокчейну»). Всё это давным-давно возможно, и может быть реализовано гораздо более правильно путём использования стандартных «directories» с доступом по LDAP. Ваши «сертификаты» ущербны потому, что в них отсутствует корректное использование следующих полей:
1) subject;
2) notBefore + notAfter;
3) issuerUniqueID + subjectUniqueID;
4) ну и на сладкое — все поля из «extensions»;
Наверное кто-то решил, что эти поля в сертификатах вторичны. Конечно, зачем умные люди их придумали — мы же живём в «новой цифровой эпохе», тут у нас есть «доверенный блокчейн» :)
Кстати — полей «OU1...OU4» в сертификатах нет. Полагаю, что вы говорите про «organizationalUnitName», а это всего лишь один из элементов имени, используемый в полях сертификата «issuer», «subject» плюс в различных расширениях сертификата (поле «extensions»).
У меня есть куча других дел, кроме копания в вашей поделке. Если мои замечания для вас пустой звук, то мне на самом деле наплевать. Мои замечания здесь тогда будут оценивать другие читатели данной статьи.
Понимаете, давным-давно жили умные люди. И захотелось им чтобы было общее хранилище для всех цифровых идентификаторов пользователей. И придумали они стандарт X.500 — и возрадовались. Также были другие умные люди, которые решили, что стандарт X.500 уж больно сложен. И придумали они LDAP (Lightweight Directory Access Protocol), который был проще. Также умные люди придумали ещё один стандарт — X.509, дабы служил он для достоверной передачи сведений о пользователях и достоверной идентификации оных.
А потом, лет эдак через 20, появился чудесный продукт — EMCSSL. И придумали для этого продукта базу данных — «доверенный блокчейн». И хранила она пары «имя-значение» и были эти пары однозначно привязаны к пользователю. С сертификатами в этом продукте решили не заморачиваться, и использовали сильно обрезанные сертификаты из X.509.
А теперь по существу. Вашему «доверенный блокчейну» даже до упрощённых реализаций «X.500 directory» — как до Луны пешком. Все ваши «инновации» и «улучшение SSL» достигаются просто дополнительным уровнем проверки по вашей базе данных («доверенному блокчейну»). Всё это давным-давно возможно, и может быть реализовано гораздо более правильно путём использования стандартных «directories» с доступом по LDAP. Ваши «сертификаты» ущербны потому, что в них отсутствует корректное использование следующих полей:
1) subject;
2) notBefore + notAfter;
3) issuerUniqueID + subjectUniqueID;
4) ну и на сладкое — все поля из «extensions»;
Наверное кто-то решил, что эти поля в сертификатах вторичны. Конечно, зачем умные люди их придумали — мы же живём в «новой цифровой эпохе», тут у нас есть «доверенный блокчейн» :)
Кстати — полей «OU1...OU4» в сертификатах нет. Полагаю, что вы говорите про «organizationalUnitName», а это всего лишь один из элементов имени, используемый в полях сертификата «issuer», «subject» плюс в различных расширениях сертификата (поле «extensions»).
У меня есть куча других дел, кроме копания в вашей поделке. Если мои замечания для вас пустой звук, то мне на самом деле наплевать. Мои замечания здесь тогда будут оценивать другие читатели данной статьи.
1. Что такое X.500 DSA и протокол DAP — знаю, сам это конфигурил в 1995-1998м когда-то.
2. Блокчейн не EMCSSL придумал, а Сатоши Накамото вообще-то. И на его доверенности функционирует сеть Биткоин.
3. Да, для авторизации используются обрезанные сертификаты, в которых некоторые поля не используются. Ну и что?
Можно подумать, что Вы всегда используете поле Location, и без использования этого поля https будет уязвим.
4. LDAP — использовать можно. Но это — централизованое хранилище, со всеми присущими ему недостатками. Например таким, что хозяин сервера волюнтаристки заменит мой сертификат в своей базе и пойдёт по всем моим акаунтам шарить.
3. Про поля — subject, etc. В обычном username/password тоже нет ничего из перечисленых Вами полей, а поди ж всё работает, и хватает. Почему Вы считаете использование этих полей необходимым в нашей системе? Как отсутствие этих полей повысит уязвисмость? Особенно при использовании блокчейна в качестве идеального CRL?
4. OU1-4: Да, перепутал-с по памяти с полями X.400. В X.509 там всё попроще будет, и вместо 4х OU — только один, без номера. Никто это поле практически не использует, вот и подзабыл точно структуру полей. Но всё равно мой изначальный вопрос остаётся — как тот факт, что в сертификате есть практически неиспользуемое поле, снижает защищённость https?
5. Ну и наплюйте.
Резюмирую:
Да, в EMCSSL сертификаты используются в весьма сокращённом виде, и часть функционала (CA+CRL) обеспечивается блокчейном. Не вижу в том трагедии. Также, как не вижу трагедии в использовании LDAP вместо полноценного DAP.
Понятно, что без блокчейна, только при использовании сертификатов, EMCSSL не будет обеспечивать безопасности. Ну так это ж и не предлагается. Зато с блокчейном — безопасность выше, чем при использовании классической PKI. Хотя бы потому, что в случае централизованного CА можно на этот СА надавить, чтоб выписал какой надо сертификат от любого имени.
2. Блокчейн не EMCSSL придумал, а Сатоши Накамото вообще-то. И на его доверенности функционирует сеть Биткоин.
3. Да, для авторизации используются обрезанные сертификаты, в которых некоторые поля не используются. Ну и что?
Можно подумать, что Вы всегда используете поле Location, и без использования этого поля https будет уязвим.
4. LDAP — использовать можно. Но это — централизованое хранилище, со всеми присущими ему недостатками. Например таким, что хозяин сервера волюнтаристки заменит мой сертификат в своей базе и пойдёт по всем моим акаунтам шарить.
3. Про поля — subject, etc. В обычном username/password тоже нет ничего из перечисленых Вами полей, а поди ж всё работает, и хватает. Почему Вы считаете использование этих полей необходимым в нашей системе? Как отсутствие этих полей повысит уязвисмость? Особенно при использовании блокчейна в качестве идеального CRL?
4. OU1-4: Да, перепутал-с по памяти с полями X.400. В X.509 там всё попроще будет, и вместо 4х OU — только один, без номера. Никто это поле практически не использует, вот и подзабыл точно структуру полей. Но всё равно мой изначальный вопрос остаётся — как тот факт, что в сертификате есть практически неиспользуемое поле, снижает защищённость https?
5. Ну и наплюйте.
Резюмирую:
Да, в EMCSSL сертификаты используются в весьма сокращённом виде, и часть функционала (CA+CRL) обеспечивается блокчейном. Не вижу в том трагедии. Также, как не вижу трагедии в использовании LDAP вместо полноценного DAP.
Понятно, что без блокчейна, только при использовании сертификатов, EMCSSL не будет обеспечивать безопасности. Ну так это ж и не предлагается. Зато с блокчейном — безопасность выше, чем при использовании классической PKI. Хотя бы потому, что в случае централизованного CА можно на этот СА надавить, чтоб выписал какой надо сертификат от любого имени.
Давно сюда не заходил.
Вы вообще представляете, что именно хранится в LDAP, а что на клиентской машине, у самого пользователя? LDAP это хранилище публичных данных (например публичных ключей). Для того, чтобы «шарить во вашим аккаунтам» необходим ещё и закрытый ключ, которого в LDAP нет (по-умолчанию).
4. LDAP — использовать можно. Но это — централизованое хранилище, со всеми присущими ему недостатками. Например таким, что хозяин сервера волюнтаристки заменит мой сертификат в своей базе и пойдёт по всем моим акаунтам шарить.
Вы вообще представляете, что именно хранится в LDAP, а что на клиентской машине, у самого пользователя? LDAP это хранилище публичных данных (например публичных ключей). Для того, чтобы «шарить во вашим аккаунтам» необходим ещё и закрытый ключ, которого в LDAP нет (по-умолчанию).
Кто мешает хозяину LDAPа сгенерить новую ключевую пару, и в моей LDAP-записи подменить мой публичный ключ на публичный ключ из этой пары? После чего со свежесгенерённым своим закрытым ключом шарить по всем моим акаунатам, которые эту LDAP-запись используют?
УЖАС!
Сертификаты выдаются удостоверяющим центром. И даже если LDAP и удостоверяющий центр были бы в руках одного администратора (таких примеров из реальной жизни у меня нет), то выпуск нового сертификата отражается в логах, увеличивается номер текущего сертификата и так далее. Все удостоверяющие центры проходят аудиты безопасности с различных сторон и так далее. Также для каждого удостоверяющего центра делается «модель угроз и нарушителя», где одной из основных угроз учитывается человеческий фактор обслуживающего персонала. И с предотвращением этой угрозы очень плотно работают.
Вы всё-таки почитайте на досуге про PKI (Public-Key Infrastructure) — много нового для себя узнаете.
Сертификаты выдаются удостоверяющим центром. И даже если LDAP и удостоверяющий центр были бы в руках одного администратора (таких примеров из реальной жизни у меня нет), то выпуск нового сертификата отражается в логах, увеличивается номер текущего сертификата и так далее. Все удостоверяющие центры проходят аудиты безопасности с различных сторон и так далее. Также для каждого удостоверяющего центра делается «модель угроз и нарушителя», где одной из основных угроз учитывается человеческий фактор обслуживающего персонала. И с предотвращением этой угрозы очень плотно работают.
Вы всё-таки почитайте на досуге про PKI (Public-Key Infrastructure) — много нового для себя узнаете.
UFO just landed and posted this here
Sign up to leave a comment.
Беспарольная авторизация и другие неявные возможности цифровых сертификатов