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,
Regards,
Konstantin
_______________________________________________ nginx-ru mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
