А возможна ли "передача" ssl renegotiation? Т.е. при запросе ssl renegotiation c сервера управления, инициировать ssl renegotiation от nginx клиенту?.
На данный момент я настроил передачу клиентского ssl сертификата в заголовке http. Регистрируюсь напрямую на сервере управления(устройство получает корректный сертификат), потом подставляю в середину nginx, и схема вполне себе работает. Проблема у меня именно в процессе регистрации, поскольку renegotiation с сервера управления просто теряется. Буду благодарен за любую информацию. Где в исходниках можно найти связь между коннектом к backend и коннектом клиента? Как инициировать renegotiation на клиентском коннекте. Сейчас уперся в первое. читал Ваши патчи на предмет renegotiation, но общего понимания внутренней архитектуры у меня пока нет, понять не получается пока. Я сознательно оставляю в стороне вопросы безопасности, понимаю, что это небезопасно, но это внутренняя система, с интернетом не связанная, более того, работающая в собственной изолированной даже от офиса сети. 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
