FreeRADIUS peap-mschapv2 + удостоверение сертификата

А «клиент» радиуса - это что именно?

В некоторых случаях точка доступа. Но насколько я понимаю, «клиент» радиуса - это посредник. А сертификаты сверяются на радиусе и машине пользователя.

Но насколько я понимаю, «клиент» радиуса - это посредник. А сертификаты сверяются на радиусе и машине пользователя.

Вижу здесь связку «но...а», предполагающую противоречие, но противоречия не вижу. Да, под «клиентом» я и имел в виду сервис, т.е. посредник с т.з. процесса аутентификации. Да, сервис получает сертификат клиента и передает его радиусу, проверяющему его правильность.

А сертификаты сверяются на радиусе и машине пользователя.

Здесь главный и первоочередной вопрос - умеет ли точка доступа (или другой клиент) осуществлять eat+tls с радиусом. Она это точно умеет?

Она это точно не умеет.

Ты такой разговорчивый.

Скажи уже, что она умеет из EAP'ов с проверкой сертификата, что ли.

:) Точка доступа позволяет авторизоваться на радиусе как клиент по «Secret Key». Больше ничего.

Если я сгенерю сертификат для радиуса и пользовательский зачем включать в эту схему еще и точку доступа? Ведь пользователь должен проверить верный ли радиус сервер, а не точка доступа.

Ну вот смотри.Здесь говорят снять галочку с «Проверять сертификат сервера»: Жмык!

В следующем окошке снимаем галку с «проверять сертификат сервера». Так как сертификаты у нас самосгенеренные при установке FreeRadius, Windows не сможет проверить их валидность (это будет показано чуть ниже).

Ведь пользователь должен проверить верный ли радиус сервер

Да с какой стати? Сам же выше совершенно правильно писал - клиент радиуса это и есть точка доступа. А клиент точки доступа (т.е. юзерское приложение) про радиус и знать не знает.

Я изначально потому и неправильно прочитал сам пост, что «радиус проверяет сертификат клиента» это правильное требование, а вот «клиент проверяет сертификат радиуса» - неправильное.

В чем проблема? Вы не можете нагуглить как собрать свой PKI с CA и остальной сертификационной мишурой?

А я, оказывается, ламер. Понаписал херни выше.

Ладно, а в чем проблема сертификатов нагенерить? Способ тот же, что и для eap-tls и чего угодно вообще (клиентских, разве что, генерить не нужно). Разве что требования вендоклиентов к серверным сертификатам надо поискать, может там нужны специфические расширения, SubjectAltName или еще что.

Почти решил. Нужно посоветоваться. В папке raddb есть папка certs там куча всяких сгенеренных при установке радиуса сертификатов, которые можно использоваться для тестирования. Для того чтобы сгенерить новые сертификаты для продакшена нужно использовать Makefile в папке certs. Как именно им пользоваться и что потом получится написано в README в папке certs.

Что касается уязвимостей. То в моем случае можно использовать EAP-TLS, авторизация будет проходить по сертификату. Для полноценного использования нужна дисциплина генерации и выдачи сертификатов, а также их удаления. Для того, чтобы обезопасить подключение к серверу нужно на клиенте настроить проверку сертификата сервера. Добавить корневой

ca.pem

server.pem

Не смотря на проведенные операции сервер будет принимать соединения без проверки себя.

Посоветуйте. Как можно обезопасить еще клиентов на которых проверка сертификата сервера не возможна.

Спасибо.

Не смотря на проведенные операции сервер будет принимать соединения без проверки себя.

Шта? Зачем серверу проверять себя?

без проверки себя

А что такое «проверка себя»?

Как можно обезопасить еще клиентов на которых проверка сертификата сервера не возможна.

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

Самый правильный путь это сгенерить корневой сертификат и подписывать им и серверные, и клиентские сертификаты (или, как у больших пацанов, корневой -> подразделения -> клиенты/серверы). Тогда придется раздать клиентам помимо собственно клиентских сертификатов еще и корневые, зато все будет работать как положено.

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

