Add ALPN support to System.Net.Security.SslStream

[ericlaw1979]

Porting to newest bug tracker.

https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/6264363-add-support-for-alpn-to-system-net-security-sslstr

https://connect.microsoft.com/VisualStudio/feedback/details/812003/system-net-security-sslstream-needs-support-for-alpn-to-negotiate-spdy-http2-connections

Microsoft drove the HTTP/2 working group to adopt the ALPN TLS Extension for use in negotiating HTTP/2 connections. It succeeded. SChannel got ALPN support in the Windows 8 timeframe.

.NET's SslStream class does not have ALPN support, preventing low-level socket clients (like Fiddler) from sending ALPN tokens to servers during TLS handshaking, in turn blocking support of the HTTP/2 protocol.

The code change to SslStream is probably a dozen lines at worst. The current workaround for those blocked by this shortcoming is to take on a massive security risk and ship either BouncyCastle or OpenSSL (or re-wrap SChannel, I guess).

[davidsh]

cc: @CIPop @SidharthNabar

[benaadams]

Information from referenced sources:

Add support for ALPN to System.Net.Security.SslStream:

Microsoft drove into the TLS working group a new standard called ALPN:

[IETFDRAFT-ALPN] Internet Engineering Task Force (IETF), "Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension", draft-ietf-tls-applayerprotoneg-00, April 2013, http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-00

This standard uses a TLS extension during the handshake to communicate to the server/client what inner protocol will be spoken over the secure stream. For instance, this is how SPDY and HTTP/2.0 connections are negotiated between browsers and compatible servers.

Today, there's no way for the .NET client to specify this ALPN during the AuthenticateAsClient / AuthenticateAsServer call on the SslStream, meaning that the customer must move to a 3rd party implementation (ugh).

To fix this, the SslStream code needs to be updated to pass a SECBUFFER_APPLICATION_PROTOCOLS buffer to the SSPI on compatible Operating Systems (Win8.1 for now, hopefully to be backported to Win7 in IE12).

Reproduction steps:

Attempt to use a SslStream to connect to a SPDY / HTTP2 server.

Client cannot send TLS extension so connection falls back to older protocols. "

[SidharthNabar]

@ericlaw1979 - Thanks for reporting this here. This issue has been on our backlog for some time now, based on the Uservoice entry and we agree that it would be a useful addition to the .NET framework. However, we have been unable to implement this yet due to other higher priority items on our plate (such as adding networking libraries to this repo!)

We are currently working on adding System.Net.Security to this repo - at that point, we would welcome participation from you or other contributors to help implement this support. We would still work on it regardless, but in terms of timeline, we may not be able to deliver it as quickly as with external participation.

Thanks,
Sid

[ericlaw1979]

@SidharthNabar Okay, thanks for the update. This is a bit frustrating, insofar as the code fix is probably not more than a dozen lines (one property or parameter, one data structure passed to an existing call).

[justcoding121]

@SidharthNabar I peeked through the PR pending for System.Net.Security. SslStream relies on native Schannel of SSPI. As per msdn SSPI is said to have implemented ALPN. However HttpClient and other wrappers based on is relying on calls to native WinHttp via interop. Msdn documentation doesn't specify whether native WinHttp supports HTTP/2 yet.

[davidsh]

Windows WinHTTP does not support HTTP/2 at this time.

[benaadams]

It supports HTTP/2 on Windows 10 and Server 2016 tp

WinHTTP2 supports the HTTP/2 functions such as HttpDeclarePush etc https://msdn.microsoft.com/en-us/library/windows/desktop/mt219053(v=vs.85).aspx

[davidsh]

The link you sent is for the server-side HTTP.SYS API (HTTP Server API).

The client side WinHTTP stack currently DOES NOT support HTTP/2.0 protocol at all.

The client WinINet stack DOES support HTTP/2.0 protocol but that stack is not used in CoreFx.

[benaadams]

The client side WinHTTP stack

Ah my mistake...

[vtortola]

It is really sad finding out that there is no ALPN support in .NET.

[ghost]

When adding ALPN support, it would also be good to consider adding support for Server Name Indication (SNI) extension.

SNI is also a popular request for SslStream:

http://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/2564042-add-support-for-the-tls-server-name-indication-sn

[karelz]

This is dupe of #15813.
If there is any unique information in this issue which is not in the dupe, please let us know.