SNIproxy

[vitus_wagner]

Нашел тут замечательный инстурмент SNIProxy

Позволяет решить задачу раскидывания https-траффика по машинам (в том числе виртуальным), сидящим за однм внешним IP. Причем полноценного такого раскидыванрия. когда каждый сервер имеет собственные ключи и хранит их у себя, может сам проверять клиентские сертификаты etc.

Под Bananian собралось, тестирвоать еще не тестировал, потому что для тестирования нужно иметь хотя бы два https-ных сервера, в локальной сети. А у меня в ЭТОЙ сети нет ни одного.

Хотя, конечно, такую штуку надо держать на роутере, а не на одном из серверов внутри сети. Но собирать ее под dd-wrt или openwrt мне ломы.

Comments

[inkelyad.livejournal.com]

О оно весь трафик через себе пропускает, или механизмами ядра tcp сессию дальше на нужный сервер отправляет?

[vitus_wagner]

По-моему через себя. Но судя по беглому взгляду даже не на код, а на набор зависимостей, оно через себя может пропустить мно-о-о-го.

[gunslinger2.livejournal.com]

А в чем отличие от nginx с +sni?

[vitus_wagner]

В том, что оно не является охренительным комбайном, который умеет делать уйму лишнего.

[vitus_wagner]

Вообще, почитав документацию на nginx я не увидел там аналогичной функциональнсти. nginx поддерживает режим ssl termintion, это значит что сертификат и закрытый ключ к нему должны жить на прокси-сервере, а реальный сервер, который за входной точкой, будет получать запросы, уже расшифрованные прокси, и, естественно, клиентского сертификата самостоятельно верифицировать не сможет.

sniproxy не выполняет никаких криптографических операций. Она смотрит на расширение SNI которое не зашифровано, и, в зависимости от этого, перенаправялет соединение тому или иному внутреннему серверу.

То есть с точки зрения внутренних серверов всё выглядит так, как будто с ними соединение осуществляется непосредственно, по отдельному IP.

У этих серверов могут быть разные реализации TLS, они могут работать на разных операционных системах, иметь разные хранилища сертификатов и даже разный административный контроль. И при этом входной IP адрес и порт - общие.

[foboss.livejournal.com]

Nginx научился работать в режиме "ssl passthrough" (без терминации сессий SSL) начиная с 1.9.0 (в opensource версии, в "Nginx+" раньше).

А так, как правило для целей tcp-проксирования ставят HAProxy. Он умеет очень многое: тот же ProxyProtocol, который отправляет на backend ip-адрес клиента в режиме TCP (без терминации ssl!) или, к примеру, можно сделать так, что на 80 порту браузеру будет отдаваться nginx/apache, а ssh-клиенту — sshd.

[octagram (from livejournal.com)]

Через полноценный HTTP проксик будет виден IP. А через SNIProxy — нет, что существенно уменьшает диапазон применений. Я некоторые свои сайты и сервисы просто не могу представить работающими вслепую, чтоб они не знали, с кем имеют дело.

Не хватает протокола, обратного SOCKS. В SOCKS мы открытым текстом указываем, с кем хотим соединиться, и дальше соединение как обычно. А в обратном SOCKS обратный прокси типа SNIProxy открытым текстом указывает, кто с нами хочет соединиться, и дальше соединение как обычно.

[vitus_wagner]

Это просто другой диапазон применения.

Зачем мне видеть IP пользователя, если я могу увидеть его клиентский сертификат? А вот с этим у обычного http-прокси, терминирующего SSL-соединение - проблема. Ну то есть пробросить сертификат на бэкэнд он может, но бэкэнду придется поверить ему на слово, что именно этот сертификат был предъявлен при хендшейке.