Re: Проброс SSL-аутентификации на backend
Бондарец Иван
bondarets at gmail.com
Sat Sep 5 22:57:16 MSD 2009
Тут не в технике проблема. Проблема в людях.
Пример: разработчики (некий аутсорс) выпустили новый релиз веб-приложения,
передали нашим тестировщикам. Тестировщики быстренько согласовали с админами
тест-бекенда, залили апдейт, погоняли тесты, потом уже спокойненько
согласовали план работ на внедрение в бой и в течение какого-то времени все
это безобразие внедряется в бой, с балансировщиками, фронтендами,
файерволами, айпиэсами и т.п.
Так вот, если мы внедрим аутентификацию на фронтенде и жестко всех заставим
работать через него, то в цепочку согласований-настроек войдет еще одно
подразделение, чего хотелось бы избежать.
5 сентября 2009 г. 20:36 пользователь Sergey Shepelev
<temotor at gmail.com>написал:
> Бекендом редиректите неавторизованных на фронтенд.
>
> 2009/9/5 Бондарец Иван <bondarets at gmail.com>:
> > Понятно, спасибо.
> > Я тоже предлагал аутентифицировать на фронтэнде, но некоторые категории
> > пользователей (админы, технологи, тестировщики-функциональщики, etc.)
> > зачастую ходят напрямую на backend, вот их-то запросы тоже нужно
> шифровать и
> > аутентифицировать (не все, а только обращения к приложениям с критичными
> с
> > точки зрения ИБ данным). Видимо придется вносить акцесс-лист на
> backend'е,
> > чтобы кроме фронтэнда никто не мог запрашивать, а всех этих товарищей
> > заставлять работать через фронтэнд. Но эта задачка может изрядно
> затянуться
> > в реализации, это ж нарушение священной мантры "работает - не трогай!",
> > будет много несогласных. К тому же сопровождение фронтэндов и бакэндов -
> > разные люди в разных отделах, т.е. при каждом изменении тетировщикам
> > придется согласовывать работы еще и на фронтэндах до начала
> функционального
> > тестирования, что однозначно внесет задержку в и так не быстрый
> процесс...
> > Всё же хочу еще раз уточнить - моя задачка не реализуема в принципе или
> не
> > реализуема средствами nginx? Может кому-то известны программы/железки,
> > которые умеют выполнять такую задачку?
> >
> > 5 сентября 2009 г. 17:06 пользователь Igor Sysoev <is at rambler-co.ru>
> > написал:
> >>
> >> 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
> >>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20090905/e5e3b09c/attachment.html>
More information about the nginx-ru
mailing list