Re: PKI self-service

2016-09-15 9:04 GMT+03:00 Victor Wagner <vitus@wagner.pp.ru>:

On Thu, 15 Sep 2016 08:27:40 +0300
Bogdan <bogdar@gmail.com> 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