ПРОЕКТЫ 


  АРХИВ 


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: Mutual authentication средствами nginx



On 23.01.2014 13:50, Kostya Alexandrov wrote:

Если сертификат один для всех, то stunnel конфиг будет один,
если разные то опять же  один stunnel и адских размеров конфиг.

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

Если для каждого сайта свой сертификат, он должен быть пописан
> в конфиге nginx. Т.е. в любом случае все превращается в ночной кошмар.

А в чем проблема? nginx умеет работать с TLS SNI на стороне сервера.
Прописать один раз сертификат в конфиг сайта - это очень легко и просто.

"Научить админку" - верный вариант, никакого layering violation нет.
Здравый смысл violation решать вебсервером не свойственные ему задачи.

layer nginx - работает с MUTUAL AUTH TLS/SSL, маршрутизирует запросы
layer backend - общается только со своим nginx по протоколу http.

перенос логики создания исходящих HTTPS-соединений на уровень backend`а
- это как раз и будет нарушение исходной схемы разделения логики на слои

Потому что тут же надо будет вручную делать и логику модуля upstream,
балансировки нагрузки и прочих прелестей. Т.е. переписывать часть nginx
на backend`е. Разве это не является явным признаком layering violation ?

Плюс, подумайте о ресурсах. Если админка научится ходить по https - то
это одно соединение, если ходит через  nginx то как минимум два.

С таким же успехом можно агитировать убрать nginx из схемы nginx+apache
или nginx+tomcat, "чтобы использовалось меньшее количество соединений".

Если через nginx - то как минимум nginx должен держать все ваши сотни
сертификатов впамяти, или грузить их по необходимости, зная какой где и
зачем. Это полный overkill.

Размер SSL сертификата, грубо говоря, два килобайта. Если админка делает
исходящие соединения - она предъявляет свой сертификат. А он всего один.

Если на хостинговой машине в одном контейнере несколько сайтов - то да,
каждый сайт предъявляет свой собственный сертификат. Но в чем проблема?

Самый врный вариант работы с удалнными сервисами с защитой соединения
это VPN, Вы подумайте сами во что превращается каждый вызов по https
в Вашем случае, один хендшейк будет стоит как сотни плейн вызовов.

с OpenVPN есть нюансы при их настройке внутри OpenVZ контейнеров.
Кроме того, OpenVPN для доступа к одному HTTPS-порту - это overkill.

Тем более, что OpenVPN уже используется для создания VPN, а сайты
под управлением админки могут быть как внутри "локальной сети",
так и снаружи - на других (не на моих) серверах в интернете.
Делать для админки OpenVPN over OpenVPN - это будет слишком.

Сорри за оффтоп.

Вроде ж не оффтоп, мы же тут обсуждаем как это лучше сделать
с помощью nginx и почему все остальные варианты намного хуже.

--
Best regards,
 Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.