SSL/TSL 和普通流量的反向代理如何工作？

Question

我有一个使用

创建的容器化 Docker ASP.NET Core 应用程序

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

启动时，对端口的唯一引用是基础映像中的这个 ENV 变量

ASPNETCORE_URLS http://+:80

我将应用程序部署到 Azure，设置了注册表并创建了一个新的 Web 应用程序。
我设置了 TLS/SSL 设置以仅使用 https。

一切正常。

问题：

我想知道这是怎么可能的，因为我没有在我的容器上配置证书，我想 Kudu 服务（反向代理）将 443 端口重新绑定到容器的 80。这是真的 ？ Kudu 和 80 端口上的容器之间的普通 http 流量可能会导致安全漏洞？

如果我使用 NGINX 部署一个容器作为 ASP.NET Core 的反向代理，我必须将 TSL/SSL 配置到 NGINX 中吗？在 ASP.NET 核心上？一个都没有？

我想了解 Kudu、NGINX 和反向代理在使用和不使用 SSL/TSL 的情况下一般是如何工作的

Answer 1

使用Reverse Proxy，客户端永远不会连接到您应用程序中的HTTP 服务器，在您的情况下为Kestrel。您获得的连接是来自反向代理的请求，您将响应发送回反向代理。大多数 HTTP 内容都是从传入的客户端请求中复制并传递给您的应用程序，但反向代理可以终止 SSL 隧道、卸载 Authentation 并执行其他请求转换。