<div dir="ltr">А возможна ли "передача" ssl renegotiation?<br>Т.е. при запросе ssl renegotiation c сервера управления, инициировать ssl renegotiation от nginx клиенту?.<br><br>На данный момент я настроил передачу клиентского ssl сертификата в заголовке http.<br>Регистрируюсь напрямую на сервере управления(устройство получает корректный сертификат), потом подставляю в середину nginx, и схема вполне себе работает.<div><br></div><div>Проблема у меня именно в процессе регистрации, поскольку renegotiation с сервера управления просто теряется.<br><br>Буду благодарен за любую информацию. Где в исходниках можно найти связь между коннектом к backend и коннектом клиента? Как инициировать renegotiation на клиентском коннекте.</div><div>Сейчас уперся в первое. читал Ваши патчи на предмет renegotiation, но общего понимания внутренней архитектуры у меня пока нет, понять не получается пока.</div><div><br></div><div>Я сознательно оставляю в стороне вопросы безопасности, понимаю, что это небезопасно, но это внутренняя система, с интернетом не связанная, более того, работающая в собственной изолированной даже от офиса сети.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">18 сентября 2017 г., 17:18 пользователь Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> написал:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<span class=""><br>
On Sat, Sep 16, 2017 at 11:52:05PM +0300, Mike Patutin wrote:<br>
<br>
> Немного странный вопрос, в чем смысл renegotiation на backend коннектах и<br>
> для чего это нужно?<br>
<br>
</span>Это нужно для того, чтобы nginx мог общаться с бекендами, которые<br>
пытаются инициировать renegotiation для запроса сертификата.<br>
<span class=""><br>
> Можно ли применить эти изменения для реализации следующей схемы:<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 бекенда на клиента.<br>
<br>
</span>Если я правильно понял задачу, то она не решается иначе как<br>
установлением прямого соединения между клиентом и сервером<br>
управления.  Ну или сложной логикой, которая бы меняла<br>
сертификаты, посылаемые клиентом в исходном запросе.<br>
<br>
Потому что если клиент прислал сертификат, и сервер управления его<br>
проверяет - то одной из решаемых задач является защита от<br>
MitM-атак.  А попытка вставить между ними nginx - это фактически и<br>
есть MitM-атака.<br>
<span class=""><br>
> Я правильно понимаю что заявленный функционал в 1.13 предназначен для<br>
> реализации подобной схемы, или это не так?<br>
<br>
</span>Нет, это не так.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" rel="noreferrer" target="_blank">http://nginx.org/</a><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></font></span></blockquote></div><br></div>