Как работает обратный прокси с SSL / TSL и обычным трафиком c?

Question

У меня есть контейнер Docker ASP. NET Базовое приложение, созданное с помощью

mcr.microsoft.com/dotnet/core/runtime:3.1.3-alpine 

При запуске единственная ссылка на порт - это переменная ENV из базового образа

ASPNETCORE_URLS http://+:80

Я развернул приложение на Azure, настроил реестр и создал новое веб-приложение.
Я установил настройки TLS / SSL для работы только с https.

Все работает.

Вопрос:

Я хочу знать, как это возможно, поскольку я не настраиваю сертификат в своем контейнере, я полагаю, что служба Kudu (обратный прокси-сервер) повторно связывает порт 443 с 80 контейнера. Это правда ? Обычный http traffi c между Kudu и контейнером на порту 80 может привести к возможной дыре в безопасности?

Если я разверну контейнер с NGINX в качестве обратного прокси-сервера для ASP. NET Ядро Я должен настроить TSL / SSL на NGINX? На ASP. NET Core? Совсем нет?

Я хочу понять, как Kudu, NGINX и обратный прокси-сервер в целом работают с SSL / TSL

и без него *

Answer 1

С помощью обратного прокси клиент никогда не подключается к HTTP-серверу в вашем приложении, в вашем случае Kestrel . Получаемые вами соединения представляют собой запросы, поступающие от обратного прокси-сервера, и вы отправляете свои ответы обратно на обратный прокси-сервер. Большинство HTTP-содержимого копируется из входящего клиентского запроса и передается вашему приложению, но обратный прокси-сервер может завершить туннель SSL, разгрузить аутентификацию и выполнить другие преобразования запроса.