Это то, что я сделал первым делом. Но, в этом случае я не могу получить IP клиента, что для меня критично. Все эти танцы с бубнами затеяны именно для X-Forwarded-For в заголовке. Если это можно исправить, то будет вполне рабочий вариант. Вот только можно ли?
18 сентября 2017 г., 18:23 пользователь Konstantin Tokarev < [email protected]> написал: > > > 18.09.2017, 17:38, "Mike Patutin" <[email protected]>: > > А возможна ли "передача" ssl renegotiation? > Т.е. при запросе ssl renegotiation c сервера управления, инициировать ssl > renegotiation от nginx клиенту?. > > На данный момент я настроил передачу клиентского ssl сертификата в > заголовке http. > Регистрируюсь напрямую на сервере управления(устройство получает > корректный сертификат), потом подставляю в середину nginx, и схема вполне > себе работает. > > Проблема у меня именно в процессе регистрации, поскольку renegotiation с > сервера управления просто теряется. > > Буду благодарен за любую информацию. Где в исходниках можно найти связь > между коннектом к backend и коннектом клиента? Как инициировать > renegotiation на клиентском коннекте. > Сейчас уперся в первое. читал Ваши патчи на предмет renegotiation, но > общего понимания внутренней архитектуры у меня пока нет, понять не > получается пока. > > Я сознательно оставляю в стороне вопросы безопасности, понимаю, что это > небезопасно, но это внутренняя система, с интернетом не связанная, более > того, работающая в собственной изолированной даже от офиса сети. > > > Можно спроскировать через Nginx TCP-соедине6ние и работать с клиентом > напрямую > > > > > 18 сентября 2017 г., 17:18 пользователь Maxim Dounin <[email protected]> > написал: > > Hello! > > On Sat, Sep 16, 2017 at 11:52:05PM +0300, Mike Patutin wrote: > > > Немного странный вопрос, в чем смысл renegotiation на backend коннектах и > > для чего это нужно? > > Это нужно для того, чтобы nginx мог общаться с бекендами, которые > пытаются инициировать renegotiation для запроса сертификата. > > > Можно ли применить эти изменения для реализации следующей схемы: > > > > Клиентом является железка, которая умеет ssl соединение с сервером > > управления (tomcat). > > Железка сначала регистрируется на сервере, и он ей отдает сертификат, > > который в последующем используется для ее авторизации. > > Т.е на определенный URL можно сделать запрос по https без корретного > > сертификата, на другие - нет > > В первый момент железка делает запрос с собственным сертификатом, > > выполяняются определенные действия, передается корректный сертификат > > авторизации, а потом томкат вызывает тот самый renegotiation и дальнейший > > обмен не может быть выполнен без авторизации по сертификату. > > Поменять поведение железки - не могу в принципе (жесточайшее legacy, > причем > > часть просто не обновляемая в принципе) > > Томкатом в определенных пределах могу управлять. > > Железок много, приходится делать балансировщик. И вот тут я столкнулся с > > невозможностью пробросить ssl renegotiation c бекенда на клиента. > > Если я правильно понял задачу, то она не решается иначе как > установлением прямого соединения между клиентом и сервером > управления. Ну или сложной логикой, которая бы меняла > сертификаты, посылаемые клиентом в исходном запросе. > > Потому что если клиент прислал сертификат, и сервер управления его > проверяет - то одной из решаемых задач является защита от > MitM-атак. А попытка вставить между ними nginx - это фактически и > есть MitM-атака. > > > Я правильно понимаю что заявленный функционал в 1.13 предназначен для > > реализации подобной схемы, или это не так? > > Нет, это не так. > > -- > Maxim Dounin > http://nginx.org/ > _______________________________________________ > nginx-ru mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > , > > _______________________________________________ > nginx-ru mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > Regards, > Konstantin > > > _______________________________________________ > nginx-ru mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx-ru >
_______________________________________________ nginx-ru mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
