Add support for the TLS Server Name Indication (SNI) Extension to SslStream
Add support for the TLS Server Name Indication (SNI) Extension to allow more flexible secure virtual hosting and virtual-machine infrastructure based on SSL/TLS protocols.
Thanks for taking the time to share this suggestion. This item has been around for a couple of versions of Visual Studio and we haven’t acted on it. Looking at the VS “15” plans, we’re not going to take action on this item, so we’re going to close it. If the suggestion is still relevant, please either take a look to see if there’s another suggestion that’s similar that you can vote on, or open a new suggestion.
- The Visual Studio Team
Eric Lawrence commented
@thegeeky is half right-- A server application is not able to see the SNI the client sent (short of watching the socket and parsing the handshake itself); this is a limitation that should be fixed.
However, it's not quite right to say that there's no way to tell SChannel which hostname it should be sending from the Client to the Server-- The hostname provided in the AuthenticateAsClient call is used as the SNI, on supported operating systems (WinVista+) with supported algorithms (TLS extensions require SSL2 be disabled).
@Lex Li: Lets assume you write a server application and the client transmits the hostname via SNI: The problem is: The "SslStream"-class does not tell you which hostname was requested and its impossible to send the correct certificate.
Also the other way round: If you are writing a client: There is no way to tell SChannel which hostname it should indicate via SNI. SslStream is missing the required parameters
Lex Li commented
Not very clear what you are asking indeed. SNI is a security feature Schannel supports (since Windows Vista from some Microsoft MSDN blog, or Windows 8 from an MSDN article), and in which part of VS do you want it to be supported? If you do native or managed projects in VS you should already receive the support from the underlying OS.
I need this too!!
Yes, pleade add it !!!