Какой стандарт де-факто для обратного прокси-сервера сообщает об использовании SSL в бэкэнде?

Question

У меня есть обратный прокси-сервер, который делает HTTPS снаружи, но HTTP внутри.

Это означает, что по умолчанию в URL-адресах приложений в качестве схемы будет использоваться HTTP, так как с ним связываются.

Как прокси-сервер может сообщить бэкэнду, что следует использовать HTTPS?

Answer 1

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

До сих пор я видел пару, использованную для принудительного использования https в схеме URL:

X-Forwarded-Protocol: https
X-Forwarded-Ssl: on
X-Url-Scheme: https

И википедия также упоминает:

# a de facto standard:
X-Forwarded-Proto: https
# Non-standard header used by Microsoft applications and load-balancers:
Front-End-Https: on

Это то, что вы должны добавить в VirtualHost на Apache: другие прокси должны иметь аналогичную функциональность

RequestHeader set X-FORWARDED-PROTOCOL https
RequestHeader set X-Forwarded-Ssl on
# etc.

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

Answer 2

Мне потребовалось несколько часов поиска в Google, чтобы найти магические условия для моего окружения. У меня есть обратный прокси-сервер SSL httpd apache перед сервером приложений Jetty и http-сервером apache2. Этот ответ фактически дал мне информацию, которая работала. Для меня добавление RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME} в файл conf сайта было достаточно для назначения, чтобы использовать https вместо http в качестве протокола при построении ссылок в ответе. Я попробовал X-FORWARDED-PROTOCOL выше, но это не сработало. Надеюсь, это поможет в будущих поисках Google!

Answer 3

Я боролся с этим пару дней, пытаясь настроить автономное приложение GitLab Community Edition. Остальная часть приложения работала нормально с SSL, например, доступ к общедоступному каталогу Apache по умолчанию и переход на страницу входа в GitLab, но после входа в GitLab выдавалась «Ошибка 422».

Возможно, это поможет кому-то еще, у кого такая же настройка, как у меня.

Настраивать

• Аппаратное обеспечение: Linux 3.10.0-1160.6.1.el7.x86_64 x86_64 (экземпляр, размещенный где-то в облаке)
• ОС: CentOS Linux версии 7.9.2009 (ядро)
• GitLab: "версия":"15.9.3"
• Apache: версия сервера: Apache/2.4.6 (CentOS), сборка сервера: 27 января 2023 г., 17:36:29
• Установленmod_sslсdnf -y install mod_sslи настроил его (вероятно, мне не стоит рассказывать, как я это настроил, потому что я не уверен в безопасности этого, так что удачи в этом, если вы еще этого не сделали)

Цели

• Игнорировать все запросы на порт 80
• Принимать только HTTPS-запросы
• Доступ к GitLab через порт 8081 через прокси
• Доступ к каталогу Apache по умолчанию, если в URL-адресе не указан порт 8081.

Решение

• Все, что мне нужно было сделать, это добавитьRequestHeader set X-Forwarded-Ssl onв мой существующий файл.

Вот мои конфиги, без IP и прочего.

• /etc/httpd/conf/httpd.conf

      ...snip...
#Listen 80
Listen 8081
...snip...

• /etc/httpd/conf/[MY_SITE].conf

      <VirtualHost [redacted]:8081>
  ServerName [redacted]
  ServerSignature Off
  ProxyPreserveHost On

  SSLEngine on
  SSLCertificateFile [redacted]
  SSLCertificateKeyFile [redacted]
  RequestHeader set X-Forwarded-Ssl on

  AllowEncodedSlashes NoDecode

  <Location />
    Require all granted
    ProxyPassReverse http://[redacted]
    ProxyPassReverse http://[redacted]
  </Location>

  RewriteEngine on

  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
  RewriteCond %{REQUEST_URI} ^/uploads/.*
  RewriteRule .* http://[redacted]

  DocumentRoot /opt/gitlab/embedded/service/gitlab-rails/public

  ErrorDocument 404 /404.html
  ErrorDocument 422 /422.html
  ErrorDocument 500 /500.html
  ErrorDocument 502 /502.html
  ErrorDocument 503 /503.html

  LogFormat [redacted]
  CustomLog [redacted]

  SSLCipherSuite EECDH+AESGCM:EDH+AESGCM
  SSLProtocol -all +TLSv1.2
  SSLHonorCipherOrder On
  Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains"   
  SSLCompression off
  SSLUseStapling on
</VirtualHost>

SSLStaplingCache "shmcb:logs/stapling-cache(150000)"