Re: Mutual authentication средствами nginx

[Gena Makhomed <gmm@xxxxxxxxx>]

On 23.01.2014 13:53, Илья Шипицин wrote:

> > Еще одной точки отказа тут нет, nginx в любом случае используется.
> > nginx стартует с рутовыми правами и доступ к сертификатам у него есть.
> > Если сервер не принял сертификат - значит у этого клиента доступа нет.
> еще одна точка отказа тут есть.
> nginx предъявляет свой сертификат серверу, сервер может отказать либо
> потому что у пользователя нет доступа, либо в силу того, что сервер не
> смог скачать CRL
Какая разница, кто делает исходящий https-запрос - nginx или backend ?
Тем более, что CRL скачивать не надо - это локальный файл. Экзотические
варианты "сломалась файловая система" и т.п. предлагаю не рассматривать.

> надо либо в одном случае возвращать "temp fail", в другом "perm fail",
> либо что-то еще, но логику отработки ошибок надо как-то реализовывать на
> стороне приложения
Почему надо возвращать "temp fail", если у пользователя нет доступа?
Доступа нет, а потом он появляется? Так бывает только в анекдотах:

Китайцы взломали сервер Пентагона, вот как это было:
1. Каждый китаец попробовал один пароль.
2. Каждый второй пароль был "Мао Цзедун"
3. На 74357181-й попытке- сервер согласился, что у него пароль "Мао Цзедун"

> > Если вся логика работы с TLS/SSL будет только на уровне nginx - это
> > нормально, а если часть там, часть там - то это layering violation.
> если вся логика с ssl на стороне nginx, это точка отказа
Если используется только nginx - новых точек отказа не добавляется.
Если использовать еще дополнительно stunnel или OpenVPN - тогда
в системе появляются новые точки отказа, которых до того не было.

> > необязательно на C/C++, можно на nginx-lua за полдня набросать
> > то, что вы хотите.
>     Каким образом, разве nginx-lua сможет добавить к proxy_pass
>     ту функциональность, которой там сейчас нет, в частности, передачу
>     на удаленный сервер клиентского сертификата и проверку серверного?
>
> content_by_lua и любой креатив в ваших силах
> ценой, возможно, большого оверхеда
http://wiki.nginx.org/HttpLuaModule#content_by_lua

Acts as a "content handler" and executes Lua code string specified in 
<lua-script-str> for every request. The Lua code may make API calls and 
is executed as a new spawned coroutine in an independent global 
environment (i.e. a sandbox).
Чем поможет "make API calls", если в nginx этой функциональности нет?

> > Логично же делать максимальный уровень защиты
> > через Mutual authentication между сервисами.
> у нас одна из любимых ошибок - "неидемпотентность сервиса", то есть, к
> примеру есть несколько экземпляров одного сервиса. мы обращаемся к
> сервису, делаем запрос "поменяй то-то и то-то", запрос уходит в таймаут,
> что делать ?
>
> идеальной была бы ситуация, когда многократно выполенный запрос не
> приводил бы к многократному изменению данных (это ведь, по сути, один и
> тот же запрос). такие типы сервисов называются "идемпотентными".
>
> если сервис таким свойством не обладает, в каких-то случаях лучше
> зафейлиться, чем уходить на следующую реплику
>
> а теперь представьте, что вы "прячете" топологию сервисов за nginx, все
> становится еще сложнее, у nginx в коде события "tcp connect timeout"
> (когда запрос не ушел и безопасно его еще раз повторить) и "http
> response timeout" (когда надо быть максимально аккуратным) выглядят
> одинаково
>
> кстати, надо будет патч на эту тему сделать ))
Прятать топологию сервисов за nginx - это имхо общепринятая практика.
Если один backend не смог ответить на запрос - он направляется
на обработку другому.

Да, сервисы желательно делать идемпотентными. Это понятно.
Но к вопросу создания Mutual authentication между сервисами
средствами nginx вопросы идемпотентности какое имеют отношение?

Грубо говоря, Mutual authentication с помощью "магии"
превращает незащищенное http соединение в высокозащищенное
HTTPS соединение. А софт на backend`е об этом не должен знать,
точно так же как он не должен знать про особенности работы TCP
протокола или про нюансы маршрутизации IP пакетов в сетях Ethernet.

Вот потому и говорю, что по моим ощущениям, переносить логику работы
с Mutual authentication на backend - это есть 100% layering violation.

>     Вот например, реальная задача. Есть небольшой хостинг -
>     несколько десятков сайтов, которые созданы под заказ.
>
>     Вместо того, чтобы для каждого сайта создавать свою админку,
>     цеплять к ней SSL-сертификат, - проще и удобнее сделать всего
>     одну админку, куда будут заходить пользователи по https,
>     и там они смогут управлять своими сайтами. А сами сайты:
>
>     www.example.com <http://www.example.com> - сюда ходят пользователи сайта
>     api.example.com <http://api.example.com> - сюда ходит админка с
>     Mutual authentication
>
>     Сейчас - сайтов десятки, потом может быть сотни и тысячи.
>     И что делать, настраивать и поддерживать в живом состоянии
>     сотни и тысячи stunnel`ей? Каждому выделяя свой отдельный
>     порт на стороне контейнера с админкой? Это будет nightmare.
>     Практически это нереальный вариант. Наверное придется таки
>     идти на layering violation и обучать админку делать https-
>     запросы с предъявлением клиентского сертификата через curl.
>
> реальна задача- это замечательно, но я не понял, в каком месте возникает
> профит от mutual authentication, вероятно, надо больше деталей
Клиентские сайты могут быть размещены как на серверах компании,
которая занималась созданием этих сайтов, так и на собственных
серверах клиента. Управлять желательно и теми и теми одинаковым
образом из одной админки, чтобы не было "вагонов двух типов" -
про которые говорил Дейкстра в своей знаменитой притче:
http://www.vspu.ac.ru/~chul/dijkstra/pritcha/pritcha.htm

> если вы хотите проверять серты на nginx и сообщать приложению, это
> делается через переменные nginx, у нас такой сценарий используется, могу
> конфиги помочь составить
Серверную часть " ... =(HTTPS)=> nginx2 =(http)=> tomcat2"
я уже настроил и здесь все работает просто отлично.

Кстати, сообщать приложению о том, что кто-то пытается
подключиться к api.example.com с невалидным сертификатом
не надо, смысла в этом никакого нет.

Проблемы осталась пока что только с настройкой
вот этой части: "tomcat1 =(http)=> nginx1 =(HTTPS)=> ..."
Не получается сделать так, чтобы nginx1 предъявлял удаленному
сервису свой клиентский сертификат и проверял сертификат
удаленного сервиса.

>     ==============================__============================
>
>     Вторая задача - это большой веб-сервис, который построен
>     с использованием Micro Service Architecture, физически
>     размещен на нескольких серверах с горизонтальным масштабированием
>
> nginx ломает идею горизонтального масштабирования, или вы планируете
> горизонтально плодить много экземпляров nginx?
Если есть 25 экземпляров tomcat`а - и каждый из них делает исходящие
запросы через свой nginx на 127.0.0.1:8080 - то понятно, что экземпляров
nginx тоже будет много, как минимум по количеству серверов/контейнеров.
И да, для простоты администрирования системы, 1 приложение == 1 tomcat.

> tomcat1 =(http)=> nginx1 =(HTTPS)=> nginx2 =(http)=> tomcat2
--
Best regards,
 Gena

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