Re: Клиентские SSL-сертификаты + ngx_http_auth_basic_module

Илья Шипицин chipitsine на gmail.com
Сб Янв 2 08:47:57 UTC 2021


пт, 1 янв. 2021 г. в 22:47, Vladislav Shabanov <vlad.shabanov на gmail.com>:

> Добрый день!
>
> Хочу посоветоваться.
> Есть сервер, где зона «для сотрудников» закрыта двумя слоями авторизации:
> auth_basic
> + проверка на уровне приложения, с куками, сессиями и прочим.
>
> Отказываться от auth_basic не хочется:
>
>    - В коде приложения запросто могут быть ошибки. Забыли, например,
>    завернуть какую-нибудь функцию приложения в декоратор и получили дырку в
>    защите.
>    - Сессионную куку могут угнать. XSS, «мутные» плагины для браузеров и
>    т. д.
>    - Есть «интимная» статика, которую проверять через auth_request не
>    хочется, т.к. замедляет.
>
> Проблема в том, что большинство браузеров неудобно работают с basic_auth:
> Сафари под iPhone спрашивает пароль каждые несколько часов и даже не
> заморачивается, чтобы его запомнить. FireFox после рестарта показывает
> модальный диалог со вводом пароля в одном из окон и блокирует все остальные
> окна с тем же сайтом. Неудобно, короче.
>
> Настроил клиентские сертификаты. Есть сотни мануалов, ничего интересного.
> Но вот раздача сертификатов сотрудникам и установка их в браузеры – дело
> муторное. У каждого браузера свои тараканы, сложно объяснить сотруднику по
> телефону, как поставить сертификат в его браузер и т. д. А если сертификат
> устареет или придётся его отозвать, совсем беда.
>
> Поэтому решил сделать вот какую логику:
>
>    - Если браузер предъявил сертификат, то *auth_basic* не требуем.
>    - Если не предъявил, то пусть вводит логин+пароль через *auth_basic*.
>    - Проверка доступа на уровне приложения никуда не девается, работаем
>    по старому.
>
>
тут есть подводные камни как минимум с сафари.
браузер предъявил или браузер не предъявил на транспортном уровне работает
таким образом

1) в серверном SSL Hello выставляется флаг "хочу сертификат"
(вы можете намекнуть клиенту, на каких именно УЦ вы хотели бы видеть
сертификат, либо "*ssl_verify_client* optional_no_ca;", если вы готовы
принимать сертификат любого УЦ)

2) нормальный браузер реагирует так, если он видит, что у него нет
клиентских сертификатов на требуемом УЦ, он не пытается спросить у
пользователя, и отправляет запрос без сертификата

3) сафари будет требовать пользователя сертификат в любом случае

далее на стороне nginx можно настроить обработчик 496 ошибки, мы с таким
игрались, туда попадет трафик без клиентских сертов (и там вы сможете
реализовать нужную вам логику)




> Я не нашёл способа, как настроить конфиг nginx, чтобы эту логику
> реализовать. Конструкции с
>
> if $ssl_client_verify == "SUCCESS" {}
>
> несовместимы с auth_basic.
>


error_page 496 .....


>
> Пока придумал только одно: отпатчил *ngx_http_auth_basic_module.c*,
> сделал в нём директиву
>
> *auth_basic_skip_if_client_cert*    *on/off*
>
> по которой проверка пароля выключается, если предъявлен валидный
> клиентский сертификат.
>
> Вопросы:
>
>    1. Может быть, кто-то решал аналогичную задачу? Чтоб и два слоя защиты
>    для страховки и удобство в повседневной работе?
>
>
кроме описанной вами трудностей с доставкой и установкой клиентских сертов
еще есть неприятное поведение сафари


>
>    1. Существует ли решение без патча ngx_http_auth_basic_module.c?
>    2. Интересен ли кому-нибудь этот патч? Может, на моём велосипеде ещё
>    кто-нибудь хочет покататься? :)
>
>
как-то сейчас oauth более в тренде


>
> С уважением,
> Владислав
>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20210102/0068719a/attachment.htm>


Подробная информация о списке рассылки nginx-ru