ssl renegotiation on nginx 1.13.+

[Mike Patutin]

Это то, что я сделал первым делом.
Но, в этом случае я не могу получить IP клиента, что для меня критично.
Все эти танцы с бубнами затеяны именно для X-Forwarded-For в заголовке.
Если это можно исправить, то будет вполне рабочий вариант.
Вот только можно ли?

18 сентября 2017 г., 18:23 пользователь Konstantin Tokarev <
annulen на yandex.ru> написал:

>
>
> 18.09.2017, 17:38, "Mike Patutin" <mpatutin на gmail.com>:
>
> А возможна ли "передача" ssl renegotiation?
> Т.е. при запросе ssl renegotiation c сервера управления, инициировать ssl
> renegotiation от nginx клиенту?.
>
> На данный момент я настроил передачу клиентского ssl сертификата в
> заголовке http.
> Регистрируюсь напрямую на сервере управления(устройство получает
> корректный сертификат), потом подставляю в середину nginx, и схема вполне
> себе работает.
>
> Проблема у меня именно в процессе регистрации, поскольку renegotiation с
> сервера управления просто теряется.
>
> Буду благодарен за любую информацию. Где в исходниках можно найти связь
> между коннектом к backend и коннектом клиента? Как инициировать
> renegotiation на клиентском коннекте.
> Сейчас уперся в первое. читал Ваши патчи на предмет renegotiation, но
> общего понимания внутренней архитектуры у меня пока нет, понять не
> получается пока.
>
> Я сознательно оставляю в стороне вопросы безопасности, понимаю, что это
> небезопасно, но это внутренняя система, с интернетом не связанная, более
> того, работающая в собственной изолированной даже от офиса сети.
>
>
> Можно спроскировать через Nginx TCP-соедине6ние и работать с клиентом
> напрямую
>
>
>
>
> 18 сентября 2017 г., 17:18 пользователь Maxim Dounin <mdounin на mdounin.ru>
> написал:
>
> 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
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> ,
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
> --
> Regards,
> Konstantin
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170918/5f3fcda9/attachment.html>