Re: PKI self-service

[Bogdan]

2016-09-15 18:08 GMT+03:00 Tim Sattarov :

> On 15/09/16 01:27 AM, Bogdan wrote:
> > Добрый день!
> >
> > Спасибо за ответы, судя по всему готового решения нет (что крайне
> > странно). Писать самостоятельно продукт такого рода - опасно и дорого.
> > FreeIPA смотрю, но так и не понял пока, где там могла бы быть подобная
> > функциональность.
> >
> FreeIPA это обертка вокруг BIND, ds389, dogtag и так далее. Как раз таки
> dogtag и выполняет функции  CA.
>

Вот к сожалению отдельно в dogtag нужного функционала нет, это просто CA,
всё остальное - внутри "комбайна".


>
> я не так давно был на конференции Hashconf, где обсуждался их новый
> продукт: Vault. в числе других задач он тоже может быть CA для организации.
> open source :)
> https://www.vaultproject.io/


Спасибо, посмотрю.



-- 
WBR,  Bogdan B. Rudas

Re: PKI self-service

[Tim Sattarov]

On 15/09/16 01:27 AM, Bogdan wrote:
> Добрый день!
>
> Спасибо за ответы, судя по всему готового решения нет (что крайне
> странно). Писать самостоятельно продукт такого рода - опасно и дорого.
> FreeIPA смотрю, но так и не понял пока, где там могла бы быть подобная
> функциональность.
>
FreeIPA это обертка вокруг BIND, ds389, dogtag и так далее. Как раз таки
dogtag и выполняет функции  CA.

я не так давно был на конференции Hashconf, где обсуждался их новый
продукт: Vault. в числе других задач он тоже может быть CA для организации.
open source :)
https://www.vaultproject.io/

Re: PKI self-service

[Коротаев Руслан]

В сообщении от [Чт 2016-09-15 12:53 +0300]
Bogdan  пишет:

> Доступные мне протоколы авторизации позволяют передавать только плейнтекст,
> либо заведомо уязвимые хэши паролей (md5 или ntlm) поверх TLS-сессии.
> Защищенность такой сессии зависит исключительно от корректности настройки
> (принудительная проверка "моего" CA) на стороне клиента, который будет
> выполнять настройки подключения сам. Honeypot и/или MitM  технически просты и
> достаточно вероятны в силу передачи данных по незащищенной и неконтролируемой
> среде. Я хочу полностью отказаться от такого типа авторизации в сервисе и
> перейти на авторизацию с использованием PKI. Вероятность успешного MitM/
> honeypot для веб-сайта раздающего сертификаты существенно меньше, чем для
> целевого сервиса.

Вы опасаетесь что с помощью MitM взломают TLS-сессию и поэтому хотите
авторизацию по сертификату клиента. Это маловероятно, конечно такое
решение надежно, но очень не удобно. Хотя если у вас клиенты технически
подкованные, например хранят сертификат и ключ на смарткарте, то да, а
так есть и другие варианты [1]. 

Кстати, вчера вы спрашивали насчет проверки отозванных сертификатов,
оказывается есть простой вариант OCSP-сервера [2] (CRL считается
устаревшим). Смысл такой, поднимаем OCSP-сервер например,
http://ocsp.example.com, прописываем его в сертификате и браузер сам
будет проверять отозванные сертификаты, детали здесь [3]. Причем
OCSP-ответы не обязательно подписывать тем же ключом что и сертификат,
можно выписать дополнительный сертификат специально для OCSP. То есть
центр сертификации может (или должен) быть не подключенным к сети, а
работу с OCSP можно доверить другой организации.

Однако, это всё типовые решения, вам судя по всему они не подходят, у
вас какой-то интересный сервис, если вы опишите общую архитектуру или
поставленную задачу, тогда и ответы могут быть поточнее.

[1]: https://habrahabr.ru/company/dataart/blog/262817/
[2]: http://backreference.org/2010/05/09/ocsp-verification-with-openssl/
[3]: 
https://jamielinux.com/docs/openssl-certificate-authority/online-certificate-status-protocol.html

-- 
Коротаев Руслан
https://blog.kr.pp.ru

Re: PKI self-service

[Bogdan]

2016-09-15 13:37 GMT+03:00 Victor Wagner :

