Closed Tratcher closed 7 years ago
From @cesarbs on September 15, 2016 22:38
Kestrel supports HTTPS: https://github.com/aspnet/KestrelHttpServer/blob/efa37e55903c276951d1cf6561abee4d4e6b3393/samples/SampleApp/Startup.cs#L41
From @halter73 on September 15, 2016 23:8
@blowdart
From @benaadams on September 16, 2016 0:9
I don't know if its "approved" yet, but for SF you should be using WebListener for your directly externally facing microservice layer, then can use Kestrel for your internal microservice to microservice communications on its private network.
Hopefully in the future can use Kestrel as the external layer, but not currently.
From @blowdart on September 16, 2016 0:11
The article is wrong. Kind of.
Remember we don't recommend you expose Kestrel to the internet. Treat it as an app server, not a web server. So the TLS support is for doing end to end encryption, you terminate at the proxy, and then the proxy talks SSL to Kestrel.
And to be technically correct, we don't support SSL, we only support TLS :)
From @AceHack on September 16, 2016 0:51
So just to be clear without a 3rd party proxy, there is no support for TLS? I just want to make sure I understand.
From @benaadams on September 16, 2016 11:50
It is a scenario that is "not supported" for an externally facing webserver; when you need to use a reverse proxy.
You can use ssl with kestrel on a closed private network (note: not an internal user exposed network); for example ssl between the proxy and kestrel for end-to-end encryption or inter-communications between microservices.
An example of how to use SSL with Kestrel is in the SampleApp project in the Kestrel samples directory https://github.com/aspnet/KestrelHttpServer/blob/dev/samples/SampleApp/Startup.cs#L36-L44
From @blowdart on September 16, 2016 14:50
That's not what I'm saying.
I'm saying don't expose Kestrel to the internet, with TLS or not. That's not what we recommend. Always run it behind a proxy, regardless of needing TLS or not.
From @AceHack on September 16, 2016 16:28
So for my internal service to service communications on service fabric or self host can I use kestrel and is TLS supported in that scenario?
From @AceHack on September 16, 2016 16:29
Also FYI there seems to be lots of conflicting information here.
From @benaadams on September 16, 2016 17:47
If you are deploying to a standard Azure SF cluster your microservices are deployed to VM scale sets and the whole cluster lives inside its own Virtual Network.
The microservices communicate with each other over the Virtual Network so they are not open to the outside world - here you can use Kestrel without a proxy as there should be no way to directly contact those services from outside the Virtual Network.
If you additionally wish to add SSL to these communications on top of the isolation that the Virtual Network provides for full end-to-end encryption then you want to use the Microsoft.AspNetCore.Server.Kestrel.Https
package as shown in the samples.
However, you will also likely have one or more ports open via the load balancer to the outside world to a stateless service that acts as the gateway to your cluster.
Here you should either use a reverse proxy to the stateless service (e.g. insuring the IIS role is installed on the server etc) or more straight-forwardly use WebListener (see announcement) instead of Kestrel for these ports.
It should be a fairly simple exchange of UseWebListener
rather than UseKestrel
; but there are more details in the announcement.
Hopefully that is correct @blowdart ?
From @benaadams on September 16, 2016 18:6
Addendum
If you are deploying SF with a custom set-up e.g. not to an Azure standard cluster; so a bunch of Azure VMs, AWS, an on premise internal network etc where you are directly setting up the cluster servers/VMs and network; then if the cluster is not on a closed private virtual network you should use WebListener for the inter-service communication as they are open to other things contacting them on their "internal" ports.
@danroth27 can we get this written up for the server docs?
@Tratcher That summary seems right.
@Tratcher @blowdart We are have this note in our Servers doc:
Kestrel is designed to be run behind a proxy (for example IIS or Nginx) and should not be deployed directly facing the Internet.
Do we really need to say more than that? I would rather not document in the ASP.NET Core doc all the various ways you can configure your Service Fabric cluster.
Why not?
Because we have plenty of ASP.NET Core stuff left to document without having to document how to use Service Fabric. Also, eventually we will have done sufficient hardening work on Kestrel so that this whole discussion becomes a moot point.
We currently link to https://azure.microsoft.com/en-us/documentation/articles/service-fabric-add-a-web-frontend/ for instructions on how to use ASP.NET Core with Service Fabric. Any clarification that needs to be made on how to apply our Kestrel vs WebListener guidance to Service Fabric I think should go there. @seanmck
From @AceHack on September 15, 2016 16:43
In reading this article it seems to say that it is not. http://aspnetmonsters.com/2016/08/2016-08-07-nginx2/, it seems you need something like nginx or IIS to support SSL in Kestrel .net core.
Copied from original issue: aspnet/KestrelHttpServer#1108