Проверять себя

Не правильно выразился. Я имел ввиду как со стороны сервера заставить клиента проверять сертификат сервера.

А что касатеся больших пацанов. Да это понятно, это круто. Но когда человек свалит ему сертификат нужно перевести в «недействительные» или просто уничтожить. Нужен немного другой подход. Тем более когда у тебя большой штат под каждого человека генерить сертиф. с ума сойти можно.

как со стороны сервера заставить клиента

Никак, конечно.

Но когда человек свалит ему сертификат нужно перевести в «недействительные» или просто уничтожить.

Отозвать. CRL, OCSP.

Нужен немного другой подход.

Биометрия пока почему-то не распространена, а лучше ничего не придумали.

Тем более когда у тебя большой штат под каждого человека генерить сертиф. с ума сойти можно.

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

Никак, конечно.

Ну вот поэтому и спрашивал.

Отозвать. CRL, OCSP.

Попытался общественно доступным языком написать

Биометрия пока почему-то не распространена, а лучше ничего не придумали.

Ну не почему-то. Штука не очень гибкая. Отпечатки пальцев можно подделать. Где-то была инструкция даже. Распознавание лица не очень точно зависит от многих факторов. Сетчатка дороговато, но алгоритмы похожи на распознавание лица. Все остальное относительно дорого и нужно с собой носить дополнительный девайс.

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

Ну да. Очень хотел обойтись без этого,т.к. PKI полезная и правильная вещь, но им нужно рулить. А заниматься этим нет особо времени.

PKI полезная и правильная вещь, но им нужно рулить. А заниматься этим нет особо времени.

Ты разрушаешь мне мозг.
«Хочу использовать клиентские сертификаты, но нет времени ими управлять». Ну как так можно, а?
И, возвращаясь к истокам темы, что там вообще может быть за «тривиальная атака» на mschap2, который идет внутри шифрованного канала?
И до кучи, что у тебя за клиенты такие, за которых ты так волнуешься, но при этом не можешь принудить их выставить правильные настройки подключения, с проверкой сертификата сервера?

BTW, не вижу, чем PKI принципиально сложнее горы текстовых паролей. Еще и проще местами вообще. Хоть не надо гонять юзера менять пароль после создания, и думать о том, что он же обязательно возьмет «1234321», да и тот на бумажке напишет.

Ты разрушаешь мне мозг.

Я не хотел.

«Хочу использовать клиентские сертификаты, но нет времени ими управлять». Ну как так можно, а?

Поясню. Если меня будет больше, то буду поддерживать. :)

И, возвращаясь к истокам темы, что там вообще может быть за «тривиальная атака» на mschap2, который идет внутри шифрованного канала?

Отвечу просто ссылками:
Первая
Вторая
Третья
Самая главная

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

Да клиенты самые обычные. Человек, который их администрирует задачи больше 10 кликов отправляет на аутсорс. Там вообще ппц.

Хоть не надо гонять юзера менять пароль после создания, и думать о том, что он же обязательно возьмет «1234321», да и тот на бумажке напишет.

Active Directory напомнит о смене.

А, так это «атака на слабую конфигурацию», тогда фиг с ней. Итак, мы выделили главный вопрос темы: как принудить юзеров держать галочку «проверять сертификат сервера» включенной. Причем, все виды галочек на всех видах устройств.

На что есть только один ответ: а вот хер его знает.

Не давать создавать подключение самому юзеру и молиться о том, чтобы он не никогда не пересоздавал и не редактировал его самостоятельно. Заткнуть максимальное количество возможностей для юзера сменить настройки подключения. Или искать сторонние решения. Вот, наверное, и всё.

Active Directory напомнит о смене

И запретит написать пароль на бумажке, угу)

Вдруг кто-то наткнется на эту тему. Вот староватая, но все еще актуальная информация по данного рода атакам.

Клац!