Назад | Перейти на главную страницу

nginx stream proxy vs http прокси для завершения ssl

Я запускаю службу HTTP и хочу поставить nginx впереди для завершения SSL. Это можно сделать двумя способами; либо как stream доверенное лицо

stream {
    server {
        listen               443 ssl;
        ssl_certificate      /certs/fullchain.pem;
        ssl_certificate_key  /certs/privkey.pem;
        proxy_pass           ip-for-backend-service:80;
    }
}

или как http доверенное лицо

http {
    server {
        listen 443 ssl;
        ssl_certificate      /certs/fullchain.pem;
        ssl_certificate_key  /certs/privkey.pem;

        location / {
            proxy_pass       http://ip-for-backend-service:80;
            proxy_set_header ...;
        }
    }
}

На первый взгляд кажется, что конфигурация stream прокси много проще, так как вам не нужно добавлять кучу дополнительных заголовков (proxy_set_header и т.д.) и другие конфигурации.

Я пытаюсь понять плюсы и минусы этих двух методов, и, в частности, у меня есть следующие вопросы:

  1. Будет ли утечка информации о серверной службе при любом из этих методов? Например, будет ли ip-for-backend-service быть видимым?

  2. Приведет ли любой метод к лучшей защите от атак? Я предполагаю, что если у серверной службы есть недостатки, их можно будет увидеть / использовать в обоих вариантах?

  3. Какой вариант эффективнее? я считать что stream вариант может быть быстрее, так как он просто маршрутизирует трафик и нет http-сервера посередине?

В обоих методах исходящий IP-адрес останется скрытым.

В остальном:

  • stream безусловно, быстрее, поскольку выполняется меньше кода. Однако оба являются хорошо написанным кодом C, и если сравнить его с задержками в сети, разница может быть незаметна.
  • С участием stream журналы восходящего потока будут содержать только один IP-адрес клиента (адрес прокси-сервера). Это можно изменить с помощью proxy_bind директиве, но требует дополнительной настройки сети. С другой стороны, добавив X-Forwarded-For заголовок в http настройка проста:

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    
  • С участием stream вышестоящий сервер необходимо вручную настроить, чтобы входящее соединение считалось безопасным: например, Tomcat требует добавления scheme="https" и secure="true" на <Connector> элемент. Используя http прокси и X-Forwarded-Proto заголовок восходящий сервер может решить, HTTP или HTTPS использовалось для каждого соединения.

Вопрос о безопасности сетапа довольно основан на мнениях:

  • Используя http прокси, вы можете ограничить пути URI, которые будут проксироваться, следовательно, вы не будете открывать для общественности административную часть своего веб-сайта,
  • С другой стороны, добавляя дополнительную вычислительную нагрузку в вашу систему (по сравнению с альтернативой прямого доступа к вышестоящему серверу), вы больше подвержены DDoS-атакам.