I suggest you ...

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

The proposal is to add TLS ALPN support to the System.Net.Security.SslStream API. One of the key applications of this would be to negotiate SPDY or HTTP/2 connection with a server.

"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).

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

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

899 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    AdminVisual Studio Team (Product Team, Microsoft Visual Studio) shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    16 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...

      Feedback and Knowledge Base