具有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 Core上？完全没有？

我想了解Kudu，NGINX和反向代理通常在有无SSL / TSL的情况下如何工作

我有一个使用mcr.microsoft.com/dotnet/core/runtime:3.1.3-alpine创建的容器化Docker ASP.NET Core应用程序，在启动时，对端口的唯一引用是来自...的这个ENV变量。>

Answer 1

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