ssl renegotiation on nginx 1.13.+

[Mike Patutin]

А возможна ли "передача" ssl renegotiation?
Т.е. при запросе ssl renegotiation c сервера управления, инициировать ssl
renegotiation от nginx клиенту?.

На данный момент я настроил передачу клиентского ssl сертификата в
заголовке http.
Регистрируюсь напрямую на сервере управления(устройство получает корректный
сертификат), потом подставляю в середину nginx, и схема вполне себе
работает.

Проблема у меня именно в процессе регистрации, поскольку renegotiation с
сервера управления просто теряется.

Буду благодарен за любую информацию. Где в исходниках можно найти связь
между коннектом к backend и коннектом клиента? Как инициировать
renegotiation на клиентском коннекте.
Сейчас уперся в первое. читал Ваши патчи на предмет renegotiation, но
общего понимания внутренней архитектуры у меня пока нет, понять не
получается пока.

Я сознательно оставляю в стороне вопросы безопасности, понимаю, что это
небезопасно, но это внутренняя система, с интернетом не связанная, более
того, работающая в собственной изолированной даже от офиса сети.


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
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170918/6f565d3c/attachment.html>