> On Thu, 15 Sep 2016 12:53:06 +0300
> Bogdan  wrote:
>
> >
> > Если я правильно интерпретировал документацию. то готовое решение -
> > это Auto Enrollment в Microsoft Active Directory Certification
> > Services -
> > https://technet.microsoft.com/en-us/library/cc771107(v=ws.11).aspx
> > т.е., но к сожалению работает только с AD :/
>
> Кстати, возможно что да. Те, кому нужен security theater будут
> использовать винду.
>
>
>
> >
> > Доступные мне протоколы авторизации позволяют передавать только
> > плейнтекст, либо заведомо уязвимые хэши паролей (md5 или ntlm) поверх
> > TLS-сессии. Защищенность такой сессии зависит исключительно от
> > корректности настройки (принудительная проверка "моего" CA) на
>
> Да, ну и что? Уязвимым местом является все равно  не TLS-сессия, а
> хранение пароля или закрытго ключа на устройстве пользователя и
> возможность внедрения к нему на устройство кейлоггера.


Этот риск в целом принят. Утечка сертификат менее болезненна, т.к. страдает
только один сервис. Если утечет пароль - появляется доступ в ряд других,
заметно более важных сервисов.


>
> Использование авторизации по сертификатам как правило, снижает
> usability сильнее чем повышает security.
>
> Если сервис использует публичное доменное имя и публичный CA (хотя бы и
> startssl.com или letsencrypt), то mitm-атака, позволяющая получить хеш
> от пароля требует серьезной организационной поддержки - компрометация
> публичного CA под силу, пожалуй, только спецслужбе государства.
>
>
Понятие доменного имени в принципе не применимо к данном сервису.

Теперь по сути вопроса: для автоматизации процессов вокруг CA и
сертификатов есть несколько протоколов (СMC, CMP, SCEP) из который SCEP
выглядит наиболее "живым". Ряд CA имеют automated SCEP workflow позволяющий
в т.ч. и обрабатывать CSR без подтверждения человеком, следовательно нужен
SCEP-клиент с веб-интерефейсом, способный авторизовать конечного
пользователя LDAP, сформировать SCEP-запрос и передать результат
пользователю.
Судя по комментариям в #dogtag, требуемый интерфейс есть во FreeIPA, но это
очередной комбайн который будет не может пока интегрироваться со внешним
LDAP.



-- 
WBR,  Bogdan B. Rudas

Re: PKI self-service

[Bogdan]

2016-09-15 9:04 GMT+03:00 Victor Wagner :

> On Thu, 15 Sep 2016 08:27:40 +0300
> Bogdan  wrote:
>
> > Добрый день!
> >
> > Спасибо за ответы, судя по всему готового решения нет (что крайне
> > странно). Писать самостоятельно продукт такого рода - опасно и дорого.
>
> Не то чтобы опасно и дорого. При предполагамемом (да и более высоком)
> уровне безопасности это пишется за полдя. Скорее как раз именно потому
> что трудно придумать решение, отвязанное от регламентов конкретной
> организации, тиражируемых продуктов и нет. Проще сделать свой,
> заточенный под свою схему безопасности, чем адаптировать процессы
> управления персоналом к готовому.
>
> > FreeIPA смотрю, но так и не понял пока, где там могла бы быть подобная
> > функциональность.
>
>
> Готового решения нет потому, что заявленный регламент работы
> противоречит базовым представлениям о безопасности тех, кто работает с
> криптографией.
>

Если я правильно интерпретировал документацию. то готовое решение - это
Auto Enrollment в Microsoft Active Directory Certification Services -
https://technet.microsoft.com/en-us/library/cc771107(v=ws.11).aspx т.е., но
к сожалению работает только с AD :/


