ПРОЕКТЫ 


  АРХИВ 


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



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

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.