Add server-side SslStream support for SNI and multiple server certificates

[Tratcher]

https://tools.ietf.org/html/rfc6066#section-3

This is needed for servers servicing multiple host names.
https://github.com/aspnet/KestrelHttpServer/issues/241

[davidsh]

cc: @CIPop @himadrisarkar @stephentoub

[davidsh]

Basically the same as #15813 #15077

[0xfffffff7]

SslStream is not supported SNI?

[CIPop]

I'm not sure this is the same as the ALPN feature. SNI is a different extension of the TLS handshake introduced much earlier than ALPN. My understanding is that:

• SNI would allow a client to specify the host name (certificate name) and a server to host multiple sites on the same IP address.
• ALPN allows a client to specify a protocol and a server to host multiple applications on the same TCP/UDP address (port).

[karelz]

Next step: We need formal API proposal.

[lodejard]

Yes, please! /cc @davidfowl @Eilon @DamianEdwards

Without SNI you must have a different public ip (and load balancer configuration) per common-name. This is totally different from ALPN, which is more about enabling http/2.

This is a feature Java/Node have had SNI for years and years. It's also worth verifying that the various .net https clients are sending SNI information on connect.

https://netty.io/4.0/api/io/netty/handler/ssl/SniHandler.html
https://nodejs.org/api/tls.html#tls_alpn_npn_and_sni

[Eilon]

Hmm yes I guess that if Kestrel is used as an "edge" server, which when ASP.NET Core 2.0.0 is released, will officially be a thing, then this becomes that much more important, correct?

[Tratcher]

Indeed. The one limiter is that Kestrel still can't share ports with other instances/processes so you'd have to be running multiple domains on the same instance of Kestrel to take advantage of SNI.

[buvinghausen]

Don't want to plus one this issue but we're here because of Mongo Atlas needing SNI support

Atlas Driver Info

For now we're just going to leave our non production items on mlab but it would be nice to go to a single management console for our stack.

[karelz]

@buvinghausen AFAIK Mongo driver was blocked on client-side SNI, which was implemented in 2.1. If you really need server-side SNI, please provide deeper info about your requirements, scenario, etc.

[buvinghausen]

@karelz I will check that out later but thanks for the heads up! I will come back and let you know... by proxy if that fixes it I will let them know as well.

[buvinghausen]

@karelz I can officially confirm we moved to .NET Core 2.1 on Sunday and today we're able to connect to the free Mongo clusters from our Linux containers. Thank you for the clarification and anyone who lands on this page because of the Mongo documentation just know you need to run .NET Core 2.1

[stephentoub]

Dup of https://github.com/dotnet/corefx/issues/24553

[buvinghausen]

@karelz just a heads up but we experience problems with the MongoDB 3.6 connection string to Atlas on both OSX and the Linux Alpine Docker image. It works great on Windows and it works great on the Debian Stretch Docker image. I'm not sure if this is the place to list this but I've chosen here just in case anyone else follows the link from the MongoDB .NET Core page which lands here. Is there a better place for me to report this?

[Tratcher]

@buvinghausen I think you're looking for SQL Server Network Interface, not TLS Server Name Indication? Regardless please open new issues rather than commending on closed ones.

[buvinghausen]

@Tratcher the reason I am commenting here is because MongoDB still has this issue linked to their Atlas configuration page. I'm just trying to help anyone who lands here from that page navigate the waters by pointing out that the SNI works on Windows and on the Debian Stretch Docker image for 2.1 but not on OSX and the Alpine Linux images.

Yes they use TLS SNI on the 3.6 driver on Atlas to connect to all the members of the replica set. I am glad to start a new issue as well.

[karelz]

@buvinghausen please link the new issue you created / are going to create