<div dir="ltr">Это то, что я сделал первым делом.<br>Но, в этом случае я не могу получить IP клиента, что для меня критично.<br>Все эти танцы с бубнами затеяны именно для X-Forwarded-For в заголовке.<br>Если это можно исправить, то будет вполне рабочий вариант.<br>Вот только можно ли?<br><div class="gmail_extra"><br><div class="gmail_quote">18 сентября 2017 г., 18:23 пользователь Konstantin Tokarev <span dir="ltr"><<a href="mailto:annulen@yandex.ru" target="_blank">annulen@yandex.ru</a>></span> написал:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> </div><div> </div><div>18.09.2017, 17:38, "Mike Patutin" <<a href="mailto:mpatutin@gmail.com" target="_blank">mpatutin@gmail.com</a>>:</div><span class=""><blockquote type="cite"><div>А возможна ли "передача" ssl renegotiation?<br>Т.е. при запросе ssl renegotiation c сервера управления, инициировать ssl renegotiation от nginx клиенту?.<br><br>На данный момент я настроил передачу клиентского ssl сертификата в заголовке http.<br>Регистрируюсь напрямую на сервере управления(устройство получает корректный сертификат), потом подставляю в середину nginx, и схема вполне себе работает.<div> </div><div>Проблема у меня именно в процессе регистрации, поскольку renegotiation с сервера управления просто теряется.<br><br>Буду благодарен за любую информацию. Где в исходниках можно найти связь между коннектом к backend и коннектом клиента? Как инициировать renegotiation на клиентском коннекте.</div><div>Сейчас уперся в первое. читал Ваши патчи на предмет renegotiation, но общего понимания внутренней архитектуры у меня пока нет, понять не получается пока.</div><div> </div><div>Я сознательно оставляю в стороне вопросы безопасности, понимаю, что это небезопасно, но это внутренняя система, с интернетом не связанная, более того, работающая в собственной изолированной даже от офиса сети.</div></div></blockquote></span><div><br>Можно спроскировать через Nginx TCP-соедине6ние и работать с клиентом напрямую</div><div> </div><blockquote type="cite"><div><div class="h5"><div><div> </div></div><div> <div>18 сентября 2017 г., 17:18 пользователь Maxim Dounin <span><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> написал:<blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br><br><span>On Sat, Sep 16, 2017 at 11:52:05PM +0300, Mike Patutin wrote:<br><br>> Немного странный вопрос, в чем смысл renegotiation на backend коннектах и<br>> для чего это нужно?</span><br><br>Это нужно для того, чтобы nginx мог общаться с бекендами, которые<br>пытаются инициировать renegotiation для запроса сертификата.<br><br><span>> Можно ли применить эти изменения для реализации следующей схемы:<br>><br>> Клиентом является железка, которая умеет ssl соединение с сервером<br>> управления (tomcat).<br>> Железка сначала регистрируется на сервере, и он ей отдает сертификат,<br>> который в последующем используется для  ее авторизации.<br>> Т.е на определенный URL можно сделать запрос по https без корретного<br>> сертификата, на другие - нет<br>> В первый момент железка делает запрос с собственным сертификатом,<br>> выполяняются определенные действия, передается корректный сертификат<br>> авторизации, а потом томкат вызывает тот самый renegotiation и дальнейший<br>> обмен не может быть выполнен без авторизации по сертификату.<br>> Поменять поведение железки - не могу в принципе (жесточайшее legacy, причем<br>> часть просто не обновляемая в принципе)<br>> Томкатом в определенных пределах могу управлять.<br>> Железок много, приходится делать балансировщик. И вот тут я столкнулся с<br>> невозможностью пробросить ssl renegotiation c бекенда на клиента.</span><br><br>Если я правильно понял задачу, то она не решается иначе как<br>установлением прямого соединения между клиентом и сервером<br>управления.  Ну или сложной логикой, которая бы меняла<br>сертификаты, посылаемые клиентом в исходном запросе.<br><br>Потому что если клиент прислал сертификат, и сервер управления его<br>проверяет - то одной из решаемых задач является защита от<br>MitM-атак.  А попытка вставить между ними nginx - это фактически и<br>есть MitM-атака.<br><br><span>> Я правильно понимаю что заявленный функционал в 1.13 предназначен для<br>> реализации подобной схемы, или это не так?</span><br><br>Нет, это не так.<br><br><span><font color="#888888">--<br>Maxim Dounin<br><a href="http://nginx.org/" target="_blank">http://nginx.org/</a><br>______________________________<wbr>_________________<br>nginx-ru mailing list<br><a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br><a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-ru</a></font></span></blockquote></div></div></div></div>,<span class=""><p>______________________________<wbr>_________________<br>nginx-ru mailing list<br><a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br><a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-ru</a></p></span></blockquote><span class="HOEnZb"><font color="#888888"><div> </div><div> </div><div>-- <br>Regards,</div><div>Konstantin</div><div> </div></font></span><br>______________________________<wbr>_________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-ru</a><br></blockquote></div><br></div></div>