ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Проброс SSL-аутентификации на backend



2009/9/5 Бондарец Иван <bondarets@xxxxxxxxx>:
> Тут не в технике проблема. Проблема в людях.
> Пример: разработчики (некий аутсорс) выпустили новый релиз веб-приложения,
> передали нашим тестировщикам. Тестировщики быстренько согласовали с админами
> тест-бекенда, залили апдейт, погоняли тесты, потом уже спокойненько
> согласовали план работ на внедрение в бой и в течение какого-то времени все
> это безобразие внедряется в бой, с балансировщиками, фронтендами,
> файерволами, айпиэсами  и т.п.
> Так вот, если мы внедрим аутентификацию на фронтенде и жестко всех заставим
> работать через него, то в цепочку согласований-настроек войдет еще одно
> подразделение, чего хотелось бы избежать.
>

Ясно.

"Возникла задачка аутентифицировать пользователей на некоторых
разделах сайта на backend'e при помощи сертификатов"

вот эту задачу можно решить только, если пользователь будет конектится
непосредственно к бекенду.

Но, можно чтоб nginx проверял сертификаты и что-то вроде

proxy_set_header x-ssl-cert-dn $ssl_client_s_dn;
proxy_pass http://backend;

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

> 5 сентября 2009 г. 20:36 пользователь Sergey Shepelev <temotor@xxxxxxxxx>
> написал:
>>
>> Бекендом редиректите неавторизованных на фронтенд.
>>
>> 2009/9/5 Бондарец Иван <bondarets@xxxxxxxxx>:
>> > Понятно, спасибо.
>> > Я тоже предлагал аутентифицировать на фронтэнде, но некоторые категории
>> > пользователей (админы, технологи, тестировщики-функциональщики, etc.)
>> > зачастую ходят напрямую на backend, вот их-то запросы тоже нужно
>> > шифровать и
>> > аутентифицировать (не все, а только обращения к приложениям с критичными
>> > с
>> > точки зрения ИБ данным). Видимо придется вносить акцесс-лист на
>> > backend'е,
>> > чтобы кроме фронтэнда никто не мог запрашивать, а всех этих товарищей
>> > заставлять работать через фронтэнд. Но эта задачка может изрядно
>> > затянуться
>> > в реализации, это ж нарушение священной мантры "работает - не трогай!",
>> > будет много несогласных. К тому же сопровождение фронтэндов и бакэндов -
>> > разные люди в разных отделах, т.е. при каждом изменении тетировщикам
>> > придется согласовывать работы еще и на фронтэндах до начала
>> > функционального
>> > тестирования, что однозначно внесет задержку в и так не быстрый
>> > процесс...
>> > Всё же хочу еще раз уточнить - моя задачка не реализуема в принципе или
>> > не
>> > реализуема средствами nginx? Может кому-то известны программы/железки,
>> > которые умеют выполнять такую задачку?
>> >
>> > 5 сентября 2009 г. 17:06 пользователь Igor Sysoev <is@xxxxxxxxxxxxx>
>> > написал:
>> >>
>> >> On Sat, Sep 05, 2009 at 04:17:32PM +0400, Igor Sysoev wrote:
>> >>
>> >> > On Sat, Sep 05, 2009 at 01:36:22PM +0400, Бондарец Иван wrote:
>> >> >
>> >> > > Добрый день!
>> >> > > Есть стандартная схема:
>> >> > > Интернет -> nginx --> backend (Apache либо WebSphere)
>> >> > > nginx сейчас терминирует на себе ssl и проксирует на backend.
>> >> > > Возникла задачка аутентифицировать пользователей на некоторых
>> >> > > разделах
>> >> > > сайта
>> >> > > на backend'e при помощи сертификатов. Можно ли настроить nginx на
>> >> > > такой
>> >> > > режим работы? В моем понимании, на backend'е нужно поднять ssl (с
>> >> > > более
>> >> > > слабым ключом, например) и настроить авторизацию по сертификатам,
>> >> > > это
>> >> > > я
>> >> > > сделал:
>> >> > > SSLEngine on
>> >> > > SSLCipherSuite
>> >> > >
>> >> > >
>> >> > > ALL:!ADH:!DH:!EDH:!KRB5:!IDEA:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
>> >> > > SSLCertificateFile /etc/apache2/ssl.crt/apache.crt
>> >> > > SSLCertificateKeyFile /etc/apache2/ssl.key/apache.key
>> >> > > SSLProtocol +SSLv3 +TLSv1
>> >> > > SSLVerifyClient require
>> >> > > SSLCACertificateFile /path/to/ca.crt
>> >> > >
>> >> > >  Далее в конфиге nginx пишу:
>> >> > >     server {
>> >> > >         listen       443;
>> >> > >         server_name  test1;
>> >> > >         ssl                  on;
>> >> > >         ssl_certificate      /etc/apache2/ssl.crt/apache.crt;
>> >> > >         ssl_certificate_key  /etc/apache2/ssl.key/apache.key;
>> >> > >
>> >> > >         ssl_session_timeout  5m;
>> >> > >
>> >> > >         ssl_protocols  SSLv2 SSLv3 TLSv1;
>> >> > >         ssl_ciphers
>> >> > >
>> >> > >
>> >> > > ALL:!ADH:!DH:!EDH:!KRB5:!IDEA:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL;
>> >> > >         ssl_prefer_server_ciphers   on;
>> >> > >         location / {
>> >> > >         proxy_pass   https://1.2.3.4:443;
>> >> > >             }
>> >> > >
>> >> > >        }
>> >> > >
>> >> > > Проверяю аутентификацию при обращении непосредственно к backend'у -
>> >> > > на
>> >> > > IE6,7,8 и Safari 4.0.2 работает, на FF 3.5.2, Opera 10, Chrome - не
>> >> > > работает, пишет что-то вроде этого:
>> >> > > SSL-узлу не удалось договориться о приемлемом наборе параметров
>> >> > > безопасности.
>> >> > > (Код ошибки: ssl_error_handshake_failure_alert)
>> >> > >
>> >> > > Пробую через nginx, соответственно тоже не работает, в логе nginx
>> >> > > пишет:
>> >> > > [error] 14221#0: *106 SSL_do_handshake() failed (SSL:
>> >> > > error:14094410:SSL
>> >> > > routines:SSL3_READ_BYTES:sslv3 alert handshake failure) while SSL
>> >> > > handshaking to upstream
>> >> > >
>> >> > > Как это поправить? И вообще реализуема ли задачка, описанная в
>> >> > > начале?
>> >> > > Т.е.
>> >> > > аутентификация пользователей именно на backend'е?
>> >> >
>> >> > В таком виде - нет, потому что nginx не передаёт клиентский
>> >> > сертификат
>> >> > в proxy_pass.
>> >>
>> >> А кроме того, это технически невозможно, потому что, даже передав
>> >> клиентский сертификат, nginx не сможет его подтвердить, не имея
>> >> клиентского приватного ключа.
>> >>
>> >> > Можно аутентифицировать на nginx'е, а результат проверки
>> >> > и прочие ssl-параметры передавать бэкенду без https:
>> >> >
>> >> >    server {
>> >> >       ssl_verify_client   optional;
>> >> >
>> >> >
>> >> >
>> >> > http://sysoev.ru/nginx/docs/http/ngx_http_ssl_module.html#ssl_verify_client
>> >> > http://sysoev.ru/nginx/docs/http/ngx_http_ssl_module.html#variables
>> >>
>> >>
>> >> --
>> >> Игорь Сысоев
>> >> http://sysoev.ru
>> >>
>> >
>> >
>
>


 




Copyright © Lexa Software, 1996-2009.