<br><br>четверг, 23 января 2014 г. пользователь Gena Makhomed  написал:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23.01.2014 8:40, Илья Шипицин wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Все что связано с сертификатами и TLS/SSL хотелось бы оставить<br>
на уровне nginx, чтобы веб-сервисам приходил plain http,<br>
и разработчикам этих веб-сервисов не приходилось бы потом<br>
заморачиваться с https-запросами и клиентскими сертификатами.<br>
</blockquote>
<br>
это чревато тем, что для приложения вся ваша магия выльется в "еще<br>
одну точку отказа", как вы выразились.<br>
как приложение отреагирует, если магия сломается ? а сломаться она<br>
может легко, например, нет доступа к CRL-ке и сервер не принял<br>
сертификат, который ему предъявил nginx<br>
</blockquote>
<br>
Еще одной точки отказа тут нет, nginx в любом случае используется.<br>
nginx стартует с рутовыми правами и доступ к сертификатам у него есть.<br>
Если сервер не принял сертификат - значит у этого клиента доступа нет.</blockquote><div><br></div><div>еще одна точка отказа тут есть.</div><div>nginx предъявляет свой сертификат серверу, сервер может отказать либо потому что у пользователя нет доступа, либо в силу того, что сервер не смог скачать CRL</div>
<div><br></div><div>надо либо в одном случае возвращать "temp fail", в другом "perm fail", либо что-то еще, но логику отработки ошибок надо как-то реализовывать на стороне приложения</div><br><div><br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Если вся логика работы с TLS/SSL будет только на уровне nginx - это<br>
нормально, а если часть там, часть там - то это layering violation.</blockquote><div><br></div><div>если вся логика с ssl на стороне nginx, это точка отказа</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Если веб-приложение работает как сервер - ему запрос приходит<br>
на <a href="http://127.0.0.1:80/" target="_blank">http://127.0.0.1:80/</a> а если веб-приложение работает как клиент<br>
и хочет связаться с другим веб-сервисом - то оно просто отправляет<br>
plain http запрос на <a href="http://127.0.0.1:8080/" target="_blank">http://127.0.0.1:8080/</a> - здесь слушает nginx<br>
и проксирует этот запрос через https с mutual auth на удаленный сервер.<br>
</blockquote>
<br>
необязательно на C/C++, можно на nginx-lua за полдня набросать то, что<br>
вы хотите.<br>
</blockquote>
<br>
Каким образом, разве nginx-lua сможет добавить к proxy_pass<br>
ту функциональность, которой там сейчас нет, в частности, передачу<br>
на удаленный сервер клиентского сертификата и проверку серверного?</blockquote><div><br></div><div>content_by_lua и любой креатив в ваших силах</div><div>ценой, возможно, большого оверхеда</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Скорее всего - такой функциональности сейчас в nginx таки нет.<br>
Только не понятно - ее "еще нет" или же "вообще нет и не будет".<br>
<br>
Подозреваю, что такая функциональность в nginx будет полезной<br>
не только мне, но и большому количеству других пользователей.<br>
</blockquote>
<br>
очень легко уйти в холивар насчет "полезно ли большому количеству пользователей"<br>
</blockquote>
<br>
Можно и не уходить в холивар. Micro Service Architecture сейчас набирает<br>
популярность для создания приложений, вот например, про это написали<br>
даже в анонсе про выход Spring Framework 4.0 GA Release:<br>
<a href="http://spring.io/blog/2013/12/12/announcing-spring-framework-4-0-ga-release" target="_blank">http://spring.io/blog/2013/12/<u></u>12/announcing-spring-<u></u>framework-4-0-ga-release</a><br>
<br>
Логично же делать максимальный уровень защиты<br>
через Mutual authentication между сервисами.</blockquote><div><br></div><div><br></div><div>у нас одна из любимых ошибок - "неидемпотентность сервиса", то есть, к примеру есть несколько экземпляров одного сервиса. мы обращаемся к сервису, делаем запрос "поменяй то-то и то-то", запрос уходит в таймаут, что делать ? </div>
<div><br></div><div>идеальной была бы ситуация, когда многократно выполенный запрос не приводил бы к многократному изменению данных (это ведь, по сути, один и тот же запрос). такие типы сервисов называются "идемпотентными".</div>
<div><br></div><div>если сервис таким свойством не обладает, в каких-то случаях лучше зафейлиться, чем уходить на следующую реплику</div><div><br></div><div>а теперь представьте, что вы "прячете" топологию сервисов за nginx, все становится еще сложнее, у nginx в коде события "tcp connect timeout" (когда запрос не ушел и безопасно его еще раз повторить) и "http response timeout" (когда надо быть максимально аккуратным) выглядят одинаково</div>
<div><br></div><div>кстати, надо будет патч на эту тему сделать ))</div><div><br></div><br><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
В любом случае, наличие такой feature никому не помешало бы.<br>
Кому не надо - просто не включают и не пользуются.<br>
<br>
Вот, как например, мне совершенно не мешает наличие<br>
модуля image_filter или empty_gif или geoip и т.п.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
И возможно это даже будет killer feature, которая позволит<br>
еще больше увеличить % использование nginx в современном<br>
web 2.0 и будущем web 3.0. Если это кому-то интересно.<br>
</blockquote>
<br>
сейчас немного другой тренд.<br>
скажем так, OAuth<br>
но там вся логика строится на приложении, не на транспорте.<br>
<br>
Майкрософт эту тему двигает, у него она называется "Claim based access<br>
control" (раньше любимая тема была RBAC = role based access control)<br>
</blockquote>
<br>
Это если разные сервисы разных производителей взаимодействуют<br>
между собой, то там да, OAuth. А если - это один сервис, который<br>
решает одну задачу, просто он сам построен не в виде одного большого<br>
монолитного приложения. Этот тренд - Micro Service Architecture<br>
набирает популярность. По крайней мере, раньше такого не было.</blockquote><div><br></div><div>тренд бесспорно интересный</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Но прежде чем куда-то идти и о чем-то просить - вот сначала<br>
попытался узнать в списке рассылки - может быть я какой-то<br>
неправильный вариант решения для этой задачи придумал<br>
и ее все обычно решают другим, более простым способом?<br>
</blockquote>
<br>
вариант как вариант.<br>
сейчас модно креативить :-)<br>
</blockquote>
<br>
А как иначе это можно сделать?<br>
<br>
Вот например, реальная задача. Есть небольшой хостинг -<br>
несколько десятков сайтов, которые созданы под заказ.<br>
<br>
Вместо того, чтобы для каждого сайта создавать свою админку,<br>
цеплять к ней SSL-сертификат, - проще и удобнее сделать всего<br>
одну админку, куда будут заходить пользователи по https,<br>
и там они смогут управлять своими сайтами. А сами сайты:<br>
<br>
<a href="http://www.example.com" target="_blank">www.example.com</a> - сюда ходят пользователи сайта<br>
<a href="http://api.example.com" target="_blank">api.example.com</a> - сюда ходит админка с Mutual authentication<br>
<br>
Сейчас - сайтов десятки, потом может быть сотни и тысячи.<br>
И что делать, настраивать и поддерживать в живом состоянии<br>
сотни и тысячи stunnel`ей? Каждому выделяя свой отдельный<br>
порт на стороне контейнера с админкой? Это будет nightmare.<br>
Практически это нереальный вариант. Наверное придется таки<br>
идти на layering violation и обучать админку делать https-<br>
запросы с предъявлением клиентского сертификата через curl.</blockquote><div><br></div><div><br></div><div>реальна задача- это замечательно, но я не понял, в каком месте возникает профит от mutual authentication, вероятно, надо больше деталей</div>
<div><br></div><div><br></div><div>если вы хотите проверять серты на nginx и сообщать приложению, это делается через переменные nginx, у нас такой сценарий используется, могу конфиги помочь составить</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
==============================<u></u>============================<br>
<br>
Вторая задача - это большой веб-сервис, который построен<br>
с использованием Micro Service Architecture, физически<br>
размещен на нескольких серверах с горизонтальным масштабированием</blockquote><div><br></div><div>nginx ломает идею горизонтального масштабирования, или вы планируете горизонтально плодить много экземпляров nginx?</div><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
наиболее высоконагруженных подсистем. Причем все эти микросервисы<br>
могут "на ходу" добавляться/убираться/<u></u>перестраиваться,<br>
здесь тоже идеально подходит вариант когда Mutual authentication<br>
делает сам nginx, а между nginx и tomcat`ами будет только plain http:<br>
<br>
   tomcat1 =(http)=> nginx1 =(HTTPS)=> nginx2 =(http)=> tomcat2<br>
<br>
Разве в будущем создание серверных систем пойдет не в этом направлении?<br>
У nginx сейчас вот есть возможность создать и возглавить такой тренд...</blockquote><div><br></div><div>тренд прикольный</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
-- <br>
Best regards,<br>
 Gena<br>
<br>
______________________________<u></u>_________________<br>
nginx-ru mailing list<br>
<a>nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/<u></u>mailman/listinfo/nginx-ru</a></blockquote>