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
|