>
> И в тех случаях, когда такой уровень безопасности считается достаточным,
> предпочитают обходиться вообще без сертификатов и PKI.
>
> А когда PKI все же нужна, предпочитают решения, в которых есть некий
> ответственный сотрудник, который знает пассфразу от ключа УЦ и
> проверяет что тот, кто пришел за сертификатом, именно он и есть.
> (в этом случае в маленькой фирме хватит чего-то типа tinyca, gnomint,
> pyca или даже easyrsa (входит в комплект openvpn).
>
> Ведь если у нас единственный proof of authencity который
> предоставляется при получении сертификата - это пароль хранящийся LDAP,
> то зачем нужна аутентификация по сертификату, когда проще везде
> аутентифицироваться оп  тому же самому паролю?
>


Доступные мне протоколы авторизации позволяют передавать только плейнтекст,
либо заведомо уязвимые хэши паролей (md5 или ntlm) поверх TLS-сессии.
Защищенность такой сессии зависит исключительно от корректности настройки
(принудительная проверка "моего" CA) на стороне клиента, который будет
выполнять настройки подключения сам. Honeypot и/или MitM  технически просты
и достаточно вероятны в силу передачи данных по незащищенной и
неконтролируемой среде. Я хочу полностью отказаться от такого типа
авторизации в сервисе и перейти на авторизацию с использованием PKI.
Вероятность успешного MitM/honeypot для веб-сайта раздающего сертификаты
существенно меньше, чем для целевого сервиса.



> Другие модели безопасности сравнимого уровня которые широко
> распространены, это пожалуй только domain-validadated only сертификаты
> для веб-серверов. Где проверяется что подавший заявку сертификат может
> по крайней мере выложить файлик на web-сервер с именем, на которое
> выписывается сертификат.
>
> По-моему в случае описанной задачи было бы логично генерировать для
> пользователя сертификат и ключевую пару в момент заведения его в LDAP и
> выдавать ему в виде PKCS12-файла и использовать автоматизированный
> rollover. Т.е. чтобы заявку на новый сертификат пользователь подписывал
> на старом.
>
> --
>
>
>


-- 
WBR,  Bogdan B. Rudas

Re: PKI self-service

[Victor Wagner]

On Thu, 15 Sep 2016 08:27:40 +0300
Bogdan  wrote:

> Добрый день!
> 
> Спасибо за ответы, судя по всему готового решения нет (что крайне
> странно). Писать самостоятельно продукт такого рода - опасно и дорого.

Не то чтобы опасно и дорого. При предполагамемом (да и более высоком)
уровне безопасности это пишется за полдя. Скорее как раз именно потому
что трудно придумать решение, отвязанное от регламентов конкретной
организации, тиражируемых продуктов и нет. Проще сделать свой,
заточенный под свою схему безопасности, чем адаптировать процессы
управления персоналом к готовому.

> FreeIPA смотрю, но так и не понял пока, где там могла бы быть подобная
> функциональность.


Готового решения нет потому, что заявленный регламент работы
противоречит базовым представлениям о безопасности тех, кто работает с
криптографией.

И в тех случаях, когда такой уровень безопасности считается достаточным,
предпочитают обходиться вообще без сертификатов и PKI. 

А когда PKI все же нужна, предпочитают решения, в которых есть некий
ответственный сотрудник, который знает пассфразу от ключа УЦ и
проверяет что тот, кто пришел за сертификатом, именно он и есть.
(в этом случае в маленькой фирме хватит чего-то типа tinyca, gnomint,
pyca или даже easyrsa (входит в комплект openvpn).

Ведь если у нас единственный proof of authencity который
предоставляется при получении сертификата - это пароль хранящийся LDAP, 
то зачем нужна аутентификация по сертификату, когда проще везде
аутентифицироваться оп  тому же самому паролю?

Другие модели безопасности сравнимого уровня которые широко
распространены, это пожалуй только domain-validadated only сертификаты
для веб-серверов. Где проверяется что подавший заявку сертификат может
по крайней мере выложить файлик на web-сервер с именем, на которое
выписывается сертификат.

По-моему в случае описанной задачи было бы логично генерировать для
пользователя сертификат и ключевую пару в момент заведения его в LDAP и
выдавать ему в виде PKCS12-файла и использовать автоматизированный
rollover. Т.е. чтобы заявку на новый сертификат пользователь подписывал
на старом. 

-- 

Re: PKI self-service

[Bogdan]

Добрый день!

Спасибо за ответы, судя по всему готового решения нет (что крайне странно).
Писать самостоятельно продукт такого рода - опасно и дорого.
FreeIPA смотрю, но так и не понял пока, где там могла бы быть подобная
функциональность.

2016-09-14 19:15 GMT+03:00 Tim Sattarov :

> On 14/09/16 04:55 AM, Bogdan wrote:
> > Добрый день!
> >
> > Ищу решение для самообслуживания: нужно дать возможность
> > авторизованным пользователям выпускать клиентские сертификаты и
> > автоматически подписывать их специальным отдельным CA-ключем.
> >
> > Авторизация пользователей - во LDAP. Очень желательно иметь
> > автоматическое управление CRL/OCSP (пользователь пропал из LDAP - все
> > его сертификаты автоматически отзываются)
> Как вариант можно посмотреть на FreeIPA, но под Дебьян он ущербный и не
> самой последней версии.
>
>


-- 
WBR,  Bogdan B. Rudas

Re: PKI self-service

[Tim Sattarov]

On 14/09/16 04:55 AM, Bogdan wrote:
> Добрый день!
>
> Ищу решение для самообслуживания: нужно дать возможность
> авторизованным пользователям выпускать клиентские сертификаты и
> автоматически подписывать их специальным отдельным CA-ключем.
>
> Авторизация пользователей - во LDAP. Очень желательно иметь
> автоматическое управление CRL/OCSP (пользователь пропал из LDAP - все
> его сертификаты автоматически отзываются)
Как вариант можно посмотреть на FreeIPA, но под Дебьян он ущербный и не
самой последней версии.

Re: PKI self-service

[Коротаев Руслан]

В сообщении от [Ср 2016-09-14 11:55 +0300]
Bogdan  пишет:

> Ищу решение для самообслуживания: нужно дать возможность авторизованным
> пользователям выпускать клиентские сертификаты и автоматически подписывать их
> специальным отдельным CA-ключем.
> 
> Авторизация пользователей - во LDAP. Очень желательно иметь автоматическое
> управление CRL/OCSP (пользователь пропал из LDAP - все его сертификаты
> автоматически отзываются)
> 
> Как такой тип ПО вообще правильно называется, задача очевидная и должна иметь
> ряд решений, но не могу задать правильный вопрос гуглу.

Если вы спрашиваете про инструменты, то значит вы ещё не создали свой
центр сертификации, тогда у гугла можно спросить: «Как создать
собственный центр сертификации?» В самом простом случае это выглядит
как-то так [1], ну а дальше смотреть как можно выдавать доверенности на
выпуск сертификатов, работать с отозванными и какие инструменты
использовать.

[1]: 
http://help.ubuntu.ru/wiki/руководство_по_ubuntu_server/безопасность/certificates

-- 
Коротаев Руслан
https://blog.kr.pp.ru

Re: PKI self-service

[Victor Wagner]

On Wed, 14 Sep 2016 12:57:55 +0300
Eugene Berdnikov  wrote:

> On Wed, Sep 14, 2016 at 11:55:21AM +0300, Bogdan wrote:
> > Ищу решение для самообслуживания: нужно дать возможность
> > авторизованным пользователям выпускать клиентские сертификаты и
> > автоматически подписывать их специальным отдельным CA-ключем.  
> 
>  "Автоматически подписывать их специальным отдельным CA-ключем"
> означает, что это ключ должен быть нешифрован и находиться в сетевом
> доступе.

Что он должен находиться в сетевом доступе - не значит.

Он может находиться на отдельном компьютере, изолированном от сети.
Главное, чтобы существовала автоматическая процедура, позволяющая
забрать по какому-то каналу (не обязательно являющемуся полноценной
сетью, предоставляющей полноценный удаленный доступ), заявки и вернуть
подписанные сертификаты, выполнив в процессе произвольное количество
проверок.

Мы, например как-то разрабатывали конструкцию, когда собственно УЦ
коннектился к регистрирующему центру (имеющему сетевой доступ) через 
последовательный порт и изображал из себя юзера последовательного
терминала, получая заявки с помощью команды cat и в нее же передавая
подписанные сертификаты.

Кроме того, ключ CA может хранится в аппаратном токене. Это несколько
меньший уровень защищенности, так как человек, получивший рутовый
доступ к компьютеру, куда воткнут токен, может подписать на нем что
угодно, но существенно более высокий чем хранение ключа в файле,
который злоумышленник может скопировать.

> 
> > Авторизация пользователей - во LDAP. Очень желательно иметь
> > автоматическое управление CRL/OCSP (пользователь пропал из LDAP -
> > все его сертификаты автоматически отзываются)  
> 
>  И для этой задачи нужно держать нешифрованный ключ CA в сетевом
> доступе.

Тут тем более все не так. Ключ OCSP-респондера и ключ CA это в общем
случае разные ключи. И протокол OCSP сдизайнен таким образом именно
потому, что ключ OCSP-респондера должен использоваться для выработки
подписей на компьютере, подключенном к сети.

Ну и вообще для специализированного СA, клиентские сертификаты которого
дают доступ только к ограниченному набору сервисов, например vpn,
наличие ключа на компьютере с сетевым доступом не обязательно является
неприемлемым секьюрити-риском.

Кстати, рекомендую внимательно прочитать раздел PATH PHRASE ARGUMENTS в
openssl(1). То, что там написано может помочь избежать хранения
незашифрованного ключа и пассфразы к зашифрованному ключа на диске
компьютера, подключенного к сети, аналогично тому как ключи для ssh
или gpg хранятся в памяти специальной  программы-агента.

 
>  Правильный ответ: openssl и руки. В модуле "ca" есть вполне рабочий
> набор функционала для массовой (поточной) обработки, который можно
> вставить в полностью автоматизированную среду. Проверено, работает.

На самом деле это не совсем правильный ответ. Потому что написание
удостоверяющих центров, тем более таких, от которых требуется высокая
usability, которая, как известно, прямо противоречит security, задача,
имеющая уйму тонкостей. Поэтому посмотреть на известные реализации было
бы крайне полезно. Но, к сожалению посоветовать реализацию, у которой
стоит поучиться "как надо" я не могу. Можно на примере разных
реализаций клиента Let's Encrypt разобрать "как совсем не надо", и "как
относительно приемлемо".

Re: PKI self-service

[Eugene Berdnikov]

On Wed, Sep 14, 2016 at 11:55:21AM +0300, Bogdan wrote:
> Ищу решение для самообслуживания: нужно дать возможность авторизованным
> пользователям выпускать клиентские сертификаты и автоматически подписывать
> их специальным отдельным CA-ключем.

 "Автоматически подписывать их специальным отдельным CA-ключем" означает,
 что это ключ должен быть нешифрован и находиться в сетевом доступе.

> Авторизация пользователей - во LDAP. Очень желательно иметь автоматическое
> управление CRL/OCSP (пользователь пропал из LDAP - все его сертификаты
> автоматически отзываются)

 И для этой задачи нужно держать нешифрованный ключ CA в сетевом доступе.

> Как такой тип ПО вообще правильно называется, задача очевидная и должна
> иметь ряд решений, но не могу задать правильный вопрос гуглу.

 Правильный ответ: openssl и руки. В модуле "ca" есть вполне рабочий набор
 функционала для массовой (поточной) обработки, который можно вставить
 в полностью автоматизированную среду. Проверено, работает.
-- 
 Eugene Berdnikov

Re: PKI self-service

[Victor Wagner]

On Wed, 14 Sep 2016 11:55:21 +0300
Bogdan  wrote:

> Добрый день!
> 
> Ищу решение для самообслуживания: нужно дать возможность
> авторизованным пользователям выпускать клиентские сертификаты и
> автоматически подписывать их специальным отдельным CA-ключем.
> 
> Авторизация пользователей - во LDAP. Очень желательно иметь
> автоматическое управление CRL/OCSP (пользователь пропал из LDAP - все
> его сертификаты автоматически отзываются)
> 
> Как такой тип ПО вообще правильно называется, задача очевидная и
> должна иметь ряд решений, но не могу задать правильный вопрос гуглу.
> 
> Спасибо.
> 

Такой тип ПО называется "Удостоверяющий центр" или "Certification
authority". Вот только готовых тиражируемых решений для вот такого
(экстремально низкого) уровня безопасности, когда авторизованный
пользователь может сам себе без дополнительных проверок выписать
клиентский сертификат, я не знаю.

EasyRSA она все таки про случай, когда все сертификаты под контролем
одного системного администратора.

Так то в принципе оно за полдня пишется на базе утилиты openssl.
Только еще какой poll для ldap придется написать, чтобы отслеживать
изменения в ldap. И понадобится явно интерфейс для отзыва сертификата
авторизованным пользователем без удаления этого пользователя из ldap.
--

PKI self-service

[Bogdan]

Добрый день!

Ищу решение для самообслуживания: нужно дать возможность авторизованным
пользователям выпускать клиентские сертификаты и автоматически подписывать
их специальным отдельным CA-ключем.

Авторизация пользователей - во LDAP. Очень желательно иметь автоматическое
управление CRL/OCSP (пользователь пропал из LDAP - все его сертификаты
автоматически отзываются)

Как такой тип ПО вообще правильно называется, задача очевидная и должна
иметь ряд решений, но не могу задать правильный вопрос гуглу.

Спасибо.

-- 
WBR,  Bogdan B. Rudas