Как заставить SSL хорошо играть с данными не-ssl протокола - PullRequest
1 голос
/ 02 марта 2020

Краткая справка: если мы go вернемся к 2006-му sh: Мы (ie: моя компания) использовали java клиентское приложение , встроенное в браузер , которое подключен через порт 443 к бэкэнду программы C, работающему через порт 8068 на внутреннем сервере. В то время, когда приложение java было впервые разработано, порт 443 был единственным портом, который, как мы знали, не был заблокирован нашими клиентами, которые использовали программное обеспечение (простота установки и, возможно, штатный персонал заказчика не имел власть или знания для управления внутренним брандмауэром).

Перенесемся в 2016 год, и я нанят, чтобы помочь разработать NodeJS / Javascript версию этого Java приложения. Приложение Java продолжает использоваться во время разработки его замены, но, к сожалению, мы узнаем, что браузеры откажутся от поддержки встроенного Java в ближайшем будущем. Поэтому мы переключаемся на Java Web Start, чтобы клиенты могли продолжать загружать приложение, и оно все равно подключалось к внутреннему серверу с маршрутизацией через порт 443-> 8068.

2017 катится и не Если вы знаете, мы не можем использовать готовящееся к выпуску веб-приложение JS с HTTPS / SSL и приложением Java одновременно, поскольку они используют один и тот же порт. «Хорошо, давайте использовать NGINX, чтобы решить проблему». Но из-за внутренней политики, потребностей клиентов и текучести кадров веб-разработчиков мы никогда не удосужились по-настоящему сделать эту работу.

Итак, мы готовы к развертыванию новой сети в 2020 году версия клиентского программного обеспечения, и весь этот беспорядок 443 вновь поднимает свою уродливую голову.

По сути, я хочу разрешить (на данный момент) приложению Java продолжать использовать 443, но теперь нужно разрешить веб-приложение тоже использует HTTPS. Еще в 2017/2018 мы гуглили способы, чтобы позволить им сожительствовать до NGINX, но мы никогда не заставляли их работать должным образом, или примеры и учебные пособия были неполными или запутанными. Казалось, что нам нужно либо использовать потоковую передачу по линиям https://www.nginx.com/blog/running-non-ssl-protocols-over-ssl-port-nginx-1-15-2/, либо посмотреть на входящий HTTPS-заголовок и выполнить 'if (https) { route to nodeJS server } else { assume it must be the java app and route to port 8068 }' сортировку в файле конфигурации NGINX.

Прошлые ссылки в Google, похоже, больше не существуют, поэтому, если кто-то знает о конфигурации NGINX, которая позволяет веб-сайту HTTPS передавать приложение не-SSL, которое все еще должно использовать 443, я был бы очень признателен Это. И любые документы и / или учебные пособия, которые указывают нам правильное направление, также будут полезны. Заранее спасибо!

1 Ответ

3 голосов
/ 02 марта 2020

Вы можете сделать это, используя опцию ssl_preread . По сути, эта опция разрешит доступ к переменной $ ssl_preread_protocol , которая содержит протокол, согласованный через порт SSL. Если действительный протокол не был обнаружен, переменная будет пустой.

Используя эти параметры, вы можете использовать следующую конфигурацию для вашей среды:

stream {
    upstream java {
        server __your_java_server_ip__:8068;
    }

    upstream nodejs {
        server __your_node_js_server_ip__:443;
    }

    map $ssl_preread_protocol $upstream {
        default java;
        "TLSv1.2" nodejs;
    }

    server {
        listen 443;

        proxy_pass $upstream;
        ssl_preread on;
    }
}

В вашем случае эта конфигурация пройдет соединение напрямую с вашими nodejs и java внутренними серверами, поэтому nodejs потребуется согласовать SSL. Вы можете передать эту работу на NGiNX, используя другой контекст сервера, например:

stream {
    upstream java {
        server __your_java_server_ip__:8068;
    }

    upstream nodejs {
        server 127.0.0.1:444;
    }

    map $ssl_preread_protocol $upstream {
        default java;
        "TLSv1.2" nodejs;
    }

    server {
        listen 443;

        proxy_pass $upstream;
        ssl_preread on;
    }
}

http {
    server {
        listen 444 ssl;
        __your_ssl_cert_configurations_here__

        location / {
            proxy_pass http://__your_nodejs_server_ip__:80;
        }
    }
}

Вам понадобится NGiNX как минимум версия 1.15.2, чтобы эта конфигурация работала и скомпилирована с Модуль ngx_stream_ssl_preread_module (необходимо скомпилировать с параметром конфигурации - with-stream_ssl_preread_module , поскольку этот модуль по умолчанию не собран).

Источник: https://www.nginx.com/blog/running-non-ssl-protocols-over-ssl-port-nginx-1-15-2/

...